On Feb 26, 2010, at 12:11 PM, William Siegrist wrote:
On Feb 26, 2010, at 9:29 AM, Maciej Stachowiak wrote:
On Feb 26, 2010, at 9:17 AM, Dimitri Glazkov wrote:
To summarize the thread:
1) We're adopting "when in doubt, roll it out" approach to patches
that turn tree red.
I think it's po
On Fri, Feb 26, 2010 at 11:53 AM, Maciej Stachowiak wrote:
> On Feb 26, 2010, at 11:43 AM, Simon Fraser wrote:
>
2. The Mozilla tinderbox page (their buildbot waterfall) had a way for
> people to leave comments, by adding a "star" to a particular build with a
> comment. This is used as a way to c
On Fri, Feb 26, 2010 at 9:00 PM, Jeremy Orlow wrote:
> On Fri, Feb 26, 2010 at 8:53 PM, Maciej Stachowiak wrote:
>
>>
>> On Feb 26, 2010, at 11:43 AM, Simon Fraser wrote:
>>
>>
>>> Mozilla has (or at least had when I worked there) two additional "tree
>>> rules" that helped keep the tree green:
On Feb 26, 2010, at 9:29 AM, Maciej Stachowiak wrote:
>
> On Feb 26, 2010, at 9:17 AM, Dimitri Glazkov wrote:
>
>> To summarize the thread:
>>
>> 1) We're adopting "when in doubt, roll it out" approach to patches
>> that turn tree red.
>
> I think it's polite, though not mandatory, to make a r
On Fri, Feb 26, 2010 at 8:53 PM, Maciej Stachowiak wrote:
>
> On Feb 26, 2010, at 11:43 AM, Simon Fraser wrote:
>
>
>> Mozilla has (or at least had when I worked there) two additional "tree
>> rules" that helped keep the tree green:
>>
>> 1. A sheriff was appointed at all times, and had the autho
On Feb 26, 2010, at 11:43 AM, Simon Fraser wrote:
Mozilla has (or at least had when I worked there) two additional
"tree rules" that helped keep the tree green:
1. A sheriff was appointed at all times, and had the authority to
close the tree if there was significant build or test breakag
On Feb 26, 2010, at 11:34 AM, Geoffrey Garen wrote:
>> There is a non-trivial cost of this workflow on the rest of the team.
>> -keeps the commit-queue from running
>> -often results in new test failures going unnoticed because the tree is
>> already red
>> -we can't generally trust that all the
On Feb 26, 2010, at 11:34 AM, Geoffrey Garen wrote:
There is a non-trivial cost of this workflow on the rest of the team.
-keeps the commit-queue from running
-often results in new test failures going unnoticed because the
tree is already red
-we can't generally trust that all the tests shou
On Feb 26, 2010, at 11:08 AM, Alexey Proskuryakov wrote:
On 26.02.2010, at 10:15, Jeremy Orlow wrote:
I didn't even know it existed until now. Was there ever an email
sent out on this? If so, I missed it.
Buildbot used to announce results there, but it was a few years ago.
My recolle
> There is a non-trivial cost of this workflow on the rest of the team.
> -keeps the commit-queue from running
> -often results in new test failures going unnoticed because the tree is
> already red
> -we can't generally trust that all the tests should pass locally
I think all of the costs you li
On Fri, Feb 26, 2010 at 10:40 AM, Geoffrey Garen wrote:
> A lot of the proposals on this thread would interfere with this work flow:
>
> 1. Finish patch and get it working on local machine.
> 2. Check in, automatically test for compatibility on other machines and
> OS's in parallel, resolving une
On 26.02.2010, at 10:15, Jeremy Orlow wrote:
I didn't even know it existed until now. Was there ever an email
sent out on this? If so, I missed it.
Buildbot used to announce results there, but it was a few years ago.
My recollection is that when it worked, about half of active
committ
> It looks like the Qt build now requires Qt 4.6. Currently, the qt-ews
> is using Ubuntu Karmic (which has Qt 4.5). I'll upgrade the machine
> to Lucid, but, in the meantime, the qt-ews will be down.
http://trac.webkit.org/changeset/54854 should allow Qt 4.5 again.
--
Ariya
__
> The reason I used this mailing list is because this is a clear regression
> not just a build problem on my side. If proven otherwise, I am sorry.
Qt-specific stuff can be asked in the webkit-qt lists as well.
Regards,
--
Ariya Hidayat
http://www.linkedin.com/in/ariyahidayat
I didn't know that failing tests would block the commit queue. I saw they were
failing yesterday afternoon and I thought it was ok to wait until this morning
to fix them.
My apologies for the inconvenience.
I believe a reasonable approach to handle these situations is to try to contact
the perso
+ chromium-dev
bcc webkit-dev
On Wed, Feb 24, 2010 at 9:29 AM, Chris Fleizach wrote:
> Hi Chromium devs,
>
> I noticed in the latest Chromium beta it seemed that there was still no
> accessibility for the mac.
>
> It should be a fairly straightforward process of enabling accessibility.
>
> Pleas
> If my webpage have many links/URLs and if I clicked on a URL then browser
> loads that URL. Click event only gives (x,y) co-ordinates of clicked area. I
> want to explore that from (x, y) points how webkit find out the particular URL
> when we click on it.
This question is for webkit-help list,
I think it would be more productive to start with better systems for informing
people that they've broken something, and move on to rolling out patches
aggressively if informing people doesn't work.
It's not surprising that people neglect a red tree when they don't know about
it.
A lot of the
On Fri, Feb 26, 2010 at 7:06 PM, Maciej Stachowiak wrote:
>
> On Feb 26, 2010, at 9:56 AM, Alexey Proskuryakov wrote:
>
>
>> On 26.02.2010, at 9:29, Maciej Stachowiak wrote:
>>
>> I'd like it if we had an IRC bot that announced build breakage on
>>> #webkit.
>>>
>>
>>
>> Perhaps better yet, on #
On Feb 26, 2010, at 9:56 AM, Alexey Proskuryakov wrote:
On 26.02.2010, at 9:29, Maciej Stachowiak wrote:
I'd like it if we had an IRC bot that announced build breakage on
#webkit.
Perhaps better yet, on #webkit-build, as buildbot used to do.
In the past, no one ever joined #webkit-buil
On Feb 26, 2010, at 9:58 AM, Alexey Proskuryakov wrote:
On 26.02.2010, at 9:50, Jeremy Orlow wrote:
> I would re-write rule one as something like this:
> 1. Comment in the bugzilla bug when the build breaks. If there
is no
> bugzilla bug, comment in #webkit.
> 2. 15 minutes after the b
On 26.02.2010, at 9:50, Jeremy Orlow wrote:
> I would re-write rule one as something like this:
> 1. Comment in the bugzilla bug when the build breaks. If there
is no
> bugzilla bug, comment in #webkit.
> 2. 15 minutes after the break or 10 minutes after the comment, with
> no reply from
On 26.02.2010, at 9:29, Maciej Stachowiak wrote:
I'd like it if we had an IRC bot that announced build breakage on
#webkit.
Perhaps better yet, on #webkit-build, as buildbot used to do.
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webk
On Fri, Feb 26, 2010 at 6:47 PM, Dimitri Glazkov wrote:
> On Fri, Feb 26, 2010 at 9:44 AM, Eric Seidel wrote:
> > The bots take 15 minutes to cycle. The moment the build is broken,
> > thats FIX_TIME + BOT_CYCLE_TIME until their green again.
> >
> > I think we should cap the fix grace period at
On Fri, Feb 26, 2010 at 9:44 AM, Eric Seidel wrote:
> The bots take 15 minutes to cycle. The moment the build is broken,
> thats FIX_TIME + BOT_CYCLE_TIME until their green again.
>
> I think we should cap the fix grace period at something like 15
> minutes, that means no more than 30 minutes of
On Fri, Feb 26, 2010 at 8:55 AM, Adam Barth wrote:
> On Fri, Feb 26, 2010 at 8:47 AM, Alex Milowski wrote:
>> On Fri, Feb 26, 2010 at 8:19 AM, Adam Barth wrote:
>>> On Fri, Feb 26, 2010 at 7:24 AM, Alex Milowski wrote:
On Fri, Feb 26, 2010 at 7:17 AM, Eric Seidel wrote:
> On Fri, Feb
The bots take 15 minutes to cycle. The moment the build is broken,
thats FIX_TIME + BOT_CYCLE_TIME until their green again.
I think we should cap the fix grace period at something like 15
minutes, that means no more than 30 minutes of tree redness per break.
That might be too aggressive to start
On Fri, Feb 26, 2010 at 1:36 AM, Adam Barth wrote:
> 2) Require pre-commit vetting of patches. We have the resources to
>
> Here's how I would design the life and times of a patch:
>
> 1) Contributor uploads patch and nominates it for review.
> 2) Patch vetted by the EWS on numerous platforms.
>
On Feb 26, 2010, at 1:36 AM, Adam Barth wrote:
Not to point fingers, but we've been having trouble keeping
build.webkit.org green these past few weeks. As I write this message,
every platform is broken, again. As the project scales, polluting the
build with brokenness impacts more developers
Am 26.02.2010 um 18:17 schrieb Dimitri Glazkov:
To summarize the thread:
1) We're adopting "when in doubt, roll it out" approach to patches
that turn tree red.
2) Need to find a way to run Mac-EWS for non-committers.
3) Enable "build-break" emails to webkit-dev or another opt-in
mailing list
On Feb 26, 2010, at 9:17 AM, Dimitri Glazkov wrote:
To summarize the thread:
1) We're adopting "when in doubt, roll it out" approach to patches
that turn tree red.
I think it's polite, though not mandatory, to make a reasonable effort
to find the person responsible for the breakage and giv
Personally, I've found those kind of changes are responsible for
a disproportionate percentage of build errors and bugs. :-)
On Fri, Feb 26, 2010 at 5:16 PM, Darin Adler wrote:
> On Feb 26, 2010, at 1:42 AM, Jeremy Orlow wrote:
>
> > Did you run the layout tests at all?
>
> Oliver already said
To summarize the thread:
1) We're adopting "when in doubt, roll it out" approach to patches
that turn tree red.
2) Need to find a way to run Mac-EWS for non-committers.
3) Enable "build-break" emails to webkit-dev or another opt-in mailing list
What else?
:DG<
On Fri, Feb 26, 2010 at 9:08 AM, A
Well, the total bill is a bit bigger, but yeah. :)
Adam
On Fri, Feb 26, 2010 at 9:05 AM, Kenneth Christiansen
wrote:
> That is some of the best 9 cents spend ever!
>
> Kenneth
>
> On Fri, Feb 26, 2010 at 1:58 PM, Adam Barth wrote:
>> On Fri, Feb 26, 2010 at 8:55 AM, Adam Barth wrote:
>>> Ama
That is some of the best 9 cents spend ever!
Kenneth
On Fri, Feb 26, 2010 at 1:58 PM, Adam Barth wrote:
> On Fri, Feb 26, 2010 at 8:55 AM, Adam Barth wrote:
>> Amazon tells me that our current bots use about 4 GB/month of download
>> bandwidth and 600 MB/month of upload bandwidth. I presume al
On Fri, Feb 26, 2010 at 8:55 AM, Adam Barth wrote:
> Amazon tells me that our current bots use about 4 GB/month of download
> bandwidth and 600 MB/month of upload bandwidth. I presume almost all
> of the bandwidth is to update the working copies of the four bots
> hosted there.
In case you're cu
On Fri, Feb 26, 2010 at 8:47 AM, Alex Milowski wrote:
> On Fri, Feb 26, 2010 at 8:19 AM, Adam Barth wrote:
>> On Fri, Feb 26, 2010 at 7:24 AM, Alex Milowski wrote:
>>> On Fri, Feb 26, 2010 at 7:17 AM, Eric Seidel wrote:
On Fri, Feb 26, 2010 at 7:12 AM, Alex Milowski wrote:
>> The only
On Fri, Feb 26, 2010 at 8:19 AM, Adam Barth wrote:
> On Fri, Feb 26, 2010 at 7:24 AM, Alex Milowski wrote:
>> On Fri, Feb 26, 2010 at 7:17 AM, Eric Seidel wrote:
>>> On Fri, Feb 26, 2010 at 7:12 AM, Alex Milowski wrote:
> The only EWS which requires committer access is Mac-EWS. All other
>
On Fri, Feb 26, 2010 at 7:24 AM, Alex Milowski wrote:
> On Fri, Feb 26, 2010 at 7:17 AM, Eric Seidel wrote:
>> On Fri, Feb 26, 2010 at 7:12 AM, Alex Milowski wrote:
The only EWS which requires committer access is Mac-EWS. All other
EWS bots will run any patch.
>>>
>>> Why is that? T
On Feb 26, 2010, at 1:42 AM, Jeremy Orlow wrote:
> Did you run the layout tests at all?
Oliver already said that he did, but before he made the small last minute
change that caused the crash.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.
On Fri, Feb 26, 2010 at 7:17 AM, Eric Seidel wrote:
> On Fri, Feb 26, 2010 at 7:12 AM, Alex Milowski wrote:
>>> The only EWS which requires committer access is Mac-EWS. All other
>>> EWS bots will run any patch.
>>
>> Why is that? That's the platform I'm most interested in see run.
>
> Various
On Fri, Feb 26, 2010 at 7:12 AM, Alex Milowski wrote:
>> The only EWS which requires committer access is Mac-EWS. All other
>> EWS bots will run any patch.
>
> Why is that? That's the platform I'm most interested in see run.
Various reasons. Mostly due to our current hardware setup. If
someo
On Fri, Feb 26, 2010 at 7:09 AM, Eric Seidel wrote:
> On Fri, Feb 26, 2010 at 4:14 AM, Kenneth Christiansen
> wrote:
>>> 1) Contributor uploads patch and nominates it for review.
>>> 2) Patch vetted by the EWS on numerous platforms.
>>
>> When a non-committer uploads a patch, it is not being vet
On Fri, Feb 26, 2010 at 4:14 AM, Kenneth Christiansen
wrote:
>> 1) Contributor uploads patch and nominates it for review.
>> 2) Patch vetted by the EWS on numerous platforms.
>
> When a non-committer uploads a patch, it is not being vet by EWS. I
> know that is due to security issues. It would be
> 1) Contributor uploads patch and nominates it for review.
> 2) Patch vetted by the EWS on numerous platforms.
When a non-committer uploads a patch, it is not being vet by EWS. I
know that is due to security issues. It would be really nice with an
option for a reviewer to accept it to run on the
On Fri, Feb 26, 2010 at 11:36 AM, Adam Barth wrote:
> Not to point fingers, but we've been having trouble keeping
> build.webkit.org green these past few weeks. As I write this message,
> every platform is broken, again. As the project scales, polluting the
> build with brokenness impacts more d
On Fri, Feb 26, 2010 at 10:36 AM, Adam Barth wrote:
> Not to point fingers, but we've been having trouble keeping
> build.webkit.org green these past few weeks. As I write this message,
> every platform is broken, again. As the project scales, polluting the
> build with brokenness impacts more
On Fri, Feb 26, 2010 at 12:03 AM, Oliver Hunt wrote:
> But any regressions would have been blamed on eric.
>
His name would show up in the SVN log, sure, but I don't think that'd fool
your average WebKit developer for long.
webkit-patch land does the correct thing, but i disable the testing pri
Not to point fingers, but we've been having trouble keeping
build.webkit.org green these past few weeks. As I write this message,
every platform is broken, again. As the project scales, polluting the
build with brokenness impacts more developers and drains more
productivity.
Here are some approa
49 matches
Mail list logo
