Packaging Help

Scott Kitterman ubuntu at kitterman.com
Thu Sep 24 16:01:31 BST 2009


On 24 Sep 2009 14:44:42 +0200 "Michael Bienia" <michael at bienia.de> wrote:
>On 2009-09-23 20:59:51 +0200, Andreas Heck wrote:
>> As someone you just recently tries to contribute packages to Ubuntu I
>> think the biggest problem at the moment is that REVU seems to be dead
>> during freeze.
>> 
>> Of course you can't get something in at the moment anyway and there are
>> more important tasks at the moment for sure but nevertheless it can take
>> away some enthusiasm from prospective contributors and makes the process
>> look more bureaucratic than it actually is.
>
>I think that packaging an (unpackaged) software is not the best way to
>start contributing to Ubuntu. And therefore don't participate in reviews
>on REVU anymore. The reason behind this is that I get the impression
>that there are way too many packages that are getting packaged once and
>then left without a maintainer and only add to the general burden on
>MOTU.
>
>I got contacted by an upstream around two weeks ago after I uploaded a
>fix for a FTBFS. He asked me why Ubuntu still ships such an old and
>bugged version of his software and would prefer to get it removed from
>Ubuntu if an update is not possible. As we don't have someone who is
>interested in maintaining that package I opted for the removal. The
>package got packaged 3 years ago and since then had only two further
>uploads fixing a FTBFS and at least 8 new upstream releases since then.
>
>It doesn't help Ubuntu if we ship old versions of software to our users.
>It may sound harsh but it's better to not package a software if we don't
>have the resources to maintain it (i.e. a person looking after that
>package) than package it and let it rot after that. At least it would be
>more honest.
>
>I'm not against new packages at all if they are maintained properly. I
>do reviews now and then but only for MOTUs as can assume that they know
>what it takes to maintain a package and package only software that is
>really needed and not because they found an unpackaged application on
>the web.
>
>I'd prefer if new contributors start with helping on existing packages.
>This helps Ubuntu more and IMHO it's an easier approach as one needs to
>concentrate on only one aspect of packaging (e.g. adding missing
>build-dependencies, applying patches, etc.) instead of doing it all at
>once which might be overwhelming.
>And I also hope that new people understand that way that maintaining a
>package is not that easy and don't package new software that lightly.
>
>I don't mean that we should make it hard for people to get new packages
>in (it still should be easy), but we also shouldn't accept every package
>that appears on our doorstep. We should only let those in where we can
>assume that they are being maintained afterwards.
>Perhaps PPAs are a good ground to let people prove that they are really
>interested in maintaining a new package before we let the package into
>Ubuntu.
>
I think this all makes sense.

More and more, I think packages do need a maintainer.  In Main there are 
teams that generally well maintained.  In Universe we have a harder problem.

I've recently wondered if we should not carry binaries forward from the 
previous release, do an in archive rebuild at the start of each debelopment 
cycle once the toolchain is in place, and then automatically remove 
packages that don't have a successful build during the development cycle 
(and thus have no binaries).  This would ensure we don't carry 
unsupportable cruft into a release.

I have long thought it was better to bring new packages in through Debian.  
One reason, related to this thread, is that it ensures there is some 
maintainer that is keeping the package up to date.  Perhaps we could take 
packages into Ubuntu with the understanding that if they were not in Debian 
in one or two release cycles they would be removed from Ubuntu (unless some 
special arrangement is made and evidence of maintenance in Ubuntu is 
evident).

Scott K



More information about the ubuntu-devel mailing list