Staging tree for AM335x platforms

Staging tree for AM335x platforms

[Jason Kridner]

Tony,

I'm looking at creating a public repository to hold patches not yet in
shape for inclusion in linux-omap (if not personally, then someone at
TI that meets the below charter).  I know there can be concern that
this becomes a distraction if we start pulling in community patches.
It seems it needs to be coupled with reworking systems for acceptance
upstream, but we'd like for there to be something where community
members can generate patches against while we are in the process of
cleaning up the underlying platform bits.

Do you have any recommendations or guidelines that should be followed
regarding anything about such a public repository?  Recommendations
and guidelines can include, but not be limited to, where the
repository should live, where patches and pull requests should be
submitted, what types of patches should be accepted and what state
they should be in, when should it be rebased, who is suitable to
maintain this repository and what should be used for managing patch
status (ie. patchwork and which patchwork).

If this doesn't sound useful to you, then please feel free to shut me
down on this.  The goal is to help and it is understood that
contributions to the infrastructure (dev tree, pwr mgmt, etc.) are
required to be productive.

Regards,
Jason

Re: Staging tree for AM335x platforms

[Tony Lindgren]

Hi,

* Jason Kridner <jkridner@beagleboard.org> [110921 10:56]:
> Tony,
> 
> I'm looking at creating a public repository to hold patches not yet in
> shape for inclusion in linux-omap (if not personally, then someone at
> TI that meets the below charter).  I know there can be concern that
> this becomes a distraction if we start pulling in community patches.
> It seems it needs to be coupled with reworking systems for acceptance
> upstream, but we'd like for there to be something where community
> members can generate patches against while we are in the process of
> cleaning up the underlying platform bits.

OK cool.
 
> Do you have any recommendations or guidelines that should be followed
> regarding anything about such a public repository?  Recommendations
> and guidelines can include, but not be limited to, where the
> repository should live, where patches and pull requests should be
> submitted, what types of patches should be accepted and what state
> they should be in, when should it be rebased, who is suitable to
> maintain this repository and what should be used for managing patch
> status (ie. patchwork and which patchwork).

Well in general the thing to watch out for is once you create a tree
it becomes a complete mess in about three months. Or else it just
becomes a graveyard of unmergeable patches :)

So keeping that in mind, ideally your tree would be just a daily merge
of various driver developers branches. And then try to set up things
where the responsibility of merging code upstream is on the drivers
developers. Trying to merge other people's patches upstream is not
scalable.

Other than that, you should be able to base it on some recent mainline
tag and pick in some queued up patches as needed.
 
> If this doesn't sound useful to you, then please feel free to shut me
> down on this.  The goal is to help and it is understood that
> contributions to the infrastructure (dev tree, pwr mgmt, etc.) are
> required to be productive.

That totally sounds usable to me :) Assuming you can figure out some
way to address the comments above.

For helping with contributions, I can think of a few places where
help is badly needed:

1. Remove dependencies in mainline kernel that block merging

   Maybe you can isolate some issues in mainline kernel that cause
   you problems merging your patches upstream? If so, whatever is
   needed should be done to patch away those dependencies. At least
   PM patches fit into this category..

2. Merge all am335x/beagle clone board-*.c files together

   This would help a lot when we start converting drivers to use
   device tree as it reduces the number of board-*.c files

3. Help with device tree conversion of device drivers

   Which drivers do most am335x and beagle clones use? Maybe
   you can help converting those drivers to use device tree?
   Sure some drivers depend on regulator framework conversion and
   the device tree omap_device glue layer, but there are already
   patches being posted for those

Regards,

Tony

Re: Staging tree for AM335x platforms

[Jason Kridner]

On Wed, Sep 21, 2011 at 4:23 PM, Tony Lindgren <tony@atomide.com> wrote:
> Hi,
>
> * Jason Kridner <jkridner@beagleboard.org> [110921 10:56]:
>> Tony,
>>
>> I'm looking at creating a public repository to hold patches not yet in
>> shape for inclusion in linux-omap (if not personally, then someone at
>> TI that meets the below charter).  I know there can be concern that
>> this becomes a distraction if we start pulling in community patches.
>> It seems it needs to be coupled with reworking systems for acceptance
>> upstream, but we'd like for there to be something where community
>> members can generate patches against while we are in the process of
>> cleaning up the underlying platform bits.
>
> OK cool.
>
>> Do you have any recommendations or guidelines that should be followed
>> regarding anything about such a public repository?  Recommendations
>> and guidelines can include, but not be limited to, where the
>> repository should live, where patches and pull requests should be
>> submitted, what types of patches should be accepted and what state
>> they should be in, when should it be rebased, who is suitable to
>> maintain this repository and what should be used for managing patch
>> status (ie. patchwork and which patchwork).
>
> Well in general the thing to watch out for is once you create a tree
> it becomes a complete mess in about three months. Or else it just
> becomes a graveyard of unmergeable patches :)

I'm not going to advertise a tree here and on the beagle list until
I'm confident I can stick with it a couple of years consistently.  I
like to keep some labels on old stuff, but I would commit to having it
rebased frequently and tested in an automated fashion.

>
> So keeping that in mind, ideally your tree would be just a daily merge
> of various driver developers branches. And then try to set up things
> where the responsibility of merging code upstream is on the drivers
> developers. Trying to merge other people's patches upstream is not
> scalable.

Understood.  I'd be looking for contributors to show some commitment
or drop their patches.  I'm sure there will be a certain amount of
fire-and-forget patches coming from people that I'll want to try to
push for them, but I'll try to shed the cruft frequently.

>
> Other than that, you should be able to base it on some recent mainline
> tag and pick in some queued up patches as needed.
>
>> If this doesn't sound useful to you, then please feel free to shut me
>> down on this.  The goal is to help and it is understood that
>> contributions to the infrastructure (dev tree, pwr mgmt, etc.) are
>> required to be productive.
>
> That totally sounds usable to me :) Assuming you can figure out some
> way to address the comments above.
>
> For helping with contributions, I can think of a few places where
> help is badly needed:
>
> 1. Remove dependencies in mainline kernel that block merging
>
>   Maybe you can isolate some issues in mainline kernel that cause
>   you problems merging your patches upstream? If so, whatever is
>   needed should be done to patch away those dependencies. At least
>   PM patches fit into this category..

Makes sense.

>
> 2. Merge all am335x/beagle clone board-*.c files together
>
>   This would help a lot when we start converting drivers to use
>   device tree as it reduces the number of board-*.c files

Sounds like a good task and something I can tackle.  I got some
push-back on this from internal developers, but I think I can start
merging some of it myself and send some code to ask advice on how to
make it most maintainable.

>
> 3. Help with device tree conversion of device drivers
>
>   Which drivers do most am335x and beagle clones use? Maybe
>   you can help converting those drivers to use device tree?

USB, GPIO, I2C and SPI are most critical from my perspective.  I need
to figure out which of those already have some owners pushing them
ahead.

>   Sure some drivers depend on regulator framework conversion and
>   the device tree omap_device glue layer, but there are already
>   patches being posted for those

Great.  I guess it makes sense for this tree to include those patches
and hopefully the thrash when they change won't be unbearable.  I
won't know until I start doing it. :-)

>
> Regards,
>
> Tony
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html