Hi Martin, I'm afraid this will be my last remark in this thread (do I hear cheers from the crowd?) since I really should go do something more productive now :-) Thanks for keeping the tone of discourse civil -- clearly this is a subject you feel strongly about, and the problem that started the thread frazzled all our nerves.
Martin Uecker wrote: > Barry deFreese wrote: >> Which brings up at least two issues. Upstream not wanting the patches >> or dead upstream. Speaking from the games team alone I would bet that >> 50% or more of the packages have no upstream anymore. Should those >> packages be removed? > > If upstream is dead or unable to do his job well, somebody should fork > the project (or take ownership). But this has nothing to do with > packaging software and should in my opinion not be intermixed. [snip] > Fork it. But not as part of the packaging work. It's easy to say "somebody should fork it." But not enough people have time or resources to guarantee a new upstream for every dead project (or project with a bad upstream) worth packaging. For an example, after I was no longer able to serve as a good upstream for wmakerconf (since I stopped using Window Maker), it was six months before someone else volunteered to take it over [1]. He made a single upstream release back in April 2007 and then also had to abandon it. Only today did someone (me) even get around to uploading that new release into Debian. And wmakerconf is not a very obscure package -- it has 797 installations in popcon [2], an installation rate of better than 1% among systems reporting to popcon. [1] http://bugs.debian.org/290350 [2] http://qa.debian.org/popcon.php?package=wmakerconf Maintainership in a caretaker mode, building up a large set of patches to keep things working, is often the best that can be expected. But this is a lot better than nothing! The larger the project, the more this is so. Time is unfortunately a scarce commodity in the community. Responding to some of your more recent email: > "Kevin B. McCarty" <[EMAIL PROTECTED]> wrote: >> Martin Uecker wrote: >> 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. I believe that declaring one is the new upstream of a software means taking on a *much* greater responsibility than being the Debian maintainer of a package of that software. In the case of Cernlib and PAW, they are venerable (i.e. obsolete) FORTRAN-based code that, with a big effort, can be forced to work and be policy-compliant on modern Linux systems with gfortran. Among physicists, who are mostly amazingly conservative with respect to software, they still have a following. As Debian maintainer, I only have to care about, and fix bugs for, people using the software on modern Linux/gfortran systems that I'm familiar with. As an upstream maintainer, I would have to care about: - people wanting support for obsolete platforms like HP-UX or SunOS (there are still lots of those old workstations around!) - people wanting support for platforms I don't want to care about, like Cygwin or Mac OS X - people wanting support for proprietary FORTRAN compilers - ensuring that the code works on new platforms (the build system is based on Imake, it is a nightmare!) - future-proofing by porting to autotools, and rewriting lots of code that assumes sizeof(void *) == sizeof(int) and only works on 64-bit platforms by use of ugly hacks And then there is not just the software itself, but also all the project infrastructure which would be expected if a new upstream took over: web pages, online documentation, upstream bug tracking system, mailing lists ... I do not have anything close to the resources that would be needed to do all that for a project the size of Cernlib, it would take a good-sized team of people. > 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. The best I can do at this time is what I have done: shared my patches (many of which originated from other people, whom I've tried to ensure receive proper credit) with maintainers of other distributions (Fedora uses them, Ubuntu inherits them automatically, I've had an inquiry about porting them to OpenSuSE), and written documentation for users about what's changed in Debian relative to the last upstream release [3,4]. This is a long way from taking over as official upstream. [3] http://people.debian.org/~kmccarty/cernlib/faq.html [4] README.Debian file for cernlib-base binary package 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
