Hi Kevin! "Kevin B. McCarty" <kmccarty@debian.org> wrote: > Martin Uecker wrote: [...] > 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. I think it is problematic even if the patch is good, because having different software branches fragments all kind of bug fixing/development and reviewing work, which could otherwise be shared upstream. > 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 This might be part of the problem, but there was discussion with other upstream developers on openssl-dev. So the problem was not that there was no communication, but that the actual patch was not forwarded to the upstream developers. [..] > > 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). I guess you are right, it's not a fork, more like a branch. I could imagine that there are good reasons for having a Debian branch for something like X, but I don't think this is true for many packages. [...] > 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. Surely, this is very valuable work and I am not implying at all that you should stop it. But if upstream is dead, then their is no reason not to step in and simply take ownership of the package. Traditionally, if upstream was dead, somebody formally declared ownership of the software and took over development. I think this is the right thing to do, because then there is a new upstream where all other work can be shared. If upstream is incompetent, that somebody can step in and fork the software. Again, with a clear announcement. Then this step can be discussed openly and other users might switch over to the fork. Just integration all changes which are not accepted upstream as part of the packaging work just makes it too easy to diverge from upstream without good reason, without discussion and without an easy way for other users/distributions to see whats going on and to eventually switch over. > 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. I don't now. I see no reason why all this good work which now ends up in Debian patches can't be seperated from the actual packaging work. Regards, Martin
Attachment:
signature.asc
Description: Digital signature