[Gta04-owner] [PATCH 00/11] DTS updates for GTA04
neilb at suse.de
Wed Jan 7 20:06:16 CET 2015
On Wed, 07 Jan 2015 00:25:15 +0100 Lukas Maerdian <luk at slyon.de> wrote:
> Am 06.01.2015 um 20:25 schrieb Dr. H. Nikolaus Schaller:
> > [...]
> > We simply have a different development model. The general problem is that
> > during development one tries this and that and fixes things here or there. And
> > sometimes has to revert. Or develops in “steps”.
> > But Linus wants to see so called “clean” patches (which is ok) which hide much
> > of this upfront work. In the end he will have an identical tree - just different
> > history how to get there.
> > So there must necessarily be some “cleaning stage”.
> > Now, there are two approaches:
> > 1. the individual developer hides all these deviations and wrong paths from the public and ends up in a set of “clean” patches only
> > 2. all changes are applied and documented to a public tree and at the end of the pipeline there is a “cleaning” process to get well tested and good things upstream
> > Both approaches are shown to work.
> > The problem I have with 1. is that it does not allow collaboration (at least I have
> > no idea how it could work).
> > Only a single developer can work with this approach because he is either done
> > (no work left over for anyone else) or intermediate steps are not available (nobody
> > knows where work is going on). And there is no way for the single developer to
> > say “hello, I need help here or there” because then the risk is that someone answers
> > with non-clean patches.
> Well... I think in the end it (once again) boils down to a git rebase vs
> git merge debate. Option (1) is the view of the rebase camp and (2) is
> the view of the merge camp. I think in the kernel community it is common
> practice to use rebase for patches flowing downstream (i.e. from
> mainline) and use merge for patches flowing upstream (i.e. to mainline).
> This is nice for downstreams who are individual developers (like Neil),
> as it results in clean and tidy kernel trees/history, where you can see
> at first glance which patches are part of mainline Linux and which
> patches are sitting on top of that. I like this very much, too.
> Now, I think the problem is that Goldelico's gta04-kernel is a
> downstream for the kernel community AND an upstream for the gta04
> community at the same time. This makes it a bit difficult policy wise:
> Using a rebase policy would make life hard for contributors of the gta04
> project, as they would need to adopt their work with every change/rebase
> of their upstream (gta04-kernel). On the other hand, using a merge
> policy makes life hard for members of the kernel community, as it is
> different from their usual workflow and they cannot easily distinguish
> the state of patches in that tree (sitting on top/merged/pending).
> One solution for this problem I am thinking of would be to have an
> official GTA04 maintainer who is in charge of creating and collecting
> (or getting send) patches which are cleaned up and said to be ready for
> mainline inclusion. This maintainer could maintain a rebase style kernel
> tree (let's call it "gta04-staging") which he himself could use to issue
> pull requests to Linus and other kernel developers could easily see
> which gta04 related patches are already queued for mainline.
> The gta04-kernel (merge style tree) could stay the work in progress
> branch, which includes the latest work of all the gta04 community and
> it's history, even changes which are not yet ready for mainline or
> gta04-staging. It would look like this:
> [testing] [development]
> Mainline <--> gta04-staging <--[cherry-pick/cleanup]--> gta04-kernel
> ^^ ^^
> || ||
> kernel community gta04 community
> (gta04 related changes)
> Unfortunately, this approach needs more manpower, as we would need to
> manage an extra branch/tree (gta04-staging). But as the patches are
> formated, send upstream and kept track of already (on LKML) it shouldn't
> be to much extra work to reflect those actions in a new kernel tree
> (i.e. collecting & mainlining clean patches, removing non-accepted
> patches from gta04-staging, rebasing gta04-staging with every -rc release).
> I think we aren't the first project to encounter this problem and other
> solutions should exists, too.
Thanks for these thoughts. I think you are definitely correct that there are
different styles of tree-management for different purposes and it is
important to keep them separate. I think I have a slightly different view of
just what the different sorts of trees are and how they work.
Firstly, as you say, there are "upstream trees". Linus' tree is the ultimate
upstream and each maintainer has their own tree which collect change to that
subsystem that are on there way to Linus.
All development should be done against an upstream tree - at least it should
appear that way in public. How you edit and compile and test on your own
machine is up to you, but patches posted publicly should be against an
upstream tree and should have been tested against that tree at least a little
GTA04 isn't a single subsystem and so it doesn't make sense for there to be a
GTA04 upstream tree. There are lots of subsystems which need fixes or
improvements for the GTA04 to work. Each of those fixes or improvements
should be done against the individual upstream tree, and then merged together.
This is a bit like linux-next. That is a merge of lots of different
subsystem tree so that conflicts between subsystems can be quickly found and
so that there is a single place to find all pending work.
It it also a bit like a distro kernel (Debian or Redhat or SUSE etc). They
start with mainline, pull in patches from various places, and provide the
result to uses. But development isn't (normally) done against a distro
kernel (SUSE has a fairly strong "upstream first" policy. Do development in
upstream, then if necessary back port it to the distro kernel).
I think it would be useful to have a "gta04-next" tree which merges all the
different threads of development in different subsystems that are needed to
make the GTA04 work. omap, twl, mmc, libertas, audio, tty, etc, etc, etc,.
The trees I publish are a lot like this. The top commit is a merge of about
a dozen sub-trees.
If two or more people within the community want to collaborate on some
particular subsystem, they would make a git tree which is based on the
relevant upstream tree and contains their fixes - always in as clean a state
as they can manage. If just one person is working on a subsystem they would
manage that tree by themselves. If there is a group, one would be chosen as
Then all of these different subsystem trees could be merged into a
"gta04-next" tree which people can use and test. Developers would probably
do their development against gta04-next, but would publish it against the
relevant subsystem tree.
The "extra work" here is not really in maintaining "gta04-next". That can
largely be scripted (linux-next is handled mostly automatically). Rather,
the extra work is in keeps a clean subsystem tree for each subsystem. That
work (or "cleaning") has to be done eventually anyway, and I find that doing
it early, when the details are still fresh in my mind, is the best time to do
I would be very happy to maintain a "gta04-next" merge tree. i.e. if anyone
has a gta04-specific "subsystem tree" - based on an appropriate upstream tree
and containing only patches for a specific subsystem and those patches in a
reasonably presentable state (i.e. you wouldn't be embarrassed sending them
for public review), then I will merge that with any other such tree into a
"gta04-next", will perform at least basic compile testing, and will provide
feedback and make it available to everyone.
I wouldn't, in this role, be sending other people's patches upstream. That
is for them to do (though I can help if needed).
Summary: development is done (or publicly appears to be done) again upstream
subsystem tree. These "gta04 enhanced subsystem trees" are kept reasonably
clean and merged into gta04-next for public consumption. Patches are send
upstream from the subsystem tree, not from gta04-next. gta04-next is
BTW, the "git rebase" versus "git merge" issue is often made out to be a lot
bigger than it is. The reality is quite simple.
If a maintainer promises to accept pull requests (possibly after view) from
downstream developers/maintainers, then they must not rebase. That is all.
If a maintainer does not make that promise, either because there is no-one
down stream or because they prefer patches via email and are happy to resolve
conflicts, then they can do whatever they like.
Linus does make that promise and so makes a big thing of the "thou shalt not
rebase" thing. All his reasons are good, but they simply don't apply to
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 811 bytes
Desc: OpenPGP digital signature
More information about the Gta04-owner