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]