[webkit-dev] A bot-filled future?

[Ojan Vafai]

This approach doesn't lend itself as well to trying patches before putting
them up for review. Specifically, I want to be able to  try patches without
spamming everyone with bugzilla mail. This is solvable in this
bugzilla-based approach, but it doesn't lend itself to this as
naturally, e.g. presumably there's a way to tell bugzilla not to send mail
for a given comment.

Also, it would be great if the commit-queue, try-server, whatever, had a UI
like the buildbot waterfall. There's a couple advantages:
1. Can see the stdio as the tests run and get better information about why
it failed.
2. Can grab layout test results from the try servers. This would reduce the
need/occurence of committing Mac expectations and then cleaning up other
platforms post commit.

Ojan

On Thu, Nov 12, 2009 at 12:58 PM, Brian Weinstein <bweinstein at apple.com>wrote:

> Seconded (or Thirded). I'd been working on a try-server using Chromium's
> try-change.py, but this seems like a much cleaner way to handle it, and ties
> into the Bugzilla workflow much better than my solution, and would be much
> easier to limit who can set the try bit, based on what we decide the policy
> to be.
>
> On Nov 12, 2009, at 12:41 PM, Jeremy Orlow wrote:
>
> It's so easy to have code that builds on one platform but not another.
>  Even if the try servers were only builders to begin with, I think they'd
> provide a lot of value to the project.
>
> On Thu, Nov 12, 2009 at 11:43 AM, Kenneth Christiansen <
> kenneth.christiansen at openbossa.org> wrote:
>
>> I think that sounds like a really good idea, and I can see my self
>> using that when touching cross platform code.
>>
>> Kenneth
>>
>> On Thu, Nov 12, 2009 at 4:37 PM, Adam Barth <abarth at webkit.org> wrote:
>> > As the project grows, we need to scale our processes to match.  In
>> > large part, that means automating as much work as possible.
>> > Commit-queue has done a good job of solving the "land patches from
>> > non-committers efficiently" problem, effectively removing that as a
>> > pain point.  I'd like to ask you to open your hearts and your minds to
>> > the idea of automating more of our processes.
>> >
>> > Currently, I see the biggest pain-point in our process as the
>> > always-burgeoning pending-review list.  It's difficult to automate the
>> > process of accepting good patches because that requires attention from
>> > experts.  Instead, I think we should make it easier to reject bad
>> > patches.  As a first step, I've started extending bugzilla-tool to be
>> > a try server in <https://bugs.webkit.org/show_bug.cgi?id=31422>.
>> > Here's how this might work:
>> >
>> > 1) Contributor posts patch for review.
>> > 2) Committer marks patch with the try? flag.
>> > 3) The try-queue downloads, applies, builds, and tests the patch.
>> > 4) If all systems are go, the try-queue marks the patch as try+.
>> > Otherwise, it marks the patch as try- with an explanation of what went
>> > wrong.
>> >
>> > The try-queue will be purely optional and advisory.  Hopefully a try-
>> > notation will encourage the contributor to post a new version of the
>> > patch that passes the try-queue.
>> >
>> > Further down the road, one can also imagine another bot that automates
>> > step (2) by scanning the pending-review list for untried patches and
>> > marking them as try? when the try-queue has unused bandwidth.
>> >
>> > Adam
>> > _______________________________________________
>> > webkit-dev mailing list
>> > webkit-dev at lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>>
>>
>>
>> --
>> Kenneth Rohde Christiansen
>> Technical Lead / Software Engineer
>> Qt Labs Americas, Nokia Technology Institute, INdT
>> Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> 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/20091112/7ca32029/attachment.html>