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
signature.asc
Description: Digital signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
