rethinking patch management with GIT / topgit

[Manoj Srivastava]

On Sat, Mar 27 2010, Enrico Weigelt wrote:

> Manoj Srivastava wrote:
>
> Hi,
>
>>>> No. Each upstream release brings a new distro branch. Trivial.
>> 
>>         Hmm. That would mean a lot more work if you are carrying long
>>  term features or modification to upstream to better fit the
>>  Distribution policy. I don't  cut a new branch fr each upstream; I have
>>  an integration branch that carries in it history of previous integration
>>  changes (conflict resolution for long term fixes/features),  and
>>  cutting a new branch from upstream would have me recreating all that
>>  work.
>
> Actually, I had to read your article (*1) to understand your point.
>
> Well, I don't use integration branches for distro purposes at all.
> Never ever. There are QM-branches, which only repairs upstream
> (eg. security issues, broken buildscripts, etc) and maybe add some
> customizability (eg. changing pathes or switching off some parts or
> features via ./configure or env). These are based on (not forked-off)
> the upstream, so frequently rebased on new upstream releases.
> For _really_ distro specific things (eg. debian/*), there're
> distro branches, based on the QM-branches.
>
> Note that that's an _strict_ tree structure. Downstream _never_
> merges upstream, but _always_ rebases, on tags, not active branches.

        *Shrug*. That is your worflow, and I am happy for you. I find
 myself in the position of being a middleman -- where I am packaging
 upstream sources, but there are people who derve from my packages, and
 thus rebasing is not an option. If you service a leaf level
 distribution, constantly rebasing might work for you. My experience has
 been that rebasing does not work well for me.

>>         I have heard people say that distributions should not carry
>>  feature branches or long term fixes, but push it upstream; but  in a
>>  non ideal world some upstreams do not respond as quickly as one wants,
>>  and secondly, a user obsession requires that users get desirable
>>  features, even if upstream is tardy or does not see the light, and thus
>>  feature branches might linger.
>
> That is _NOT_ distro's business. If you want such things, do a clean
> fork - w/ all implications. This creates a new/different package, out
> of the original package's versioning line. (eg. ff vs. iceweasel).

        I am glad you have an opinion. I do not share it. I have some
 experience packaging software for a fairly mainstream distribution, and
 I have long since come to the conclusion that the black and white line
 you draw is suboptimal for my users.

        In response to your question in a related email, in my opinion,
 this never-carry-patches-and-fork policy  does not work for me. I think
 rewriting history  that other people see is a bad idea.

        manoj
-- 
"Never give a statist an even break.  The State has never given us one."
Andre Marrou
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C