Commit Queue is back online. Please let me know if you notice any issue.
Thanks
Aakash
> On Jul 28, 2021, at 1:27 PM, Aakash Jain wrote:
>
> Hi Everyone,
>
> We just took commit-queue bots offline for some maintenance. I will send
> another update when they are back online.
>
> Thanks
>
Hi Everyone,
We just took commit-queue bots offline for some maintenance. I will send
another update when they are back online.
Thanks
Aakash
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
There were intermittent issues with Commit Queue even after adding the retries
and few other fixes. The issue was related to git-svn specifically with our
GitHub repo and caused intermittent failures while trying to push the commits
to WebKit svn repository. We have now moved Commit Queue bots
Most of the issues with commit-queue were fixed. We also added automatic
retries in commit-queue to better handle intermittent issues (in
https://webkit.org/b/222038).
Please let me know if anyone notices any issue.
Thanks
Aakash
> On Feb 4, 2021, at 4:39 PM, Aakash Jain wrote:
>
> We are
We are noticing intermittent issues with Commit-Queue failing to commit, since
we moved it to github. We are looking into it. Meanwhile, if Commit-Queue fails
on your patch, you can set cq+ again to retry.
Thanks
Aakash
> On Jan 19, 2021, at 4:56 PM, Aakash Jain wrote:
>
> All the issues
Hi,
now everything is broken again. :(
trac.webkit.org:
-
OperationalError: could not connect to server: Connection timed out
Is the server running on host "data.macosforge.org" and accepting
TCP/IP connections on port ?
bugs.webkit.org:
-
02 сент. 2015 г., в 5:41, Philippe Normand написал(а):
> It seems the commit queue cannot land patches?
>
> https://bugs.webkit.org/show_bug.cgi?id=148702
This should be resolved now. I see that you already marked this patch for cq+
again; I'll see if any others are stuck.
> 2 сент. 2015 г., в 9:59, Alexey Proskuryakov написал(а):
>
>
> 02 сент. 2015 г., в 5:41, Philippe Normand написал(а):
>
>> It seems the commit queue cannot land patches?
>>
>> https://bugs.webkit.org/show_bug.cgi?id=148702
>
> This should be resolved
Hi,
It seems the commit queue cannot land patches?
https://bugs.webkit.org/show_bug.cgi?id=148702
Philippe
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
Looks like there is a real build failure here. I've filed
https://bugs.webkit.org/show_bug.cgi?id=134152 with a patch.
- R. Niwa
On Fri, Jun 20, 2014 at 8:55 AM, Lucas Forschler lforsch...@apple.com
wrote:
I will investigate... starting by power cycling the bots...
Lucas
On Jun 20, 2014,
Hi All,
it seems WebKit commit queue is stucked, because the last pass was
14 hours ago: http://webkit-queues.appspot.com/queue-status/commit-queue
All patch fails with Unable to build without patch [results] message:
I will investigate… starting by power cycling the bots…
Lucas
On Jun 20, 2014, at 12:52 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:
Hi All,
it seems WebKit commit queue is stucked, because the last pass was
14 hours ago: http://webkit-queues.appspot.com/queue-status/commit-queue
This problem appears to have been worked out over the weekend. The commit
queue should be working as expected by now.
- R. Niwa
On Fri, Oct 11, 2013 at 9:53 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
It appears that the machines running commit queue cannot reach
svn.webkit.org due to
https://bugs.webkit.org/show_bug.cgi?id=122534
Not sure why this one failed to commit. Rebased just incase, but nothing
indicates that this is an issue with the patch (at least to me). Possibly
related?
Thanks for taking a look.
- Sam
On Oct 14, 2013, at 10:45 AM, Ryosuke Niwa
It appears that some CQ and EWS bots are still experience some issues.
Please re-set cq+ should CQ fails to land your patch.
- R. Niwa
On Mon, Oct 14, 2013 at 3:44 PM, Samuel White samuel_wh...@apple.comwrote:
https://bugs.webkit.org/show_bug.cgi?id=122534
Not sure why this one failed to
Hi,
It appears that the machines running commit queue cannot reach
svn.webkit.org due to some network issues. Please land patches manually
until a further notice.
If you're not a committer yet, please reply to this thread with a bug
number and I'll land it manually for you (as long as it has
Hi there,
The commit queue is stuck and 19 patches are now pending. Looks like the
problem started about 8 hours ago.
Thanks,
Robert
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Looks like the commit queue didn't handle the SVN outage gracefully.
Have restarted the bots; they're up and running again now.
Thanks for the notification.
- Alan Cutter
On Wed, Mar 27, 2013 at 13:52:49 PDT, Robert Hogan wrote:
Hi there,
The commit queue is stuck and 19 patches are now
Hi,
It appears the commit queue stopped working due to lack of disk space:
https://bugs.webkit.org/show_bug.cgi?id=107680#c8
Failed to run ['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch',
'--status-host=queues.webkit.org', '--bot-id=gce-cq-04',
'apply-attachment', '--no-update',
Thanks for the note. We seem to have a temp file leak in
run-webkit-tests. I'm rebuilding the machines now.
Adam
On Thu, Jan 24, 2013 at 10:03 AM, Dumez, Christophe
christophe.du...@intel.com wrote:
Hi,
It appears the commit queue stopped working due to lack of disk space:
If Chromium DRT crashes, it will leak temp files. Maybe run-webkit-tests
should try to clean these up?
On Thu, Jan 24, 2013 at 10:15 AM, Adam Barth aba...@webkit.org wrote:
Thanks for the note. We seem to have a temp file leak in
run-webkit-tests. I'm rebuilding the machines now.
Adam
Hi all,
As you might all know, the commit-queue uses chromium linux port.
Consequently, any JavaScriptCore and WebKit2 specific changes (and any
non-Chromium port specific changes) are never tested. Commit-queue doesn't
even detect whether it builds or not.
This is a source of confusion because
The solution I'd recommend is to make the JavaScriptCore and/or
WebKit2 bots faster. If those bots are able to complete their
processing before the commit-queue, then they'll stop the patch from
being committed by marking the patch commit-queue-.
Adam
On Thu, Jan 10, 2013 at 9:22 PM, Ryosuke
I believe the CQs are back up and running. Adam moved them to
git.webkit.org for the time-being (they were using git.chromium.org as
a mirror). Stefan is investigating our mirror to understand what went
wrong. Sorry for the troubles.
http://queues.webkit.org/queue-status/commit-queue
On Tue,
There's some problem with the commit-queue failing with some git
error. I'm taking it offline for the rest of the day. Hopefully I'll
figure it out tonight.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
An example of the git failures can be found here:
http://queues.webkit.org/results/15120956
(For any with git-knowledge who might know what's wrong.)
On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote:
There's some problem with the commit-queue failing with some git
error.
On Tue, Dec 4, 2012 at 12:39 PM, Eric Seidel esei...@google.com wrote:
An example of the git failures can be found here:
http://queues.webkit.org/results/15120956
(For any with git-knowledge who might know what's wrong.)
On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote:
Hi,
Is it possible if http://git.chromium.org/external/Webkit
is broken? Or somebody pushed non fast forward commits?
Maybe a manual kick can help:
git reset --hard HEAD~1000
git clean -dxf
git pull
These lines always helped me if something went wrong on my git repository.
Ossy
Eric Seidel
Both the commit hashes mentioned in the log appear to be real hashes
from today, about ten revisions apart. I'm not enough of a git expert
to understand what's going on.
Adam
On Tue, Dec 4, 2012 at 2:49 PM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:
Hi,
Is it possible if
Argh, yeah. Unfortunately, I'm not sure what triggers this problem.
It's easy enough to fix as soon as I can find someone w/ access to the
CQ.
-- Dirk
On Tue, Nov 13, 2012 at 7:50 AM, Adam Barth aba...@webkit.org wrote:
Sounds related to a recent changed made by dpranke.
Adam
On Tue, Nov
I'm seeing the same on the Android bot. What is the right way to fix this?
Cheers,
Peter
On 13 Nov 2012 18:31, Dirk Pranke dpra...@chromium.org wrote:
Argh, yeah. Unfortunately, I'm not sure what triggers this problem.
It's easy enough to fix as soon as I can find someone w/ access to the
CQ.
Hi,
It seems CQ is stucked 2 days ago:
http://queues.webkit.org/queue-status/commit-queue
Is there anyone here to be able to kick it/them?
br,
Ossy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
Will do once I get a stable Internet connection (probably in an hour and a
half).
Adam
On Oct 15, 2012 4:10 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:
Hi,
It seems CQ is stucked 2 days ago: http://queues.webkit.org/**
Looks like the commit queue is sick. Can someone please check?
Cheers,
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Will do. Thanks.
On Tue, Aug 21, 2012 at 11:36 AM, Thiago Marcos P. Santos
tmpsan...@gmail.com wrote:
Looks like the commit queue is sick. Can someone please check?
Cheers,
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
I'm not really sure what's wrong with them, but I kicked off a job to
rebuild their VMs. Hopefully that will fix the problem.
Adam
On Tue, Aug 21, 2012 at 11:39 AM, Adam Barth aba...@webkit.org wrote:
Will do. Thanks.
On Tue, Aug 21, 2012 at 11:36 AM, Thiago Marcos P. Santos
Hi All,
I'm seeing the commit-queue bot
http://webkit-commit-queue.appspot.com/queue-status/commit-queue/bots/ec2-cq-02
consistently rebooting about every hour. I know I'm not the only one with a
patch that has commit-queue+ waiting for this to be resolved.
Can someone look into this
On Mon, Jan 23, 2012 at 11:07 AM, Konrad Piascik kpias...@rim.com wrote:
I'm seeing the commit-queue bot
http://webkit-commit-queue.appspot.com/queue-status/commit-queue/bots/ec2-cq-02
consistently rebooting about every hour. I know I'm not the only one with a
patch that has commit-queue+
On Mon, Jan 23, 2012 at 11:12 AM, Adam Barth aba...@webkit.org wrote:
On Mon, Jan 23, 2012 at 11:07 AM, Konrad Piascik kpias...@rim.com wrote:
I'm seeing the commit-queue bot
http://webkit-commit-queue.appspot.com/queue-status/commit-queue/bots/ec2-cq-02
consistently rebooting about every
We are getting this:
Attachment XXX did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/10728791
New failing tests:
svg/custom/linking-uri-01-b.svg
Can someone fix it?
-- Darin
___
webkit-dev mailing list
On Mon, Dec 5, 2011 at 3:43 PM, Darin Adler da...@apple.com wrote:
We are getting this:
Attachment XXX did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/10728791
New failing tests:
svg/custom/linking-uri-01-b.svg
Can someone fix it?
It looks like it's
On Mon, Dec 5, 2011 at 3:52 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Dec 5, 2011 at 3:43 PM, Darin Adler da...@apple.com wrote:
We are getting this:
Attachment XXX did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/10728791
New failing tests:
I noticed that the commit-queue is a lot zippier now. Thanks!
Nico
On Wed, Jun 8, 2011 at 1:57 PM, Adam Barth aba...@webkit.org wrote:
Update: The new commit-queue nodes run about 6x faster than the old
nodes (wow). We're now fully switched over and have re-allocated the
Mac Minis to the
CQ backlog is cleared.
Recent CQ changes of note:
1. The CQ now runs with --exit-after-N-failures=10 instead of 1.
2. The CQ now knows how to upload layout-test-results.zip files when
tests fail during a commit run.
3. The CQ can now land when the tree is red with up to 9 failures.
(Keeps a
On Fri, Apr 15, 2011 at 10:50 AM, Adam Barth aba...@webkit.org wrote:
That means we'd likely need to switch the commit-queue over to using one of
the Linux ports. The consequences of switching ports are somewhat difficult
to foresee, which is why we're being cautious.
While this might
The model we're working towards would involve running tests on some
sub-set of platforms (certainly mac!) before landing. This would
involve making the EWSes run tests and making the commit-queue
dependent on their output.
This is all in a very experimental stage at the moment.
-eric
On Fri,
The cq cluster is sick at the moment, after some changes I made
yesterday to teach it how to land when the tree is red with known
failures.
I'm working on bringing it back on line.
On the bright side, as of this morning queues.webkit.org will show you
how long its been offline. :)
The Commit Queue will be down as of this afternoon, as we have to move
the machine this weekend.
Any patches you mark cq+ this weekend will get landed early next week
(likely monday).
I'll reply to this thread once it's back up and running.
Sorry for any inconvenience.
-eric
Looks like it is stuck again, trying to land patch 62961 for the past 8
hours..
Is there any way to see the commit queue script output/console so we can
find out what is going wrong? At times it keeps retrying to land the same
patch multiple times and one of us removes the patch from the queue
It was hung due to https://bugs.webkit.org/show_bug.cgi?id=31500.
I've fixed it now.
Sorry, there isn't a way to see the console output easily. It logs
everything, I just don't post them all online as well as I should.
-eric
On Wed, Aug 4, 2010 at 6:11 AM, Satish Sampath sat...@chromium.org
Trying to land the same patch multiple times is expected behavior.
That happens when it can't decide whether the patch is good or bad
(e.g., because the tree is broken or because it's checkout gets out of
date before it's able to actually commit).
Adam
On Wed, Aug 4, 2010 at 6:11 AM, Satish
Agreed, though I have seen at times the same patch was retried 4 or 5 times.
Is that expected?
- Satish
On Wed, Aug 4, 2010 at 5:38 PM, Adam Barth aba...@webkit.org wrote:
Trying to land the same patch multiple times is expected behavior.
That happens when it can't decide whether the patch is
It was down for the last 36 hours due to Leopard bustage and moving
machines. It's back up and running again now. Apologies for (my
part) of the trouble.
http://queues.webkit.org/queue-status/commit-queue
-eric
___
webkit-dev mailing list
- CQ will block on the SL Release builder
- CQ will test on SL Release before committing.
Most users shouldn't notice or care.
Email me if you have questions.
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
Independently of the other long thread, I'd like to express my love of
the commit queue. It is actually quite a nice feature for someone like
myself who is off in a corner.
I don't want commit access. I'd rather my changes go through some
process like the commit queue to ensure that it doesn't
On Jul 9, 2010, at 3:38 AM, Alex Milowski wrote:
Being able to go around the commit queue means you can cheat. That
seems like something that should be reserved for more severe problems
where we know the process used by the commit queue will fail.
That is not how I see it at all. And calling
On Fri, Jul 9, 2010 at 3:39 PM, Timothy Hatcher timo...@apple.com wrote:
On Jul 9, 2010, at 3:38 AM, Alex Milowski wrote:
Being able to go around the commit queue means you can cheat. That
seems like something that should be reserved for more severe problems
where we know the process used by
On Fri, Jul 9, 2010 at 7:39 AM, Timothy Hatcher timo...@apple.com wrote:
Some of the glaring reasons I don't use the commit queue have been resolved
(svn blame mainly), but the fact that there is no control over when the path
lands is my chief reason.
I agree. When my patch has a potential
This is great! Thanks guys for putting this together. The dominance of
e...@webkit.org as the most prolific committer is about to come to an
end! :P
:DG
On Sat, Jun 26, 2010 at 8:56 PM, William Siegrist wsiegr...@apple.com wrote:
The Commit Queue now commits with its own account (commit-queue,
In the last 3 days the commit-queue has not been keeping up. Due
partially to tree redness, and partially to graphics card troubles on
the machine (https://bugs.webkit.org/show_bug.cgi?id=38912) . The
tree is green now, but I do not expect the commit-queue to be able to
keep up until we solve
I have a (non-sustainable) hack in place where I have downgraded the
version number on the commit-queue's CoreVideo.framework to trick
WebKit into disabling hardware compositing (due to radar 7969612), and
I've hacked the commit-queue not to run compositing/iframes tests
(since they fail when HW
http://trac.webkit.org/changeset/57532
http://trac.webkit.org/changeset/57534
My apologies. Investigating now.
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Turns out this was a regression from:
http://trac.webkit.org/changeset/57531
Will be fixed with:
https://bugs.webkit.org/show_bug.cgi?id=37528
This also breaks webkit-patch land until bug 37528 lands.
-eric
On Tue, Apr 13, 2010 at 3:06 PM, Eric Seidel e...@webkit.org wrote:
Fixed in http://trac.webkit.org/changeset/57550.
If your webkit-patch checkout is between r57531 and r57550
webkit-patch land will commit with an incorrect commit message.
Please update before using webkit-patch land.
-eric
On Tue, Apr 13, 2010 at 4:48 PM, Eric Seidel e...@webkit.org wrote:
http://home.introweb.nl/d/dodger/svnauthor.html
Could it be? Anyone know if that could actually work for changing
authorship after-the-fact?
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
Woh. Looks like this is the real deal:
https://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/svn-tweak-author.py
I'll work with Bill and see if we can wire up some magic. :)
-eric
On Wed, Mar 17, 2010 at 4:40 PM, Eric Seidel e...@webkit.org wrote:
Just as a warning: changing commits after the fact can cause
git.webkit.org to get out of sync (it can mirror before the username
change goes through). I don't think that's a reason to not make a
change like this, but it would be good to figure out how to handle
this before you make it live.
On
The only time I've ever had an issue with committing is when I forgot to add
the file myself. The bot uses the same scripts that committers do. I think
it'd be worth your time to become comfortable with them. If nothing else,
so you can land fixes for when you break the build. It also frees up
The only time I've ever had an issue with committing is when I forgot to add
the file myself. The bot uses the same scripts that committers do. I think
it'd be worth your time to become comfortable with them. If nothing else,
so you can land fixes for when you break the build. It also frees up
On Thu, Feb 25, 2010 at 5:26 AM, Jeremy Orlow jor...@chromium.org wrote:
It also frees up the queue for those who need it.
A common misconception, but looking at the logs the commit-queue looks
to be no where near capacity. I believe it could commit every change
done to WebKit in a day and
I agree with Jeremy and David. If you are a committer you should try to land
patches on your own when you can. I mainly think this because it lets svn/git
blame work as intended instead of always blaming who ran the bot. Maybe we
should have a commit-...@webkit.org user?
On Feb 25, 2010, at
Also, I think that the argument that the (common) commit-queue breaks
annotate is not really accurate.
The commit-queue does change what user name it puts next to the line
in the default annotate view (in the command line)[1]. But the
username in that view is almost entirely useless (at least
Adam Barth pointed out that the commit queue has been blocked for
about 20 hours. Looking at the reason why:
editing/undo/undo-deleteWord.html - failed
editing/undo/undo-iframe-location-change.html - failed
If you have made changes in this area recently, could you please fix
these test failures?
Actually, it doesn't appear to be do to recent changes in this area. They
started failing after r55177 (
http://build.webkit.org/waterfall?last_time=1266975298), but that change is
unrelated to these test as far as I can tell.
I suspect it has to do with shuffling around of tests, so it just
On 24.02.2010, at 11:47, David Levin wrote:
Actually, it doesn't appear to be do to recent changes in this area.
They started failing after r55177 (http://build.webkit.org/waterfall?last_time=1266975298
), but that change is unrelated to these test as far as I can tell.
It looks unrelated,
On Wed, Feb 24, 2010 at 12:02 PM, Alexey Proskuryakov a...@webkit.org wrote:
On 24.02.2010, at 11:47, David Levin wrote:
Actually, it doesn't appear to be do to recent changes in this area. They
started failing after r55177
(http://build.webkit.org/waterfall?last_time=1266975298), but that
1. It looks like you are a committer, so you don't need to wait for the
commit queue to do this for you :)
2. But it still would be good to have this fixed. If you'd like to help move
this along, you can go to http://build.webkit.org/waterfall and find which
patch caused the test to start
I find http://build.webkit.org/console more useful.
In this case, looks like mitz's patch changed the test:
http://trac.webkit.org/changeset/55203
I'm glad to see more folks are watching the bots!
-eric
On Wed, Feb 24, 2010 at 3:48 PM, David Levin le...@chromium.org wrote:
1. It looks like
That test is kinda tricky. The change isn't necessarily wrong. But
the patch appears to have changed what the DOM tree looks like (at
least in order) and thus exposed bugs in our JS bindings where some
objects aren't being created with the proper prototype chains.
Our JS bindings get cached
On Wed, Feb 24, 2010 at 3:48 PM, David Levin le...@chromium.org wrote:
1. It looks like you are a committer, so you don't need to wait for the
commit queue to do this for you :)
Understood -- but I prefer to use the bots where possible. I've seen
multiple instances where the commit scripts
What is a possible resolution? Can we temporarily disable the test to
unblock the commit queue?
-Ken
On Wed, Feb 24, 2010 at 3:53 PM, Eric Seidel e...@webkit.org wrote:
That test is kinda tricky. The change isn't necessarily wrong. But
the patch appears to have changed what the DOM tree
On Feb 24, 2010, at 3:50 PM, Eric Seidel wrote:
I find http://build.webkit.org/console more useful.
In this case, looks like mitz's patch changed the test:
http://trac.webkit.org/changeset/55203
Sorry about the inconvenience. I will try to fix this shortly.
I'm glad to see more folks
If you're wondering why your cq+'d patch hasn't landed, it's because
we're behind again. 21 patches in the queue. Again, mostly due to
the tree being red for an extended period this weekend (and today).
The queue should catch up over night.
-eric
On Wed, Jan 27, 2010 at 1:31 PM, Eric Seidel
The tree was torched again this evening. :( The builders got way way
way behind. I cleared the slow ones just now. I expect them to roll
green and the commit-bot to start landing while we sleep. :)
-eric
On Tue, Jan 26, 2010 at 5:55 PM, Eric Seidel e...@webkit.org wrote:
Sorry, the
The commit queue caught up over night, and is operating normally
again. (aka if build.webkit.org is green, then your patch should be
landed within 15 minutes of setting cq+)
Thanks for your patience.
-eric
On Wed, Jan 27, 2010 at 3:12 AM, Eric Seidel e...@webkit.org wrote:
The tree was
Sorry, the commit-queue got behind today (currently 19 patches in the
queue) due to the bots being red much of the day and whole bunch of
reviewing. :)
http://build.webkit.org/console
It should catch up over night.
Thanks for your patience.
-eric
___
In case you're wondering why your commit-queue+'d patch has not landed yet...
http://webkit-commit-queue.appspot.com/
will now tell you. It needs work, but it's better than nothing.
The code will soon be in SVN and patches are most welcome:
https://bugs.webkit.org/show_bug.cgi?id=29307
-eric
So awesome - thanks for doing this, Eric.
It says it's blocked because the builders are red - is it just looking for
compile status across all platforms, or does it actually wait for all unit
tests to be green, or just some subsets of the Mac unit tests, or what?
-atw
On Fri, Sep 18, 2009 at
Yup, clearly it needs to show more information. :)
The commit-queue calls core_builders_are_green() which you can see
the source of here:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/modules/buildbot.py#L86
Right the commit-queue is blocked by any Leopard builder/tester or any
Adam Barth announced last week that he'd wrapped bugzilla-tool in a
shell-script and created the commit-queue. We're now running this queue
every day, but not overnight yet.
The commit-queue script is super-simple. It wakes up every 10 minutes and
runs:
bugzilla-tool bugs-to-commit | xargs -n1
90 matches
Mail list logo