NEW Packages process

[Loïc Martin]

Stefan Potyra a écrit :
 > Hi,
 >
 > On Wednesday 16 April 2008 18:51:36 Loïc Martin wrote:
 > [..]
 >>
 >> 1. Is it possible to review what are the most frequent packaging errors,
 >> and how much of these can be picked up by a few scripts?
 >>
 >> IMHO, most new contributors would omit debian/copyright, or tend to
 >> indicate the wrong Ubuntu version (i.e. the stable release instead of
 >> the development one, since at first you're not going to know about SRU
 >> policy), leave the Debian one, forget to fill some fields in
 >> debian/control, include binaries, etc...
 >>
 >> Could it be possible to automate most of these checks and others, so
 >> each uploader would get feedback on the first screening errors ( a
 >> process which, at the moment, can take 2+ weeks)? The system could point
 >> to the relevant parts of the documentation (hypertext links or extracts)
 >> for each problem, and provide information on how to receive human
 >> interaction if necessary - irc, mailing list or, better, a packaging
 >> forum since Windows users aren't used to irc and mailing lists). In
 >> short, a kind of lintian for common mortals, but server-side.
 >
 > hm... that's tough. Well, there is lintian, but not all of lintian 
output is
 > always correct for each source package (that's why you can override 
parts of
 > it). So the tricky part here is: What to do with the result of a package
 > checker? (should it reject the package, which would be wrong for 
some, should
 > it leave a negative reviewing comment, same problem, or should it 
just be
 > informational, which is what we have right now, though not really 
presented
 > very nicely).

lintian output is informative only if you already know how to correctly
build a package (and most first-time uploaders won't understand much of
what lintian is talking about).

I like lintian, and I use it, even when the package is for my own use
(f.e. new version of programs that I know are going to appear in Debian
then in Ubuntu's development version, but that I nedd right now in
stable). However, most of the time people won't know what to do with the
error descriptions, and from what I could understand reading some MOTU's
description of their work, they end up pointing the same things lintian
did on their first reviews.

If it is possible to give a human understandable descriptions of the
problems, accompanied with a how-to extract on the steps required to fix
the problems, would it save MOTU's time and give all uploaders the means
to improve their packaging practices without burdening MOTU? Ubuntu
documentation is really good at explaining things, and the quality of
the wikis could prove a good starting point compared to lintian's
output. Ubuntu's wiki are usually done bearing first time users in mind,
and that's really what most first-time uploaders are (else they'd be
uploading to Debian in the first place).

The revision process for new package doesn't have the same landscape as
lintian's main use. The most common packaging errors aren't necessarily
the same problems that lintian checks, and the experience in years of
REVU could be used to adapt the tools.

Another aspect lintian won't adress is that most users would package an
application for the version of Ubuntu they are using, thus providing
incorrect debian/control. However, it is the version they able to test
the application the best with, while pbuilding a package for a
development version of Ubuntu nobody uses yet only proves that the
package builds. If it is possible to replace gutsy by hardy
automatically, then check if it builds, packages could be accepted more
easily, without having to just reject the package till the uploader has
understood completely Ubuntu's policy.

It's not going to degrade/dumb uploaders. Between an uploader that just
checks if a package build and one that actually runs the application and
use it everyday, which one is going to give the best feedback/testing?
In later stages, they're going to learn how to build a package for other
  versions of Ubuntu.

Some jobs can be made simpler by applying some computer power. It can be
too much for a server at the moment, but processor power is cheaper than
MOTU's time.

At the moment, whatever lintian's input, a reviewer still has to point
the problem to the uploader when this uploader isn't already familiar
with the system.

 > Others than that, someone would have to write such a checker, in case 
lintian
 > doesn't fulfill the needs. Running that on the server - given that it's
 > particular secure to do so - shouldn't be a problem.
 >
 >> Result : the packager gets immediate input, and reviewers know that
 >> they're only reviewing pre-screened packages which should already build
 >> and meet a few basic standards. How costly would it be for the server to
 >> try and test building each upload - getting the tarball, applying the
 >> patches, trying to build the package, and even trying to run it?)
 >
 > Autobuilding: autobuilding is basically handing out a root shell on 
the box,
 > so this won't happen.

I didn't know about that, sorry. It means MOTU always have to build the
package on their side to check if it builds? Or could it be done in a
virtualised environment?

 >> 2. When the new package is uploaded, the uploader's email could be added
 >> as a bug contact, while all reviewing comments (including the automated
 >> screening results) are forwarded to its email address, ensuring nobody
 >> loses touch with their package unless they'd really have no interest in
 >> it (which I assume isn't the case in the first place).
 >
 > Well, we have the motu-reviewers mailing list. I'm not sure if I'd 
like to get
 > an additional email myself, but this shouldn't be too tough to do in 
case
 > other people feel the same way. (I guess the hardest part is finding out
 > where to send the email, since it involves looking up the signature 
of the
 > changes file and finding out the email address of the signature).
 >
 > Cheers,
 >      Stefan.

It's mostly for non-MOTU uploaders, since they're the one that can have
difficulty to track the review of their package. MOTU could disable
their email address - especially since MOTU or frequent users won't have
to wait a few weeks for a review, so they're not really the ones that
would lose track of their uploads.

However, other uploaders could be required their email address before
uploading, thus making sure they receive any comments done by the system
or by MOTU. If I were a reviewer, I'd feel happier knowing that the time
spent reviewing a package doesn't have all chances to be lost on a
server's database.

Uploader's email address could also be picked up from their
Launchpad/Ubuntu account.


I'm more trying to explain things from a newbie point of view. MOTU are
the few first-time uploaders that were already going to track all the
review process and get in touch with developers in the first place. If
we are loosing some possible candidates, putting ourselves in the shoes
of these users can help adjusting the review system.

Making it simple like that isn't going to affect the package quality,
while going from 2 ACK to 1 might. It could save MOTU's time and broaden
the MOTU hopefulls base while ensuring the same (or better) standards in
package building. Better teaching doesn't dumb the students just because
the classes aren't reserved to a small number of people anymore.

While looking for packages (I always Google before trying to package
something) I've found many packagers that have been providing quality
Ubuntu packages for years, but didn't get them into Ubuntu because they
got discouraged by the process (most often it was because of the long
time before review of the packages occurred, or because they were aiming
for a released version of Ubuntu instead of the development one). Most
people won't understand the need for codes and "bureaucracy" at first,
but it doesn't mean they can't (an automated system has the advantage of
being responsive and always welcoming, when we humans have real life and
limited to cope with, even with the best of our efforts).

Cheers,
Loïc