[webkit-dev] Towards a commit-queue

[Jeremy Orlow]

On Sat, Aug 1, 2009 at 11:45 AM, Ojan Vafai <ojan at chromium.org> wrote:

> On Sat, Aug 1, 2009 at 2:08 PM, Adam Barth <abarth at webkit.org> wrote:
>
>> On Sat, Aug 1, 2009 at 11:04 AM, David Kilzer<ddkilzer at webkit.org> wrote:
>> > Bugzilla has the ability to create additional 4-state flags at both the
>> attachment level and at the bug level.  (Note that bugs.webkit.org does
>> not have bug-level flags enabled.)
>> >
>> > For example, we could create a "commit" attachment flag which would have
>> four states (just like the "review" flag):  <none>, commit?, commit+,
>> commit-.
>> >
>> > I'm not sure if this helps or hurts, though it would have made abarth's
>> desired workflow much nicer.
>>
>> Yeah, that sounds great.  Should we try that out for a while and see
>> if it's useful?
>
>
> This seems fine to me, except it adds yet another layer of complexity to
> the review process. I think getting patches landed more quickly is probably
> worth it though. This is essentially a slightly more complicated (but easier
> to implement?) version of Maciej's proposal from a few weeks ago to get rid
> of r* and have the following four review states:
>
> REQUESTED
> DENIED
> APPROVED WITH MODIFICATIONS
> APPROVED
>

It seems to me that the only difference is APPROVED becomes READY TO LAND
(or LANDABLE or something like that).


Btw, I see one downside to a commit queue:  When you manually commit
something, you're supposed to watch the build bots for breakage.  If the
submit queue is running all the tests on all the platforms then it doesn't
really matter, but if not there'll need to be automated rollbacks when
things break on the waterfall build bots.  This could easily become
complicated if the commit queue can submit multiple patches before the
waterfall bots show green for the previous patch.

I guess the point that I'm trying to make is that tests should either be run
on every buildbot configuration, there needs to be some pretty robust
rollback code, or the queue needs to let everything cycle green before
committing the next patch.  The last suggestion seems like a good start.

Note also that, if the system rolls back a patch and the bots don't go back
to their previous state, the submit bot needs to stop so someone can take a
look manually (so things don't get further hosed).

One benefit over the above is that, I don't think we need to restrict
> commit+ to people with svn commit bit, as long as a patch is r+'ed or r+'ed
> with modifications.
>
> Ojan
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090801/f7fd1ac7/attachment.html>