rethinking patch management with GIT / topgit

[Enrico Weigelt]

Thomas Koch wrote:

Hi,

> Although the above is quite a harsh judgement, I'd like to note, that tg has 
> had its merrit to promote one right idea: Patches should be managed in the 
> form of branches by the means of the underlying VCS and not as simple 
> patchfiles.

No, distros shouldnt maintain patches at all, instead use their
own maintenance-branches, which will be rebased to upstream on
new releases.

Lets take an example of debian (etch) and mysql. They have some
.orig tarball, which is _NOT_ upstream (actually, several files
left off, so it doesnt build) and some big patch against it.
This patch now not just changes some files but also adds patchfiles
(in debian/patches/*), which get applied deep within the package
build process (oh, they also have files in debian/additions, which
are directly copied-in/over to the source tree).

Needless to say that that's totally insane.

The right way would be having a upstream branch (really upstream!)
and an debian branch (maybe one for etch, one for lenny, ...),
which does the distro-specific things. Generic fixes should be
strictly separated from the distro-specific things (actually, in
99.99% of the cases that shouldnt be more than just adding the
buildrule files), so others (upstream, other distros, etc) can
easily cherry-pick at will.

Ah, of course, NEVER EVER changing autogenerated files should
be self-understood ;-o

> 1) merge commits to save history

Interesting idea. But probably too complex in the long run.
Think of rebasing, etc.

Instead I'd prefer special suffixes or some additional headers
in the commit-messages, which indicate some classification, eg.
whether the its distro-specific (and for which distro) or generic,
whether its critical (security fixes), external source (eg. CVE's),
maybe also some really-global unique identifier. This information
then can be used by semi-automatic helper scripts (in theory, full
automatization might be possible, but I'd strongly advise against
it from QM viewpoint).

> Managing a Debian package in stable, unstable and experimental can quickly 
> doom you to manage at least three different patchsets with possibly three 
> different roots. 

As said above. It's the idea of patchsets at all which brings you
into that nightmare (and, of course, debian's insane way for managing
them). Simply use branches (and the usual wf's like rebase) instead
of patchsets, and you're quickly out of that hell.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info at metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------