[arch-dev-public] Possible signoff addendum

Eric Belanger belanger at ASTRO.UMontreal.CA
Tue Sep 9 12:56:47 EDT 2008

On Thu, 4 Sep 2008, Dusty Phillips wrote:

> 2008/9/2 Aaron Griffin <aaronmgriffin at gmail.com>:
>> On Sun, Aug 31, 2008 at 11:11 AM, Dusty Phillips <buchuki at gmail.com> wrote:
>>> Another alternative:
>>> - Create a web based interface to allow community users to signoff on
>>> packages. We could have a policy of X number of user signoffs is equal
>>> to one developer signoff. Developers can be trusted to test it better
>>> (or not? ;-), but arch members can contribute too. In that case we
>>> still need some incentive to the end users to bother doing this. There
>>> aren't a lot of people like dolby and cactus who seem to actually like
>>> working really hard with as little recognition as possible.
>> I actually thought about this a while back. It was in terms of "each
>> package needs 10 points, developer signoffs are 5 points, TU signoffs
>> are 3 points, user signoffs are one point"
>> It might be a useful way to find active community members too. If you
>> could think of a way to creatively implement something like this, I'd
>> be all for it, assuming other people are.
> The obvious implementation would be to give people the option to sign
> up for an account and to give them signoff permission (as Paul
> suggested). This is easy to implement but it means non-devs have to
> have access to dev.archlinux.org or we have to break some of the
> caching on the public site (which would make cactus weep). It also
> means yet another fricking user account that people have to sign up
> for.
> A less invasive option would be to add a 'signoff this package' link
> to testing packages just like there is currently a 'flag out of date'
> link. But it would be hard to police if some asshat wanted to come
> through and click the signoff button 50 times even though the package
> was thoroughly busted.
> There have been some bug reports suggesting linking packages to
> flyspray tickets (or vice versa), and I have a personal vendetta
> against flyspray so another option would be to create a new
> package-based bug tracker and port existing bugs and user accounts
> from flyspray. Then anyone with a 'Arch Linux KISS Bugtracker' account
> would also have the ability to signoff on packages. So people could
> actively log in and either say "yo this package works so good I want
> it to go live (ie: signoff)" or "wtf this package is broken, fix it
> fix it whine whine whine (ie: attach a bug to the package)".
> The question isn't so much which of these to do as how much time do I
> have to commit to it (within epsilon of 0), how many other awesome
> people want to submit patches (approximately 2), and how soon do we
> need it (two months back?)
> Dusty
> PS: sorry for not replying sooner, that little bit of time I have for
> Arch is mostly being eaten up by schwag lately.

This sounds complicated.

I think we could improve signoff by being more organized. One of the 
current problem is that we have packages that very few devs uses (wireless 
drivers, file syatem tools, raid, lvm, etc). As we don't know how many dev 
uses these, at every signoff thread we are probably waiting for signoffs 
that will never come. And the users probably assume that eventually a dev will 
signoff.  So Aaron has to come and give his "untested" signoff just to get 
things moving.

To improve this, we should make a list of these low-usage packages with 
the name of the devs that actually uses them (and for which architecture). 
This might even encourage signoff if a dev knows he's the only one who can 
signoff a package. If there are packages that not enough dev use to do the 
signoff, we could do one of two options:

1) Make an exceptions for these packages. We move them to core once the 
devs who use them have signed off. We could also force them to remain in 
testing for a minimal time (few days) to be more safe. This is equivalent 
to what we do now when Aaron gives his "untested" signoff except we don't 
wait for a few weeks for signoffs that will never come.

2) We involve the community at large. In the signoff thread, we 
explicitely state that we need community signoffs and for which 
architecture. Users signoff by replying directly to the dev who started 
the signoff thread or to the arch-general ML. If a few users signoff, then 
we move the package to core.

The points system is not pratical. If no dev use a package, then we would 
need signoff from 7 TU or 20 users or any combination. This is a lot of 
signoff. If very few devs use a package, then it's probably the case for 
the community as well so it might take a long time to get all these 
signoffs. The signoff threads are on the arch-dev-public ML which is 
intented for Arch developpement. I assume that users subscribed to this 
list are more technical oriented and have Arch at heart. So if they 
signoff a package, then they probably know how to test it, have tested it 
and verified that it work as intended. Anyway, we would have their email 
address in case there are problems.


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

More information about the arch-dev-public mailing list