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, 01:04 AM
Nathan Handler
 
Default REVU: Automated Package Checks

On Thu, Jan 22, 2009 at 7:42 PM, Scott Kitterman <ubuntu@kitterman.com> wrote:
> I think it's fine to mention, but I wouldn't want the package rejected or knocked into some
> kind of needs work state as a result.

That brings up another interesting point. Which checks should result
in the package entering the Needs Work list? Most of the issues that
would be checked for are minor things by themselves, and probably
should not be in the Needs Work list. However, I feel that a package
that has a lot of minor issues with it should go in that list. Maybe
we could have a counter that keeps track of the number of issues
detected with the package during the automatic checks. If more than a
certain number of issues are detected, the package is sent to the
Needs Work list (with a comment). Otherwise, only a comment is added.
This would prevent a package that passes all of the checks except the
needs-packaging bug check from being sent to the Needs Work list, but
the uploader will still be told that they should close a
needs-packaging bug in their changelog entry.

--
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, 02:18 AM
Scott Kitterman
 
Default REVU: Automated Package Checks

On Thu, 22 Jan 2009 20:04:55 -0600 Nathan Handler <nhandler@ubuntu.com>
wrote:
>On Thu, Jan 22, 2009 at 7:42 PM, Scott Kitterman <ubuntu@kitterman.com>
wrote:
>> I think it's fine to mention, but I wouldn't want the package rejected
or knocked into some
>> kind of needs work state as a result.
>
>That brings up another interesting point. Which checks should result
>in the package entering the Needs Work list? Most of the issues that
>would be checked for are minor things by themselves, and probably
>should not be in the Needs Work list. However, I feel that a package
>that has a lot of minor issues with it should go in that list. Maybe
>we could have a counter that keeps track of the number of issues
>detected with the package during the automatic checks. If more than a
>certain number of issues are detected, the package is sent to the
>Needs Work list (with a comment). Otherwise, only a comment is added.
>This would prevent a package that passes all of the checks except the
>needs-packaging bug check from being sent to the Needs Work list, but
>the uploader will still be told that they should close a
>needs-packaging bug in their changelog entry.

I'd suggest the automatically generated list be exposed on the package page
on revu so that a MOTU doing a review can quickly look at the list and
judge if the package is mature enough for a detailed review. If it's not,
they can easily leave a comment like "1, 2, and 4 really need to be fixed
before the package gets a detailed review. 3 is nice to have and add a
lintian override for 5. It's OK as is."

Scott K

--
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, 02:24 AM
Nathan Handler
 
Default REVU: Automated Package Checks

On Thu, Jan 22, 2009 at 9:18 PM, Scott Kitterman <ubuntu@kitterman.com> wrote:
> I'd suggest the automatically generated list be exposed on the package page
> on revu so that a MOTU doing a review can quickly look at the list and
> judge if the package is mature enough for a detailed review. If it's not,
> they can easily leave a comment like "1, 2, and 4 really need to be fixed
> before the package gets a detailed review. 3 is nice to have and add a
> lintian override for 5. It's OK as is."

The idea was to have the automatic checks add a comment to the package
on REVU. I think this would be the clearest method of showing the
issues in the package to the uploader and MOTU reviewers. Is this
exposed enough, or should the issues found in the automatic checks be
shown in some other way?

--
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, 02:44 AM
Scott Kitterman
 
Default REVU: Automated Package Checks

On Thu, 22 Jan 2009 21:24:16 -0600 Nathan Handler <nhandler@ubuntu.com>
wrote:
>On Thu, Jan 22, 2009 at 9:18 PM, Scott Kitterman <ubuntu@kitterman.com>
wrote:
>> I'd suggest the automatically generated list be exposed on the package
page
>> on revu so that a MOTU doing a review can quickly look at the list and
>> judge if the package is mature enough for a detailed review. If it's
not,
>> they can easily leave a comment like "1, 2, and 4 really need to be fixed
>> before the package gets a detailed review. 3 is nice to have and add a
>> lintian override for 5. It's OK as is."
>
>The idea was to have the automatic checks add a comment to the package
>on REVU. I think this would be the clearest method of showing the
>issues in the package to the uploader and MOTU reviewers. Is this
>exposed enough, or should the issues found in the automatic checks be
>shown in some other way?

