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]
