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 <aba...@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.wei...@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@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev