On Wed, Aug 20, 2008 at 11:31:41AM +0900, Emmet Hikory wrote: > Steve Langasek wrote: > > If you have more than one change to the upstream source of a Debian package, > > then you need some system to manage the changes to indicate which parts of > > the patch belong to which functional change -- i.e., a "patch management > > system". This can be a set of VCS feature branches, if you prefer (in which > > case it's important to use the Vcs-* headers in debian/control in the Ubuntu > > upload), or it can be an in-package patch system; but it is important to > > have /some/ mechanism for labelling your changes so that you aren't left > > with a single massive diff.
> Why? Why should the Debian Maintainer care about the monolithic > patch as applied in Ubuntu (perhaps also cluttered by several > changelog entries about merges that have happened, or rebuilds). Is > it not best practice to send those patches relevant to Debian to bugs > in the BTS, as separated patches? If this is done, to whom is it > useful to track the patches independently, so long as the patches > remain easy to maintain? I think this is a misleading question: it is /not/ easy to maintain patches that are jumbled together in a monolithic diff, because even if it's easy for the person who created the patches (which is likely to change over time), it's not necessarily easy for $random_other_ubuntu_developer who comes along afterwards. Even the most innocuous-seeming of patches can become head-scratchers over time if they aren't accompanied by appropriate metadata (description, + some sort of bounding box saying which bits belong). So for *Ubuntu's* benefit, I believe our best practices should be to use some sort of patch management whenever patching upstream sources, not just a monolithic diff. (Again, I think this can be either VCS feature branches or an in-package patch system, whichever is easier for the people doing the work.) > > If the Debian maintainer already has a patch system in place, it's far > > better to continue using that one (no matter how bad it is, sometimes); > > otherwise, adding a patch system *should* be done when needed. > I generally argue against the introduction of patch systems, as 1) > I am very much opposed to working with a package that has both changes > in diff.gz (from the original packaging), and 2) a patch system. If we're talking about packages where the Debian maintainer has already patched upstream and done so without a patch system, then I agree that this is ugly; in that case I think the best outcome is if the Debian maintainer can be persuaded to /use/ some form of patch management. > These are painfully ugly, and the monolithic diff frequently becomes > completely unreadable (was this a change to a previous Debian change, > to an upstream change, or to a combination?); and 2) I have heard a > number of Debian maintainers complain about the "useless" introduction > of a patch system when they maintain the package in a VCS with no > patch system. Can you give examples of these? Ideally if the maintainer is already using feature branches in a distributed VCS, Ubuntu could hook into that with its own feature branches, and that would entirely satisfy my concerns about maintainability of the patches. But the highest percentage of Vcs-* fields in Debian packages still point at subversion, which is not at all useful for this purpose. > That said, in the case where there are no previous diff.gz changes > external to debian/, I think it is best practice to review other packages > with the same Debian Maintainer to attempt to determine the preferred > patch system of that maintainer (which may be monolithic diff.gz), and > follow that practice. In the rare case where there are no patches > external to debian/ in any of the packages maintained by that Maintainer, > the introduction of a patch system seems the least bad way to do things, > but this is very much an exceptional case, and for most packages we would > do well to instead follow the existing practice (even where that is a > monolithic diff.gz). I agree; I was assuming the common case was that the Debian package did not include patches to the upstream source, or that if there were any such patches, they were managed with a patch system. Perhaps this is not such a common case as I believed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
