Thorsten Behrens wrote: > Nils Fuhrmann wrote: >> I know that there were some issue regarding QA'ing buildbot builds in >> past. To get an idea what the real problem is, we should collect those >> issues in detail when they occur to find the root cause for them (as we >> always do). If those issues still are existent, I would await that this >> list is already available somewhere (Mechtilde, do you have such list?). >> > Hi Nils, *, > > I would expect to *always* have subtle (or not so subtle) > differences in the build, *as long* as we don't converge to exactly > one build system (whatever that might look, not necessarily > buildbots). That would be fixing the root cause, in my book. > >> Really, we should investigate into the concrete list of issues before >> thinking about any additional infrastructure. So if such list of issues >> is available, I will ask someone of my team to take a look on it. >> > In concur with Andre. I guess it's about using the existing > infrastructure properly - why not setup a buildbot with the exact HH > Linux buildenv (publish that as a VM/VirtualBox image at the > same time), and keep it in sync with internal builds (of course, > having RelEng build on that very same machine/setup would nicely > ensure that this is the case)?
Perhaps it would help to agree on what we want to have in an ideal world. And then see what we can achieve now and in the forseeable future. At that point we can decide whether it makes sense to look on trees or if we already like the wood. I agree with Caolan and Thorsten Behrens: ideally we all could use the same build environment with the same conditions. The same conditions can be guaranteed on reference systems only, we never will be able to handle arbitrary builds, but IMHO this is not necessary. Having a reference build system available to everybody is enough. The build bots we are talking about should be these reference systems. Also ideally we would do all internal CWS builds we do for final QA and "official" release builds on these systems also. I don't see a big problem with this requirement for CWS builds. I think it could be even a relief for most developers in Hamburg to have that. But obviously this doesn't work for the release builds, at least not today. If the Hamburg RE can't use the build bots for their builds, it's fair to charge them with keeping both systems in sync and make it a priority to keep that running, monitor the state and fix problems ASAP. Another important point: the builds from the bots should be the reference for all other builds, especially wrt. QA. Then only the Hamburg RE will need to wonder whether keeping a second build environment and keeping it in sync is an economic way to invest resources or if perhaps having a unified build environment (including adjustments to requirements of the Hamburg RE) might be a better way. This is a decision that wouldn't affect and so is also completely irrelevant for anyone outside of Hamburg. The "standard" way of testing CWS and releases should be tailored to the "standard" way of doing builds. And "standard" means: accessible to everybody. Is that a wood we could agree on? Or shall we keep the status quo and look on the trees? Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
