Packaging Help

[Loïc Martin]

The order of your email has been changed, because the part I put at the 
end gets off-topic, the relevant one is at the top.

Michael Bienia wrote:
> 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.

I actually learnt a lot preparing my first package, which was useful 
later ;) Far more than doing merges/sync/small patches/upgrades for 
packages which packaging is messy or really old, especially when you 
can't fix much because you have to keep it as close to Debian as 
possible (for future syncs/merges). Everybody is different, but what I 
learnt through REVU was a great help for the rest (except for writing 
get-orig-source targets, which apparently nobody cares for in Debian).

More important, I found the REVU process far friendlier and transparent 
than the sponsorship job needed when working on existing packages. The 
main problem I'm afraid off when telling new contributors we'd rather 
see them working on existing packages is that the sponsorship process 
can get really unfriendly and obscure, unlike REVU. Having someone's 
patch or diff.gz (that they spent countless hours on) sit for months 
unlooked doesn't encourage anyone into contributing, and nagging on 
#ubuntu-motu is nobody's idea of fun. Especially if everybody agree 
those same "unmaintained" packages are the problem we would want to 
solve in the first place[1].

The new reviewing practice with #ubuntu-review seems like a step in the 
right direction. Maybe having clear rules for Launchpad sponsoring would 
make it more transparent too, like having fixed time limits for a bug 
awaiting sponsorship to be looked at (twice a month, with set dates 
maybe? or a countdown thing per bug?). I don't say sponsor them if 
they've got issues, but at least stating why it isn't in good shape. 
Hopefully not just "Your diff.gz had to wait long enough for a new 
policy to come on, please update Standards-version and reupload" :P

In the end, having to nag people on IRC means you fix less bugs, and 
reduce the number of packages you work on, for fear of being obnoxious. 
Sadly, the packages needing the more work are those that gets less 
chances of sponsoring, probably because they aren't in a field the 
sponsors are interested in. Users are though.

> 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 does help our users though. Most people don't know how to get a 
program working in Ubuntu if it's not in the repositories, and upstreams 
usually only provide binaries for Windows and OSX, which leaves people 
no choice if the application isn't in the repositories. They thus have 
to switch back to Windows, not because the application they need doesn't 
have an open source equivalent, but because they can't use their open 
source application in Ubuntu.

For most people but enthusiasts, and older version is far better than no 
version at all - they might not even see the difference. Unless the 
version in Ubuntu has security issues, saying that it's old and buggy is 
from a developer's perspective. people that have used that application 3 
years ago learnt to do their work around the bugs. On the other hand, 
there's plenty of well-maintained and up-to-date applications that crash 
on our desktop everyday, and nobody's thinking about pulling them out 
from the repos.

The question would be to address the need of lambda users (who don't 
really care if a package FTBFS in new versions as long as it's still 
working on the desktop) - see Scott reply to our email, which deal with 
the developer side of things, but doesn't address the problem from the 
user side.

Moreover, it's usually not that hard for a new contributor to upgrade a 
package from upstream, and provides an easy level of entry into 
contributing. Far easier than when the application comes from Debian, 
and the developer isn't responding, or when the packaging itself has so 
much issues it wouldn't be sponsored if it was to be submitted into 
Ubuntu now. Packages that enter Ubuntu through REVU are far easier to 
deal with actually.

> 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.

Agreed. If we can make it easier for people to care for existing 
packages, wouldn't that help keep them contributing?

Loïc



[1] Just for reference, because they're recent:
https://bugs.launchpad.net/ubuntu/+source/xvidcore/+bug/306399
https://bugs.launchpad.net/ubuntu/+source/sdlmame/+bug/403212
https://bugs.launchpad.net/ubuntu/+source/ecm/+bug/410707
The first one we're not even respecting the license of the binaries we 
ship. The last one is fixed, but you can look at the time schedule and 
see the problem for new contributors.