On 02/09/2010 03:49 AM, Allan McRae wrote:
On 09/02/10 18:38, Jan de Groot wrote:
These days it looks like almost nobody in our developer team uses i686 anymore. I still have a laptop running it, but I barely use it.
I think both architectures are an issues, although I agree i686 is worse. There is rarely a signoff without requiring a bump these days.
As an aside, in the last month there has been five devs signoff for i686 (me, Eric, Andrea, Vesa, Dan), but I was surprised to see three of these still used i686...
I think it's time to revise our signoff policy. I was thinking about making it a bit more flexible:
- signoff by 3 devs, no matter what architecture, and no bugs within 3 days -> move - signoff for both architectures, 2 each -> move - no signoff, no bugs for a week -> move
Sounds fine to me. I know several of us give a "signoff" after a week if there appears to be no issues whether or not we use the package...
For the last thing to get implemented, this can be a bit tricky. Sometimes developers throw something in testing, just to test something, and it sits there for weeks without anyone knowing why it's in testing. I would like to have every package that goes to testing getting committed with a reason in the commit message. This way we can find out why something is in testing and if we can easily move it out without breaking things.
Good commit messages should make the reason for testing clear anyway.
One thought to add: I think the signoffs are more useful as a "sanity check" than a test of the newly-implemented functionality. I think the primary benefit of signoffs is catching obvious regressions, more than making sure we, in fact, did close bug #83446 completely and correctly. It's still good to have descriptive commit messages, but I think lately we've been trying too hard to test the specific thing(s) in the commit message, rather than using it as a clue as to what to sanity check. That's extra benefit when people do it, but extra obstacle to getting signoffs done if people feel obliged to replicate the precise set of test conditions necessary to fully test a fix. - P