FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Masters Of The Universe

 
 
LinkBack Thread Tools
 
Old 01-23-2009, 05:32 PM
Loc Martin
 
Default REVU: Automated Package Checks

Kjeldgaard Morten wrote:
> I am not sure that more automated package analysis well help much. The
> uploaders already have Lintian and other tools at their disposal, yet
> the fact is that many packages have lots of Lintian issues remaining
> on the binary packages.

Except for linitan errors, on the other hand lots of packages come with
easily to spot by script errors. Just off of my head:
1. debian/control
- wrong target dirsto (actually not always a mistake, since the upload
might sit in REVU for month before first review - if all uploads could
be checked at the start of a development cycle and either modified or an
email sent, it would save one back and forth comment cycle;
- wrong priority;
- maintainer field not assigned to MOTU, packager email need to be moved
to XSBC-Original-Maintainer;
- too many spaces in the file, too many characters on one or more lines
(valid for other files in debian/ too);
- debhelper version don't match compat one.

2. debian/copyright
- no copyright assigned, no licence;
- licence is GPL but the file doesn't direct to the location on the
system (or to a wrong location, not existing directory or GPL instead of
GPL2);
- no copyright/licence for the packaging (not sure it's mandatory).

Then maybe a grep on the source files for "copyright" "" "(C)" and the
log added to the files so one can check without having to download the
files.

3. debian/changelog
- no bug closed or wrong syntax.

4. other files:
- comment created automatically not removed;
- presence of an INSTALL file;
- no man(s) page(s);
- does REVU check for binaries in the packages? I've seen comments on
IRC that some upload need binaries removed, so if REVU don't do that it
might be nice to implement it (if feasible).

Some of the aforementioned issues might be invalid, some are just
cosmetic and shouldn't block a review or an upload, but they often
appear in reviews.

I agree those problems with an upload are easy to spot, and sometimes
don't take more than a few minutes by experienced MOTU, who might fail
to see the point of automating the process. That would be indeed
pointless if the review came just a few days after a first upload, but
the fact is it can take month, thus restarting the review process
(uploader need to fix those, upload a new package, then wait for a few
weeks/month before the real review, far more time consuming, starts).

Any automated reply is a benefit in the current state of REVU, since the
uploader can fix the package instantly (and go to IRC for questions) and
that would save going back and forth between uploads and comments, both
for MOTU/reviewers and for the uploader.

There's also the fact a first review will spot 3/4 of those problems,
then a few month afterwards somebody else will spot one or two issues,
which delay the final reviews even more.

> When people upload to REVU, they have read all the guides and
> tutorials (at least some have) and what they really want is a human
> being to look at it, and to get advice on what to do. Many see the
> warnings by the various tools, but simply don't know what to do about
> them. Or, they feel unsure on where to go and don't want to spend a
> lot of time going in the wrong direction.

Even when having read all the tutorials and packaging step-by-step
according to the rules, it's often hard to figure it out perfectly.
There's times you don't understand what the tutorial says in the right
way, and there's times you just make a mistake or overlook something.
Being pointed to your own errors is invaluable in this learning process
(and it's also a good way to ensure you won't forget the issue if you
want to do some reviewing later), and when it's close in time from the
making of the mistake, it means you still have everything fresh in
memory and won't just "apply the fix", but question what you thought you
had understood.

It doesn't replace human interaction, but it's a good start, especially
for uploaders that don't just want to see a package in the archives, but
want to be involved in REVU as well. Having an automated pre-review
process may be a good thing to try, as it won't in any way prevent human
interaction :
- people will go to IRC if they care about their upload, except they
will go there sooner and not few month later when the first comments appear;
- reviewer will have tools that save them some time while ensuring the
uploader is active, since he/she will have corrected some mistakes at
least once already.

Loc

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 01-23-2009, 05:43 PM
"Siegfried Gevatter (RainCT)"
 
Default REVU: Automated Package Checks

[2009/1/23 Loc Martin <loic.martin3@gmail.com>]

Just some comments:

> 1. debian/control
> - wrong priority;

How can this be determined? Priority "extra" is not always (although
very often) wrong.

> - maintainer field not assigned to MOTU, packager email need to be moved
> to XSBC-Original-Maintainer;

I think REVU already checks if the Maintainer has an address ending
with "ubuntu.com" .

> 2. debian/copyright
> - no copyright/licence for the packaging (not sure it's mandatory).
>
> Then maybe a grep on the source files for "copyright" "(c)" "(C)" and the
> log added to the files so one can check without having to download the
> files.

Doesn't lintian complain if there's no copyright statement?

> - no man(s) page(s);

I don't know how this could be checked...

--
Siegfried-Angel Gevatter Pujals (RainCT)
Ubuntu Developer. Debian Contributor.

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 01-23-2009, 07:42 PM
Loc Martin
 
Default REVU: Automated Package Checks

Siegfried Gevatter (RainCT) wrote:
> [2009/1/23 Loc Martin <loic.martin3@gmail.com>]
>
> Just some comments:
>
>> 1. debian/control
>> - wrong priority;
>
> How can this be determined? Priority "extra" is not always (although
> very often) wrong.

Indeed, it's not always wrong, but it can be suggested the uploader
check it really deserves the priority - and then the uploader can
comment on the reason on REVU, so reviewers will know why. Inexperienced
reviewers like me will almost surely point it to the uploader anyway

A better solution could be to fix dh_make so it defaults to the priority
optional instead of "extra" (then we know the uploader set "extra" on
purpose).

>> - maintainer field not assigned to MOTU, packager email need to be moved
>> to XSBC-Original-Maintainer;
>
> I think REVU already checks if the Maintainer has an address ending
> with "ubuntu.com" .

Indeed it does, as in http://revu.ubuntuwire.com/details.py?package=tcpproxy

However, for whatever reason it doesn't seem to be obvious enough, and
Nathan solution might help, especially if REVU automated comments appear
as a review (thus as visible as somebody's comments), with numbers for
each points to be fixed, and a clear statement for those that would
"block" the package to get further review.

>> 2. debian/copyright
>> - no copyright/licence for the packaging (not sure it's mandatory).
>>
>> Then maybe a grep on the source files for "copyright" "(c)" "(C)" and the
>> log added to the files so one can check without having to download the
>> files.
>
> Doesn't lintian complain if there's no copyright statement?

I didn't see lintian errors in REVU when I was reviewing the package
above, so it might not complain if there's no copyright/license for the
packaging. Again I'm not sure it's mandatory in either Ubuntu or Debian,
but if so it would be helpful for important packages where the uploader
gives up during the process but someone else would like to pick up its
work. If they at least license their packaging before disapearing that's
possible, else you'd have to track them, and it would be faster to redo
the work.

For greping the source files for copyright issues, I was under the
impression lintian doesn't do that by a comment on one of the wiki page
- a MOTU developer stated that the first thing he did when looking at
the copyright file was greping the source code.

>> - no man(s) page(s);
>
> I don't know how this could be checked...

I don't know either but REVU could check debian/rules and see if
manpages are installed, check the different ways they get installed
(depending on the tool used to build the package). The uploader can
comment if REVU doesn't spot them, but I'm not sure there's so many
different ways to install man pages.

Loc



--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 01-23-2009, 07:44 PM
"Siegfried Gevatter (RainCT)"
 
Default REVU: Automated Package Checks

2009/1/23 Loc Martin <loic.martin3@gmail.com>:
> I don't know either but REVU could check debian/rules and see if
> manpages are installed, check the different ways they get installed
> (depending on the tool used to build the package). The uploader can
> comment if REVU doesn't spot them, but I'm not sure there's so many
> different ways to install man pages.

The problem is not only knowing if uploads are being installed (which
is not that easy, as they can be installed by upstream's autotools, a
custom install script or whatever), but if there's actually some
manpage required and for which binaries.

--
Siegfried-Angel Gevatter Pujals (RainCT)
Ubuntu Developer. Debian Contributor.

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 01-24-2009, 12:10 AM
Kjeldgaard Morten
 
Default REVU: Automated Package Checks

Loc, Nathan,

It is in principle possible to transform REVU into a super-
sophisticated package-analysis machine that would extend Lintian's
capabilities and it is even in principle possible that virtually error-
free packages would result.

The point is, it doesn't solve our problem, because at some point, a
human being needs to have a look at the package. Even if all packages
were perfect, we still could not handle one review plus an upload with
the current activity of MOTUs.

In addition, having this automatic checking would not change the rate
of arrival of new packages. Our rate of processing is less than the
rate of arriving packages, and consequently the pool of packages
awaiting review is constantly increasing.

A second point is, that no matter how sophisticated the program, it
will not be able to solve issues that are common with many of the
packages. F.ex. that the package has to be split into several
subpackages, which often is a point of discussion, that the
description is not understandable, that files need to be removed from
upstreams tarball, etc. etc. There are lots and lots of issues that
could never be detected automatically.

Thirdly, and most importantly, is the personal interaction we get with
the uploaders, and in this regard the simple things people are asked
to fix is often a useful beginning. It gives you an opportunity to
judge the qualifications and personal qualities of the uploader, and
it tells you if the uploader is truly interested in doing some work.

So, in my opinion, REVU is a very good tool already that fulfills it's
purpose very well. What is lacking is the involvement of more MOTUs.

Cheers,
Morten


--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 01-24-2009, 12:33 AM
Kjeldgaard Morten
 
Default REVU: Automated Package Checks

On 23/01/2009, at 18.17, Jordan Mantha wrote:

... a long post with points that I agree with and others that I don't.
A very good outset for discussion! Just a short comment on one of
your points, Jordan:

> 1) New contributors are not to be encouraged to package from scratch.
> If somebody wants to go for it anyway, they will be expected to be the
> primary maintainer of the package and should give a rationale beyond
> "dunno, I just wanted to package something" for including it in
> Ubuntu. MOTU documentation should be fairly clear that generally
> people should try some other packaging tasks before try to package
> something from scratch.

I agree that new people should be pointed in a different direction,
which is why I have drafted a new "getting started" document with the
specific purpose of getting people involved with things other than
packaging new stuff. The document is still quite imperfect and it
would be good to get more ideas and more contributions!

https://wiki.ubuntu.com/GettingStartedDraft


Go edit! Specifically, it would be nice to get more qualified input
from folks in the bugsquad, the locos and in the ubuntu art teams!

Cheers,
Morten

--
Morten Kjeldgaard <mok0@ubuntu.com>
Ubuntu MOTU Developer
GPG Key ID: 404825E7


--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 01-24-2009, 12:51 AM
Nathan Handler
 
Default REVU: Automated Package Checks

On Fri, Jan 23, 2009 at 7:10 PM, Kjeldgaard Morten <mok@bioxray.au.dk> wrote:
> The point is, it doesn't solve our problem, because at some point, a
> human being needs to have a look at the package. Even if all packages
> were perfect, we still could not handle one review plus an upload with
> the current activity of MOTUs.
>
> In addition, having this automatic checking would not change the rate
> of arrival of new packages. Our rate of processing is less than the
> rate of arriving packages, and consequently the pool of packages
> awaiting review is constantly increasing.

I can not speak for other MOTUs, but when I review a package on REVU,
I normally subscribe to it. That way, I can review it again once a new
version is uploaded. If these uploaders abandon the package, I usually
move on and review a new package on REVU. Hoever, if the uploader is
active, and prepares new versions as-needed, I am usually busy
re-reviewing that package, so I don't review any new ones. For me, I
would much rather keep working on one package and get it to the point
where it can be uploaded than review a lot of packages only once.

>
> A second point is, that no matter how sophisticated the program, it
> will not be able to solve issues that are common with many of the
> packages. F.ex. that the package has to be split into several
> subpackages, which often is a point of discussion, that the
> description is not understandable, that files need to be removed from
> upstreams tarball, etc. etc. There are lots and lots of issues that
> could never be detected automatically.

You are correct. We would only be able to test for some of the more
basic stuff. However, this will reduce the number of times that the
contributor would need to upload, wait for a review, and revise. The
fewer times that they need to do that, the faster we can get the
package uploaded and out of REVU.
>
> Thirdly, and most importantly, is the personal interaction we get with
> the uploaders, and in this regard the simple things people are asked
> to fix is often a useful beginning. It gives you an opportunity to
> judge the qualifications and personal qualities of the uploader, and
> it tells you if the uploader is truly interested in doing some work.

REVU is not designed to form relationships. If the MOTU is interested
in getting to know the uploader, they should initiate a conversation
either on IRC or via email. Also, these automated checks will still
allow the MOTU to see if the uploader is really interested in working
on the package. If they are willing to take the time to make the
corrections proposed by the checks, they are probably also willing to
make any corrections proposed by the MOTU.
>
> So, in my opinion, REVU is a very good tool already that fulfills it's
> purpose very well. What is lacking is the involvement of more MOTUs.

Yes, REVU is a great tool. And yes, having more MOTUs reviewing
packages would solve a lot of the problems. However, we can not force
people to spend time on REVU. As a result, we need to do what we can
to make REVU as easy to use and efficient as possible.

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 01-24-2009, 01:06 AM
Scott Kitterman
 
Default REVU: Automated Package Checks

On Fri, 23 Jan 2009 19:51:41 -0600 Nathan Handler <nhandler@ubuntu.com>
wrote:
>I can not speak for other MOTUs, but when I review a package on REVU,
>I normally subscribe to it. That way, I can review it again once a new
>version is uploaded.

There are other MOTU that think it's good to get review on a variety of
packages and a variety of MOTU look at each package. We all have our
strengths and variety helps get a balanced view.

I often focus on copyright/license stuff in packages with one advocate as a
pretty large fraction of advocated packages still have problems in this
area.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 

Thread Tools




All times are GMT. The time now is 09:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org