[oe] [RFC] more streamlined review procedure, was: Re: [STABLE] branch created: stable/2009

Koen Kooi k.kooi at student.utwente.nl
Thu Apr 2 17:31:28 UTC 2009


On 02-04-09 17:31, Marco Cavallini wrote:
> Koen Kooi ha scritto:
>> I've found that there's a huge flaw in this setup:
>>
>> Currently there are 8 people signed up as 'maintainers' for the stable
>> branch, but only 2 (yes, two) have looked at some of the patches posted
>> 2 days ago. Another said he didn't want to look at patches for machines
>> he didn't build for. No idea why the other 4 haven't responded, but if
>> this continues then the stable branch can be closed down immediately.
>>
>> Why? The current procedure requires an ACK from a stable 'maintainer'
>> (not including yourself, of course), but you won't get an ACK or even a
>> NACK.
>>
>> This is annoying since I've had the first bugreports from users that
>> were solved by patches that are 'under review'.
>>
>> The previous stable branch tried to guarantee that you'd get at least a
>> reaction on all your patches within 24 hours, so submitters knew what
>> was happening. A 'reaction', not a 'review', so "will look at it next
>> week" is perfectly well.
>>
>> So my proposal:
>>
>> * within 24 hours of posting at least 1 reaction from any stable
>> 'maintainer'
>> * No review within a week means automatic approval, commit must have
>> "UNREVIEWED" marker to signify that.
>
> Hi
> I'm trying to understand the best way to proceed.
> I think you shouldn't ACK a patch that you can't test.
> Maybe I'm wrong or I'm misunderstanding the goal of a 'stable' branch?

It seems you didn't read http://wiki.openembedded.net/index.php/Stable:

"It is important to note that we will test for building. Testing on 
target devices is left for users which can (and should) report bugs if 
something is not working. More about reporting bugs later in that text."

There's no "can't" when it comes for testing for the stable branch.

regards,

Koen

PS: I do think we should test on a target device whenever possible





More information about the Openembedded-devel mailing list