Hi,
On Thu, Jun 14, 2012 at 12:36:12PM +0200, Lubos Lunak wrote:
Where are we going to get these tinderboxes? The page for master lists 17
tinderboxes, out of which only about 11 build regularly. Out of which there
are 4 linux-gcc tinderboxes, one linux-clang, 1(2?) macosx, 3 windows and 1
mingw. That, not counting any further division like running or not running
checks, gives 5 testcases if I understand it correctly, and building
successfully in any of them does not guarantee that the rest builds as well.
Right -- although I would count the linux-gcc-with-subsequentcheck tinderbox as
a single test case.
So, the thing I do not understand, how is this (complex, as far as I can say)
setup supposed to improve anything? There does not seem to be any big
difference between dedicating X tinderboxes to it or just 1-2 tinderboxes. If
we put a number of tinderboxes on this, they still won't test the patches
enough, while there won't be that many left for checking that the actual
repository builds fine, which will be needed anyway.
I dont think we should split up tinderboxes between this and repository builds
(I asssume you mean testbuilding the head of master with that). As the patches
are cherrypicked on the head of master with this, master is already tested
along with this. However, while people are in the beginning still pushing even
risky patches directly to master we cant assume master to be flawless all of
the time -- so the proposed algo should be extended with "build the master you
cherry-picked upon once after each failed build".
What is this setup improving? Simple:
- find buildbreakers _before_ they hit master
- with gerrit, you can push your patch, wait for the tinderbox result you need
and _then_ put it on master
(so this gives everyone easy access to windows test builders, which as we all
know are a pain to set up, and also subsequentcheck runs)
- reduce tinderbox spammage as the list of possible offenders is smaller -- and
esp. is not growing with every build
- allows greenlighting bigger sets of patches with one compile (essential on
slower platforms, f.e. Windows)
If patches in gerrit[*] need to be tested, it should work just as well to use
one of the really fast tinderboxes for checking that it builds, which will
cover a majority of possible problems, then maybe one more can build
including checks, and if any problem gets through, it'll be caught by the
normal tinderboxes, which are needed anyway (for direct commits, some other
seemingly unrelated commit breaking the patch meanwhile, etc.).
That doesnt scale that well. Also note that the tinderboxes building plain
master should end up a scenario that is very, very rarely needed (it will still
be done of course)
Best,
Bjoern
[*] Speaking of which, when will we get told about this gerrit thing, besides
random remarks, or have I missed it?
Look for a mail with "ACTION REQUIRED" in the subject in the libreoffice
mailing list archive.
Context
- Re: probabilistic approach to tinderboxing (continued)
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.