I think it's fine as long as it doesn't automatically push the package to
needs work.

Scott K

--
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, 03:28 AM
Emmet Hikory
 
Default REVU: Automated Package Checks

James Westby wrote:
> On Thu, 2009-01-22 at 18:44 -0600, Nathan Handler wrote:
>> On Thu, Jan 22, 2009 at 6:31 PM, Loc Martin wrote:
>>> What happens when lintian (or another automated check) throws an error,
>>> but that error is not justified? I've seen the case for all cdemu
>>> related packages (for example
>> I actually had thought about this issue a bit. This lintian error that
>> you mention is not the only instance of a package that is not lintian
>> clean that is technically correct. The issue is, I personally can't
>> think of any reliable way to check for these cases. Having a MOTU
>> check the error is certainly possible, but I would prefer to keep this
>> as automated as possible. This is one reason that I sent an email to
>> the mailing list; I am hoping that someone can come up with an
>> efficient way to handle these exceptions.
>
> For lintian there are lintian overrides.

While adding more automated checks to REVU would be nice, the
existence of things such as lintian overrides, means that some of the
more substantive tests can be masked. While it's nice when a given
package has all the trivial bits right, these aren't typically as
important as having the packaging right. Aside from false positives,
many lintian warnings or errors may not make sense initially, and I'd
hate to find packages that passed the robot tests from excessive
overrides that needed to be detangled to be reviewed.


--
Emmet HIKORY

--
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, 04:49 AM
Daniel Holbach
 
Default REVU: Automated Package Checks

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Westby schrieb:
> For lintian there are lintian overrides.

lintian --no-override? :-)

Have a great day,
Daniel

- --
https://wiki.ubuntu.com/GlobalBugJam - 20-22 February 2009
Join in on the fun with YOUR team!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl5WlAACgkQRjrlnQWd1esfGACfYUUCgvtOVZ DnC6e1LKS0Lt5q
eqAAn1G0GK1J0yl1OBZtCQjuTahBzNyk
=pwmx
-----END PGP SIGNATURE-----

--
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, 08:49 AM
Kjeldgaard Morten
 
Default REVU: Automated Package Checks

On 23/01/2009, at 00.30, Nathan Handler wrote:

> For those of you who might be unaware, I have taken over Siegfried
> Gevatter's (RainCT) role of REVU Coordinator. For the past few days, I
> have been thinking about something, and I want to get the opinions of
> the rest of the people in the community before taking any action.

... and kudos to you for taking on this task, Nathan!

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.

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.

The REAL problem with REVU is that not enough MOTUs care about it to
enable us to keep up with the demand for reviews.

IF we want this interaction with the community, this way of meeting
and training new developers, we really have to do more!

If we don't, we should consider closing down REVU. Personally, I don't
think it's a good idea, but it is even worse having a queue of over a
hundred packages where uploaders are waiting months between review
cycles! That is detrimental to our standing respect in the community.
The large number of packages in the "needs-work" section is also
testiment to the number of uploaders who have given up, and every one
of those is a potentially useful contibutor lost. Those still hopeful
of getting their packages processed generally re-upload quite quickly,
and so their package can wait for another month or two. This is BAD.

As someone who has been doing lots of REVUs this cycle, it is quite
depressing seeing that no matter how hard you work, the list keeps
growing, and the packages you advocate do not attract a second advocate.

As a temporary measure, to get rid of this long queue, perhaps we
should only require one advocate for an upload? This is what Debian
does, and I'd like to suggest a discussion of that on the next MOTU
meeting.

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-23-2009, 09:57 AM
Stefan Potyra
 
