[webkit-dev] The Purpose of Core Builders

Adam Barth abarth at webkit.org
Wed Nov 9 09:15:52 PST 2011

On Wed, Nov 9, 2011 at 9:07 AM, Patrick Gansterer <paroga at paroga.com> wrote:
> Am 09.11.2011 um 17:21 schrieb Adam Barth:
>> On Wed, Nov 9, 2011 at 2:47 AM, Patrick Gansterer <paroga at paroga.com> wrote:
>>> Some of my thought on this, since I have the same "problems" with my WinCE bot:
>>> 1) Is there any real benefit in the CoreBuilders concept (since it's not used as intended as Eric already wrote)?
>> If it were up to me, I'd remove the concept because causes me more
>> headaches than it's worth.  However, ggaren makes some good points
>> about why it's useful.  Hopefully having that wiki page will help.
> Sorry, but I don't see the benefit compared to the "is 90% green" solution.
>>> 2) When we still want the CoreBuilder concept: Can we make the core/non-core transition without any SVN change? What about improving the buildbot-master, so that it dertiminates the core/non-core on the fly, by checking the last x builds? I don't like the idea of adding and removing the the bots to the "core list" all the time.
>> I'd be happy to review such a change.  Practically, however, if
>> there's a configuration that a large number of developers use (e.g.,
>> apple-mac), it's probably worth having on the front page even if it's
>> red a lot.
> An alternative might be to split the bots into categories like "apple", "chrome", "qt" and so on instead of "core"/"non-core". But this won't help in catching problems on the "other" bots. So not sure if that is a practicable solution.
>>> 3) It's hard for non full time contributes to get informed about broken bots, if you don't watch the buildbot site the whole day.
>>>   a) Maybe we can tell the buildbot to write a mail to the build slave maintainer, when the bot is broken. (It happened more than once that my bot was red for days, because I didn't get informed about it).
>>>   b) I agree that keeping all bots green is not the task of the committer, but maybe someone should trigger the port maintainer to fix it. I have no idea about a general working rule, but as of my experience the committer simply "don't see" the problem. E.g. WinCE bot builds the interpreter version of JSC, which is a "core feature" and not port specific, but the commit author didn't see the break.
>> It's petty easy to write a webkit-patch command that monitors the bots
>> and files bugs when they fail or whatever.  If I were you, I'd just
>> write such a monitoring command rather than wait for other folks to
>> solve this problem for me.
> I don't want other folks to do "my work", I'm not happy, but ok with the current state. I wanted to add my view to this topic. :-) Maybe other folks have similar requirements, so that we find a more general solution, instead of many home brew ones.

My experience with threads like this is that they generate a bunch
talk but little action.  I'm encouraging you to take action to improve
your happiness.  If other folks have similar problems, I'm sure they
won't have any trouble jumping on your bandwagon.


More information about the webkit-dev mailing list