Re: 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]