Default REVU: Automated Package Checks

Hi,

On Friday 23 January 2009 01:31:42 Loc Martin wrote:
> Nathan Handler wrote:
[..]
>
> What happens when lintian (or another automated check) throws an error,
> but that error is not justified? I've seen the case for all cdemu
> related packages (for example
> http://revu.ubuntuwire.com/details.py?package=cdemu-client ) where
> lintian reports an error but according to the packager (and my newbie
> review ) the error is bogus.

Nope, in this case (cdemu-client) it is indeed a packaging error (don't copy
config.sub/config.guess in clean -- rather remove/restore the original ones
in clean. Otherwise the .diff.gz gets cluttered).

Cheers,
Stefan.
--
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, 10:21 AM
Scott Kitterman
 
Default REVU: Automated Package Checks

On Fri, 23 Jan 2009 10:49:56 +0100 Kjeldgaard Morten <mok@bioxray.au.dk>
wrote:
>On 23/01/2009, at 00.30, Nathan Handler wrote:
>
>> For those of you who might be unaware, I have taken over Siegfried
>> Gevatter's (RainCT) role of REVU Coordinator. For the past few days, I
>> have been thinking about something, and I want to get the opinions of
>> the rest of the people in the community before taking any action.
>
>... and kudos to you for taking on this task, Nathan!
>
>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.
>
>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.
>
>The REAL problem with REVU is that not enough MOTUs care about it to
>enable us to keep up with the demand for reviews.
>
>IF we want this interaction with the community, this way of meeting
>and training new developers, we really have to do more!
>
>If we don't, we should consider closing down REVU. Personally, I don't
>think it's a good idea, but it is even worse having a queue of over a
>hundred packages where uploaders are waiting months between review
>cycles! That is detrimental to our standing respect in the community.
>The large number of packages in the "needs-work" section is also
>testiment to the number of uploaders who have given up, and every one
>of those is a potentially useful contibutor lost. Those still hopeful
>of getting their packages processed generally re-upload quite quickly,
>and so their package can wait for another month or two. This is BAD.

Agreed.

>As someone who has been doing lots of REVUs this cycle, it is quite
>depressing seeing that no matter how hard you work, the list keeps
>growing, and the packages you advocate do not attract a second advocate.

Thank you for this and I quite understand.

>As a temporary measure, to get rid of this long queue, perhaps we
>should only require one advocate for an upload? This is what Debian
>does, and I'd like to suggest a discussion of that on the next MOTU
>meeting.
>
I do not think this is a good idea.

I think it's better in the short run if we all step up and do a bit and in
the long run if we figure a way to point new contributor more strongly
towards fixing what we already have.

Scott K

P.S. I'll sign up for doing a bit of it.

--
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, 04:17 PM
Jordan Mantha
 
Default REVU: Automated Package Checks

On Fri, Jan 23, 2009 at 1:49 AM, Kjeldgaard Morten <mok@bioxray.au.dk> wrote:
> On 23/01/2009, at 00.30, Nathan Handler wrote:
>
>> For those of you who might be unaware, I have taken over Siegfried
>> Gevatter's (RainCT) role of REVU Coordinator. For the past few days, I
>> have been thinking about something, and I want to get the opinions of
>> the rest of the people in the community before taking any action.
>
> ... and kudos to you for taking on this task, Nathan!
ditto

> The REAL problem with REVU is that not enough MOTUs care about it to
> enable us to keep up with the demand for reviews.
>
> IF we want this interaction with the community, this way of meeting
> and training new developers, we really have to do more!

I am fairly strongly against using REVU as an educational tool. IMO at
least, it should be use primary by existing developers to get work
done. The frustration of trying to learn how to package, learning the
Ubuntu processes, and waiting around for feedback mean we're often
just shoving newbs into the deep end of the pool and expecting them to
have fun. I'm not much surprised that they don't come back for more.
It also means we generate a lot of archive "cruft". Besides our
primary duties of keeping packages in sync with Debian and forwarding
bugs and applying fixes, we have almost 800 source packages to
maintain on our own. Given a core group of even 40 developers that's
20 packages *per* MOTU that are needing to be maintained without *any*
help from Debian.

> If we don't, we should consider closing down REVU. Personally, I don't
> think it's a good idea, but it is even worse having a queue of over a
> hundred packages where uploaders are waiting months between review
> cycles! That is detrimental to our standing respect in the community.
> The large number of packages in the "needs-work" section is also
> testiment to the number of uploaders who have given up, and every one
> of those is a potentially useful contibutor lost. Those still hopeful
> of getting their packages processed generally re-upload quite quickly,
> and so their package can wait for another month or two. This is BAD.

I wouldn't want REVU closed down completely I don't think, it's a very
useful tool. What I do think is that perhaps we can rethink the
purpose and process around how we use it. The issues seem to be 1) too
many requests to handle with the resources available and 2) too long
of turnaround time and very variable "results". So here's a "solution"
I've been tossing around in my head:

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.

