Hi Martin, Martin Uecker wrote: > "Kevin B. McCarty" <[EMAIL PROTECTED]> wrote: > >> If you see packages for which a Debian-specific patch seems unnecessary, >> please by all means file a bug (severity wishlist) requesting that the >> patch be either reverted or submitted upstream. > > Most time the patch is already submitted upstream, but not yet applied > or released. If you look into the Debian changelogs you find a lot of > "drop XXX patch, applied upstream". This is done to bring the fix > faster to the user. The question is, is this worth it? Maybe it is, > but only for certain patches? Is there a policy?
Well, *assuming* the patch is good, a subset of users of the software (i.e. Debian users and users of downstream distributions) benefit from it between the time it's applied in Debian and the time it's applied upstream, and there are no major negatives that I can think of. But that assumption is what you really want to discuss, I guess. As far as I know, Debian policy is silent about when to apply a patch or how to decide if it's good. If upstream is responsive, it might make sense to wait until someone from there reviews the patch and gives a thumbs-up or -down. That supposes it is clear how to get in touch with upstream, which I gather was one of the big mis-communications leading to the current state of affairs [1]. [1] http://advogato.org/person/branden/diary/5.html >> Speaking only for myself, let me comment on some "extensive patching". >> I guess that some of my physics-related packages (cernlib, paw) are >> among the more heavily patched in Debian. Unfortunately upstream is >> dead, so there is *no way* to see the patches incorporated there. > > As other have already pointed out: In this case, it should be > considered a fork. It's really just an argument over semantics. I personally think of a "real" fork as one where someone purports to have taken over the role of upstream. You're welcome to have a different opinion (clearly you do). The XFree86 4.3.0 that Debian shipped with Sarge was also extremely heavily patched from the upstream version, but I don't believe most people thought of it as a "real" fork (unlike X.org). >> And even before they gave up the ghost, they were very conservative, >> refusing to consider most patches more complicated than trivial changes >> to fix complete breakage. > > Open source development does work well only if splitting up the > development in different branches or even forks is strongly > avoided and done only if it is strictly necessary. IMHO the > Debian way of doing things makes it far too easy for package > maintainers to diverge from the upstream source. I can't really > comment on the examples you have provided, but in general, I feel > that Debian has not found the right balance here. At least for the example of my packages that I brought up, if I could not make an extensive set of patches, it is unlikely that the software could have met the policy and quality standards to be accepted into Debian. Whether it's better for Debian to ship heavily-patched software (that is still quite popular in the physics community) from a dead upstream, or not to ship it at all (forcing users to download it on their own from upstream's web site, then find and apply some set of patches grabbed from elsewhere on the web [2,3], then going through a baroque and obsolete build procedure [4]) is of course open for debate. You can guess that I hold the former of these opinions. [2] http://www.public.asu.edu/~comfort/cernlib.html [3] http://www-zeuthen.desy.de/linear_collider/cernlib/new/cernlib_2005.html [4] http://cernlib.web.cern.ch/cernlib/install/install.html One could certainly envision a distribution that used a Debian-like packaging infrastructure, but had a goal of trying to deviate from upstream's source code as little as possible. I think that such a distribution would either have serious QA problems (think for instance of embedded code copies, a security nightmare) or would be restricted to packaging a much smaller set of software than Debian does. YMMV. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751
signature.asc
Description: OpenPGP digital signature