Re: [tools-dev] Suggestion for milestones tagging and buildfixes
Christian Lohmaier wrote: Hi Eric, *, On Mon, Dec 11, 2006 at 08:37:05PM +0100, eric b wrote: [...] (snip) Comment : buildbots for Mac OS X + manual builds should be enough. I'm pretty sure this is the same for other archs :-) I know everybody is on the buildbot-hype - but don't forget about tinderbox.. Tinderbox constantly builds everything without an explicit request to do so. Hear, hear! Many buildbreakers can just be avoided by not integrating cws that break the build. (Preventing is better than fixing afterwards) Tinderbox has a seperate overview page for cws that are in ready-for-qa state[1]: http://go-oo.org/tinderbox/ready_for_QA.express.html (main builders are two linux boxes (build everything), one PPC Mac (builds everying) and one Windows-box (builds selected stuff)) The windows box builds all milestones and RC's. And CWS's if there is demand. So don't be shy and just send me an email if you want your CWS to be build on Windows. (If I find the time I'll integrate that box into the buildbot system, I promise ;) ) Volker So before a cws gets nominated, I suggest that the QA-Rep has a look at that page. If the cws is listed green, then no problem, nominate it. However if one or more are listed red, then have a look at the logs (tinderbox offers summarized logs as well as full logs) and see whether the breaker is caused by the cws. You can ignore the red status if * You added a new module (is not listed in EIS info and thus tinderbox cannot know about it, the build will break because of that missing module) * the Master your cws is based on failed as well. Usually the buildmaster of the buildslave will hunt for patches in IZ and apply them to make the master build and then rebuild all relevant cws so this should only last a couple of days) Apart from that, a build may occasionaly fail because of parallel build issues, but that is the exception, not the rule. If your cws is red, and the master is green, then something is fishy. Have a look! If tinderbox didn't build your cws yet, fire up one of the buildbots to fill the gap. Tinderbox buildslaves will always perform clean builds (as do the buildbots). combinations of integrated cws may still cause build-breakers, but well, that's life... [...] ciao Christian [1] other overview pages are only new cws: http://go-oo.org/tinderbox/new.express.html and both ready and new: http://go-oo.org/tinderbox/all_trees.express.html -- = http://wiki.services.openoffice.org/wiki/Debug_Build_Problems = PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D signature.asc Description: OpenPGP digital signature
[tools-dev] Suggestion for milestones tagging and buildfixes
Hello, Following some good advice, I decided to use this list, because I had an idea about milestones tags. Please note : 1) This is just a suggestion, can be discussed, ... improved ..etc 2) the issue mentionned is just as example, and I have nothing against the content nor the origin. Please don't see any offense My personal experience in build : I do Mac OS X and Linux ( both Intel and Power PC ) builds since several years. I'll talk about native port, but all builds are IMHO concerned. The problem is very simple : they are tagged milestones, and these one are not buildable with the corresponding source code, because build fixes will be integrated in the next one. This is unfortunaly recurrent :-/ Exemple : m196 + aquavcl01 : one issue with P1 priority ( http:// www.openoffice.org/issues/show_bug.cgi?id=72372 ). The fix will be in m197, and we have to explain to new developpers they have supplementary patches to include to build. We had the same problem with previous milestones (buildfix included in next milestone), and we never will be able to provide any milestone without additional patch this way :-/ This problem is fully repeatable, and will certainly (unfortunaly ) occur again. I know nothing is perfect, and I really appreciate the current scheduling. My purpose is just suggest a little change, with constructive objective only :-) So, I have a proposal : step 1 : tag odd milestones odd milestones will contain previous milestones + all integrated cws step 2 : build all concerned architectures : Windows, Linux Solaris Mac O SX ... Comment : buildbots for Mac OS X + manual builds should be enough. I'm pretty sure this is the same for other archs :-) Every arch, once build, will return a go. All go means everything is ok. For every build break, a fix will be integrated on HEAD : *average delay for a P1 fix is less than a day* . Really harmless IMHO. Once all archs are ok the next milestone is tagged (even milestone) step 3: tag even milestone : previous milestone + buildfixes ( no new cws integrated but means buildable for all ) - just checkout and build Pros : - This way, all even milestones will be buildable on all archs - No guarantee for odd - Resync does make sense for technical previews Drawbacks : - estimated delay between odd /even milestone : 2 days max - a severe protocol has to be found (means more restrictive than currently ) - milestones consuming - maybe a better naming scheme can be found No problem if my suggestion is stupid, or can't just work. Just explain me why ;-) Regards, eric Bachard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools-dev] Suggestion for milestones tagging and buildfixes
Every arch, once build, will return a go. All go means everything is ok. For every build break, a fix will be integrated on HEAD : *average delay for a P1 fix is less than a day* . Really harmless IMHO. Once all archs are ok the next milestone is tagged (even milestone) And this even milestone is not going to be thoroughly approved by builds? P1 fix for Windows can bring P1 problem for Mac OS X... This can't work as described. Problems: too many milestones. If milestone is OK - we will skip the next one? Is there any timeout? Is e.g. Solaris/SPARC team able to reply in certain time? I think that these problems (yes, there are problems - we all know it and acknowledge it) are not that problematic. But this is only my opinion, I know I'm used to solve them so they are not so difficult for me and I think that they can be hard to solve for newcomers. Compared to other projects of such scale, OOo is much better in handling them because of milestones. We should spend some time on identification of such problems, separate them into classes and try to solve the original problems: - builds from scratch issues (Hamburg RE simply can't build from scratch because of storage, CPU, speed, etc.) - 64bit issues (we do not have buildbot for Linux/x86_64 yet?) - platform specific issues - compiler specific issues Buildbots can help solving most of them... Tag early what is to be built, fire buildbots on the tag which is not yet ready. I see the main problem with buildbot admins - it is easy to setup the buildbot, but it is not that easy to run it properly. -- Pavel Janík [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
