Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


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

Attachment: signature.asc
Description: Digital signature


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.