rethinking patch management with GIT / topgit
srivasta at ieee.org
Sun Mar 28 16:28:40 UTC 2010
On Sat, Mar 27 2010, Enrico Weigelt wrote:
> Manoj Srivastava wrote:
>>>> 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
> 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.
"Never give a statist an even break. The State has never given us one."
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
More information about the vcs-pkg-discuss