Hi all,
_A) Reasons to always fix the issues on the next milestone_
After a milestone is announced on [EMAIL PROTECTED],
developers nearly immediately start working on that milestone, they
create childworkspaces or resync their existing CWS against it. For
doing so they rely on having the cvs tags fixed.
What could be a reason to re-open an existing milestone?
1) A milestone could pass smoketest but nevertheless contain issues
rendering it useless for parts of the stake holders. Example: current
issue i67982 causing writer to crash on red linig or tables, build
issues making a milestone totally unusable (build breaks) for OOo
community developers.
2) A milestone could contain code integrated 'by accident' which is not
allowed to be in the code line. For example license protected code not
allowed to be distributed.
Well, this should never happen! If it does we have a problem, because
this stuff is checked in on a branch and can be obtained by anyone how
can deal with cvs. If it does happen thogh, I suspect everyone could
live with this special rebuild for legal reasons.
What I really see as problematic is to have two different m179 (or
whatever) Masters. If a Master was built and declared as Ready for CWS
use (whatever this implies), it should never change. This leads only to
problems. In this case it is better to announce: "m179 will not be
tested, so resync all m179-CWSes to >=m180". IMHO this is a rule we
should stick to.
The other question is, what does "Ready for CWS use" mean. I would like
it to mean "Smoketest passed" + "Automated Tests passed". However, I see
that automated tests take too long. One obvious way to fix this is no
new idea: make the automated tests faster! :-)
If automated tests cannot be made faster, I think maybe "Smoketest
passed" is enough. In the "normal" case, where the automated tests find
no severe bugs (the chance for them should be low, and it is from
looking at the past. That's why we introduced CWSes), developers can
immediately resync. In the rare occasion we just faced, it should then
be announced that the master will not be tested and all CWSes based on
it have to resync against the next one.
I think we could live with that.
-Bjoern
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
