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
>  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.

>         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).

 Enrico Weigelt, metux IT service --

 cellphone: +49 174 7066481   email:   skype: nekrad666
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme

vcs-pkg-discuss mailing list

Reply via email to