[Gta04-owner] [PATCH 00/11] DTS updates for GTA04
luk at slyon.de
Wed Jan 7 00:25:15 CET 2015
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:
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: OpenPGP digital signature
More information about the Gta04-owner