[arch-dev-public] improving signoffs

Paul Mattal paul at mattal.com
Sat Mar 13 15:41:54 CET 2010


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.

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.

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

- P


More information about the arch-dev-public mailing list