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