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 <sriva...@acm.org> <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C _______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss