[arch-dev-public] improving signoffs

[Allan McRae]

On 14/03/10 08:21, Eric Bélanger wrote:
> On Sat, Mar 13, 2010 at 9:41 AM, Paul Mattal<paul at mattal.com>  wrote:
>> There's a confluence of circumstances that occurs regularly now that is
>> wasting lots of time for those trying to squash bugs:
>>
>> 1) It's really hard to get signoffs for core packages. It usually takes at
>> least a week, and an extra bump, and coaxing. The process isn't
>> fire-and-forget, so I have to spend time each day thinking about packages I
>> currently have awaiting signoffs and what has happened to them and whether
>> or not I need to take some action.

Didn't we go through this a month or two back?  As an aside, paclist 
from pacman-contrib is very handy for remembering signoffs.  "paclist 
testing" shows you the packages you have installed from [testing].

>> 2) Signoff threads are hijacked for a general discussion about the package.
>> This is annoying because it happens AFTER the developer has done all the
>> work teeing up the new package, testing it himself on both environments,
>> writing up the signoff, doing the coaxing, watching the signoff thread. Once
>> the thread is hijacked, it becomes even more difficult for those who would
>> sign off to figure out the state of the signoff.
>>
>> All this has the effect of filibustering progress in core and discouraging
>> people from doing work on core packages.
>>
>> There are a number of potential solutions to this problem-- perhaps some of
>> you will think of others. Here are two that come to mind:
>>
>> 1) Get a web signoff mechanism to really work for us. We'd have to evaluate
>> why the previous web mechanism wasn't embraced and solve the problems with
>> it. This would require some more work in archweb, which I could probably do
>> if we thought it was the right approach.
>
> Problems with the current web signoff (some might be in bug tracker):
>
> - notification. There should be a text box where you write the package
> modifications then click on a button. That would send an automatic
> signoff message (standard blurb with text box contents) to the dev
> public (or aur in case of community packages) ML to inform devs about
> the pending signoff and package changes.
>
> - currently there is no way to flag a package as broken on the web signoff.
>
> - you can't unsign-off a package.  In the case you sign-off the wrong
> package by accident or notice a problem after signing-off, you can't
> revert it.
>
> - the packages are ordered alphabetically so core packages are mixed
> up with extra and community packages. We should be able to sort by
> repo.
>
> - sometime you want to add extra information when signing off, like
> what on what setup you tested, what part of the package you tested or
> on how in-depth you tested. A short text box on the signoff page might
> be useful.
>
> - users signoff. Some low-usage packages benefit from users signoff.
> Maybe we could add a feature where a dev could enter a user name
> and/or email and signoff for a user.

The biggest problem I see is that I rarely visit the webpage, whereas I 
visit my email inbox several times an hour.  So switching to web-base 
signoffs requires people to go out of their way and is going to reduce 
visibility and require even more chasing people.

How we know a signoff is needed is another interesting issue...  The 
suggestion is to have the web interface automatically send an email to 
the list.  But instead of clicking reply, we a required to boot up a web 
browser, navigate to the correct page and enter our response there. 
That is just tedious.

>>
>> 2) A pre-signoff thread for each signoff. You run this thread before you do
>> any packaging work, so that if someone wants to discuss other things about
>> the package and suggest other modifications, they do it without causing you
>> a whole lot of extra work. We then agree not to hijack signoff threads for
>> unrelated aspects of the package-- rather, we start other threads or open
>> new bug reports.
>
> That would be a good idea. This way the package will be done right the
> first time.

If you can not get packaging done right first time, do not do it.  I 
maintain ~40 packages in [core] and there is no way I am going to post a 
message asking permission to update them.  But if you want to make a big 
change that is worthy of discussion then do so.

I agree discussing changes is useless in signoff threads unless they are 
regressions.  All other requests should go to the bug tracker. And we 
should just point people there and move on.

Allan