gerrit-buildbot master builds

[Thorsten Behrens]

Norbert Thiebaud wrote:
> > so I want all builds be scheduled through the queue with the builder
> > being ignorant what kind of build he does. Make the client as dumb as possible.
> 
> Not a good idea. tinderbox build are progressive so you can take
> advantage of incremental build.
>
The scheduler would know that, so it could instruct the builder to do
the right thing?

> basic tinderbuild can be done without any kind of authorization or
> external setup... whereas gerrit based build need a registered
> builbot user in gerrit.  iow a much higher barrier of entry.
> 
basic tinbuild should ideally come with nightlies IMO, so that is
debatable.

> so for instance you can have a tb scrip that build gerrit patch +
> master continuously... and run a full-lang build once a week and a
> valgrind perf regression build once every 3 days... the later two
> being triggered by cron using a simple touch <tigger_file>  command
> 
Wouldn't that be much better handled from a central master scheduler,
that has a much broader view on what is needed and when?

> box that will do gerrit patch verification will need to be
> registered in gerrit indeed. and we want to have some level of
> control and/or confidence in the operation of these boxes... iow we
> would _rely_ on them to work well and work reliably...
>
I would consider a not-so-well maintained tinderbox a nuisance in any
case, if it spams committers with false positives.

> so yes the barrier of entry will be higher, and eventually I expect
> most if not all of these to be TDF operated. but for the rest there
> is no need or benefit to deprive ourself of the occasional/part-time
> tinderbox, or make it more complicated for people to play with a
> tinderbox for a while on their own... without requiering any
> approval, control or admin involvement.
> 
That does not follow, if all that is needed is a ssh key on the
builder?

> The other consideration is that the tinderbox system today works
> independently of gerrit... so if gerrit were to go down hard for a
> significant amount of time... we could fairly easily fall back to a
> git mirror and continue working without gerrit for some time...with
> still tinderbox verification.
> 
That is the one point in your email I agree with. :)

> iow: Please explain what is the goal and justification to add
> complexity and fragility to something that is not broken.
> 
Not speaking for Bjoern of course - but my ideal outcome would be a
set of distributed build slaves, that are more flexible than the
current tinbuild system. You cannot shutdown a builder that is
misbehaving, you cannot re-purpose it to 4-0-3 if somehow noone else
builds that branch, you cannot have them build feature branches for
specific setups, you cannot instruct them to bisect a breakage that
occured just on their niche etc etc - and you have to poke their
owners each time tinbuild2 requires an update. Well, you might
consider that an advantage. ;)

Part of the underlying reason is also the question of *what exactly*
is the canonical TDF build. Default configure, or release build, or
some temporally varying mix? Or as of today, whatever the tinderbox
sponsor deems valuable?

My 2 cents,

-- Thorsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20130325/966e53d2/attachment.pgp>