[arch-dev-public] improving signoffs

[Eric Bélanger]

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.
>
> 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.


>
> 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.

>
> What do others think? Any other ideas for how to handle this?
>
> - P
>