[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: extensive patching

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.


> 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" <kmccarty@debian.org> 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 <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

Reply to: