gerrit-buildbot master builds

[Bjoern Michaelsen]

Hi,

On Mon, Mar 25, 2013 at 06:28:57PM -0500, Norbert Thiebaud wrote:
> in any case is is _much_ simpler to manage what a box schedule is on
> each box than try to have a 'global scheduler'
> How are you going to manage autogen.lastrun from a remote centralize
> server... what happen when I run emerge --update
> and suddently I need to adjust the autogen, because the system libs is
> not compatbile anymore, etc....
> No, tinderbox need to be 'managed' by their owner(s), and they should
> have some autonomy to do that on their own, without having to involve
> a gerrit admin to tweak/fix things.. think 'bazaar' not 'cathedral'.

_If_ a box is that fragile, it shouldnt publish to the world at all, as with
20+ such tinderboxes the amount of false positives are overwhelming.

Essentially: Either you keep your builder stable enough so that it qualifies
for patch verification or you dont -- in the second case the results should not
go out unchecked to some public display or bulk email, but in a private
notification to the owner. Sending it to the public doesnt help -- it actually
hurts.

That doesnt mean we shouldnt have boxes test for cornercases and fringe
scenarios -- it just means results shouldnt be bestowed upon the public
without checking by the boxowner.

> 1/ such box maybe 'unreliable' because they are not always online...
> that does not necessarily mean that they are not-so-well maintained,
> just not dedicated.

In which case it just wouldnt pick up any tasks from a gerrit queue.

> 2/ it is quite possible not to spam people and still report build to
> the web site, heck one can even, today, setup a box that only spam
> oneself.

Self spamming is the only viable route to go, if there highened risks of
breakage due to the tinderbox, instead of the libreoffice source tree. But then
again, that has nothing to do with TDF infra anymore at that point.

> And here is a crux of the misunderstanding: neither the tinderboxes
> not the gerrit-patch-verification system is master-slave.

There is no misunderstanding there: Both are not master-slave, but both require
reliable builders. Thus they can and should be joined into one mechanism.

> ... I would never have been able to do that in a master slave system ...

How is that relevant, when the gerrit queue is explictly _not_ master-slave?

> So, provided the necessary dedicated hardware, then sure, we could
> have a whole scheme based on that model... but at that point the whole
> plugin is pointless since you can then simply use vanilla gerrit and
> jenkins to acheive that. the whole point of the gerrit plugin was to
> allow the client-server scheme.

See above: There is no intention to go master-slave.

Best,

Bjoern