Hi Mikhail, Mikhail Gusarov wrote: > Twas brillig at 10:30:44 15.05.2008 UTC-07 when Kevin B. McCarty did gyre and gimble: > > KBM> Believe me, there are lots of upstreams for which extensive > KBM> patching really is necessary. (I have no idea whether OpenSSL is > KBM> one of those, as I have no familiarity with its code nor the > KBM> Debian packaging of it.) > > Probably the work then should be clearly labeled as fork (especially > given the other distro maintainers also share some patches)? It will > reduce the confusion, like "oh, erm, our <foo> is not quite upstream > <foo>, we rewrote it from scratch, and left the name and this cute > logo". I'm not sure if you are addressing me specifically, or just maintainers in general who have a large patch set. I don't view my maintainership of cernlib, paw, etc. as a fork in the same sense that, say, X.org is from XFree86 or Xemacs from Emacs. (In the most technical sense, *all* Debian packages are forks of upstream, though in some happy cases the only difference is a little added packaging infrastructure, and Debian users are generally aware of this.) My patches, if somewhat extensive, are still at most a few percent of the total size of upstream's code, so there is no rewriting from scratch going on. I've also tried to make it very clear through README.Debian files, FAQ web pages, etc. how the software in Debian behaves differently from upstream's original version in the cases where the difference is visible to the end user. I have zero desire to be considered as cernlib upstream myself -- that would imply that the software was supported at a level that I am not able to guarantee. If my upstream were to reanimate (or someone else took over upstream), I'd happily continue to package new releases from them, keeping any of my patch set that continued to be necessary that they wouldn't themselves accept. Mainly, I see my packaging of this software as a caretaker effort that makes it possible for people to install it with a minimum of trouble, while being able to expect that it follows Debian policy and has some chance of getting fixes for reported bugs. If some future change to the operating system occurred that broke cernlib in a hard-to-fix way, I would be much more likely to orphan the package and request its removal from Debian than to try to make big changes to the architecture of the software. Doing the latter, IMO, *would* deserve to be called a real fork. -- Kevin B. McCarty <kmccarty@gmail.com> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751
Attachment:
signature.asc
Description: OpenPGP digital signature