2) For packages uploaded to REVU from non-developers (in this case I
think developers = ~ubuntu-dev), a developer should be paired up with
the REVU uploader as a primary sponsor. This developer will be
responsible for seeing the REVU process to completion (hopefully
meaning an upload to the archives, but could also be removing it from
REVU if the contributor gives up or the software is outright
unsuitable). The primary sponsor should work closely with the REVU
uploader so they shouldn't pick up too many packages at any given
time. They will also give the 1st ACK.

3) A group of MOTU who may either not have the time or desire to be
primary sponsors will take packages that have been ACKed by primaries
and do the 2nd review and ACK. This allows people who don't mind doing
a one-time review of an already good package to do something on REVU.

4) REVU would need to be modified a bit to handle this workflow. One
thing would be like a package description whiteboard that MOTU can
look at to see if they want to sign up as primary supervisors.
Currently it takes a bit of digging around to find what a package is
all about. It might also be nice to have a little "Sign up as primary"
box that would then subscribe you to the package and let the REVU
uploader know that somebody has taken on their project.

> As someone who has been doing lots of REVUs this cycle, it is quite
> depressing seeing that no matter how hard you work, the list keeps
> growing, and the packages you advocate do not attract a second advocate.

Right. IMO, this is due to flawed process/philosophy. You can't have a
"we'll include *anything*" philosophy, an easy tool to upload too,
random and arbitrary reviewing, and expect it to work efficiently or
effectively, IMO.

> As a temporary measure, to get rid of this long queue, perhaps we
> should only require one advocate for an upload? This is what Debian
> does, and I'd like to suggest a discussion of that on the next MOTU
> meeting.

I really would suggest not doing away with the 2nd ACK. It has often
proven useful. It also gives the 1st ACK a bit of freedom as they know
somebody else will double check their reviewing. Instead of cutting
out the useful bits let's perhaps rethink our philosophy about REVU a
little. One of the things that I'm wondering about is our general "we
don't care *what* it is as long as it's good packaging". While I know
Mark has wanted Universe to represent the entirely of the FLOSS
ecosystem essentially, we simply don't have resources to do that. If
Mark wants to spend some money hiring dedicated REVU people then I'd
more than welcome that, but until then I think we should focus on
processes that adequately reflect where we are today, not where we
hope to be some day. I think asking questions like, "why do we need
this in Ubuntu?", "how is this software different/better than
<existing package>?" might be useful for prioritizing work around
software that is of the most good to our users. It's very hard, though
not impossible, for me to justify to myself wasting MOTU time
maintaining solely a package that only 10 people in the whole Ubuntu
user-base every use.

-Jordan

--
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 04:34 PM.

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