[webkit-dev] A bot-filled future?

[Brian Weinstein]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091112/e0c8120d/attachment.html>