[arch-dev-public] package signoffs

[Paul Mattal]

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