[webkit-dev] Landing your own patches

[Julie Parent]

It seems like if you are a committer, you should still be able to use the
commit queue, you just need to do it responsibly.  If the problem is with
people setting the bit and walking away, why not include a warning to the
effect of: "Setting commit-queue+ is equivalent to svn commit" so it is
understood that you should follow the same policies when setting the bit as
you do when committing manually?  For example, my workflow is as follows:

   1. Check the status of the commit queue to make sure it isn't busy and is
   ready to accept my patch
   2. Make sure I'm logged into #webkit
   3. Set commit-queue+
   4. Wait ... watch for IRC notifier for my commit (simple notifier set up
   on my username)
      1. If my commit doesn't go through and I need to leave my desk, set
      commit-queue- so it doesn't commit while I'm away.
      5. Watch the tree and make sure there was no issues

If anything, I'm being a better citizen because I'm running the tests on
both Windows (locally) and Mac (commit-queue) before submitting.  (Agreed
that this is the wrong tool, try severs would be better, but in the absence
of try servers, I don't see how I'm causing harm by using commit-queue).

Julie

On Wed, Oct 14, 2009 at 12:38 AM, Adam Barth <abarth at webkit.org> wrote:

> Has this actually been a problem?  I know the commit-queue broke
> something today when landing a patch for Evan Martin, but he was on
> IRC and I made sure he was on the hook to watch the bots before I had
> to leave.  If I've landed things via commit-queue and not cleaned up
> after them, I certainly apologize.  Eric has talked about having the
> commit-queue watch the bots and send out email to the appropriate
> people when the commit-queue breaks something.
>
> What I see as more of a problem is the failing tests on Tiger and
> SnowLeopard the past few days.  Having red columns on the tree makes
> it harder to see when a new regression is introduced.  Looking at the
> tree, the issue seems to have been resolved.  If that was caused by
> the commit-queue, then I agree we should improve the commit-queue
> process.  If it was caused by someone committing their own patch, then
> I think we should improve the self-commit process.
>
> Adam
>
>
> On Tue, Oct 13, 2009 at 11:22 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
> > Hi WebKit Developers,
> > As nice as it may be to have a bot landing your patches, I think
> developers
> > who have a commit bit should try and make the effort to land their own
> > patches.  Mainly I think this is a good idea since the creator of the
> patch
> > has a much better chance of fixing the issue or quickly rolling it out if
> > they have to consciously commit and watch the bots.  It also, and perhaps
> > more importantly, places a lesser burden on the community who ends up
> doing
> > this job for them.
> > I understand the concern of those working on Windows who don't
> necessarily
> > have access to a Mac and I applaud your fear of breaking the build, but I
> > think in the end you are using the wrong tool (admittedly due to a lack
> of
> > trybots, but the commit bot will not run Qt or Gtk) and you are using it
> too
> > much (most patches probably won't break a build, unless you are named
> Dave
> > Hyatt).
> > Thanks,
> > -Sam
> > _______________________________________________
> > 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/20091014/192f9c65/attachment.html>