[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