rethinking patch management with GIT / topgit

[Petr Baudis]

On Sat, Mar 27, 2010 at 03:22:22PM +0100, Enrico Weigelt wrote:
> >         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).

There are two parts to this:

(a) It's totally unrealistic to do unless you absolutely have to (e.g.
due to trademark issues).

(b) Even if, you just push the issue around! You would want to still
use something like the topgit model in your "forked upstream", since
again, you will probably want to have the two desirable properties we
seek to preserve - to reiterate them,

  (i) Have full and incremental history available for all changes.

  (ii) Have the ability to produce a diff from current version to
current upstream version for each logical change, for purposes of review
or e.g. upstream submission.

No matter how you push things around, you still need to reconcile (i)
and (ii), or explain why they aren't interesting - you haven't done that
yet.

-- 
				Petr "Pasky" Baudis
http://pasky.or.cz/ | "Ars longa, vita brevis." -- Hippocrates