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: i...@metux.de skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- _______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss