[dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
Hi, the P1 issue i67982, that was found on the milestone m179 of SRC680, brought up the question whether there might be cases when it is useful to re-open a milestone that has already been announced as "ready for CWS usage", in order to integrate a P1 bugfix. As this matter does not only affect a few guys at Sun, I am trying to start this discussion again here on the OOo list. I will try to summarize some of the points which were already brought up in the recent discussion (ruthlessly copying & pasting from other people's emails ;-)). Please excuse if this mail gets quite long thereby. In replying it might be useful to keep only the part which seem relevant to you. _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. Ad 1) Developer perspective: for those not already working on that milestone it makes no difference, whether to wait for a rebuild or for a new milestone. For those who are already working on that milestone a re-open would cause additional trouble if they need to get the new fix. Getting it from a new milestone would be standard task with normal tooling support ('cwsresync'). Getting it from the same milestone requires manual work (throw away your solver, get the new one, rebuild if necessary). QA perspective: for serious QA you cannot accept that milestone as base for any CWS. No one knows by sure in what state such a CWS would be: does it already contain the late fix, or not? Of course you would gain a testable master milestone, but what is the difference in waiting for a rebuild of milestone x and waiting for milestone x+1 containg just that one fix? Technically you would win nothing. So, to summarize: no benefit for developers, more work to do for some developers, no real benefit for QA -> no solution at all. Scenario 1 does not need re-opening an existing milestone. Ad 2) Allthough we did not have this situation yet, there may be cases where we are required to undo master commits regardless from all negative consequences. What would be consequences of fixing bugs on existing milestone (in contrast to doing them ASAP for the next build)? - More work for developers (see above). - Unambiguity about the state of such a milestone and derived work. We have no versioning withing milestones, no one could tell whether something based on a redone milestone is done before or after that fix (see 'QA perspective' above). - Unambiguity about when a milestone is really ready for use. At the moment everyone can rely on the announce mails. If we start redoing milestones, when should a developer be shure a milestone is good? I f.e. would stop creating CWSs against the latest milestone, I would take the one before, just to be shure I do not have to redo my work. - Another question that comes up: what kind of P1 tasks is severe enough to redo a build? Who decides about that? What would be consequences of always fixing bugs in the next available milestone? - Clear rules. What has been announced as finished is finished, no one will touch it again. Neither inside nor outside SUN. - There may be milestones known to be partly unusable. That's not new, we already had situations where CWS owners were forced to resync their CWS before QA before a ceratin milestone had bugs preventing proper testing of that CWS. Of course we should communicate this cases as early as possible to avoid unnecessary work for CWS owners and QA people. _B) Wait with the "ready for CWS usage" announcement until QA approval_ The QA does not want to release products/builds where P1 issues are open, which lead to broken major functionality in SO/OOo. They want to have a build where test results are comparable with other builds and where the number of errors goes down from one version to the next. And where regressions can be found quickly, without searching in hundreds of new errors. Developers sometimes want to have fast a build to open new CWS or resync an older CWS to use new functionality. But OTOH resyncing against an unusable milestone could be a waste of time. So why not wait until automated testing has the results for a build? What are the consequences : - automated testing takes 2-3 days - the development
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
From: Jörg Jahnke <[EMAIL PROTECTED]> Date: Wed, 02 Aug 2006 10:46:07 +0200 Hi, I'll try to read this long e-mail completely in the evening again. But here is my first idea: > _B) Wait with the "ready for CWS usage" announcement until QA approval_ Minor modification of this: after integration of all CWSes is done and the tree is tagged but still not yet announced as ready (as is the case with SRC680_m180 right now), inform people about this fact. And you can even sent buildbots (the latest work from our Intel friends) on it to get early feedback about the "buildability" thus preventing build related P1 issues. -- Pavel Janík It's an editor, a programming environment, a mail and news reader, a shrink, and a way of life. -- Eli Zaretskii in gnu.emacs.help about Emacs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
Hi, regarding position _B) below: one should point out that the milestone will be delayed for more than 2-3 days in case something is wrong with the milestone. Creating a CWS, fixing the bug, rebuilding, repackaging, doing again the automated tests can possibly delay the milestone by a week or even more. Another thing is what criteria do we establish for a bug which is severe enough to stop a milestone? Certainly not the ones we do for for major and minor releases, this is just a development milestone after all. But what is a bad milestone for - say - using the writer in a meaningful way can be a perfect milestone to base a new calc CWS on if it contains urgent needed new stuff. Any criteria for such milestone stopper bug will be necessarily "subjective" in a way, at least everything short of saying that all automated tests must be successful. The latter criteria would be a nice one if it wouldn't take days to ensure this, I think we would become to inflexible if we adopt that. I would plead for keeping the current way to release development milestones, that is, do the smoketest and than announce it. Maybe we should enhance it with a "milestone is really really bad, please don't use, QA will not accept anything which is based on this" notification mechanism. +1 for _A) Heiner Jörg Jahnke wrote: Hi, the P1 issue i67982, that was found on the milestone m179 of SRC680, brought up the question whether there might be cases when it is useful to re-open a milestone that has already been announced as "ready for CWS usage", in order to integrate a P1 bugfix. As this matter does not only affect a few guys at Sun, I am trying to start this discussion again here on the OOo list. I will try to summarize some of the points which were already brought up in the recent discussion (ruthlessly copying & pasting from other people's emails ;-)). Please excuse if this mail gets quite long thereby. In replying it might be useful to keep only the part which seem relevant to you. _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. Ad 1) Developer perspective: for those not already working on that milestone it makes no difference, whether to wait for a rebuild or for a new milestone. For those who are already working on that milestone a re-open would cause additional trouble if they need to get the new fix. Getting it from a new milestone would be standard task with normal tooling support ('cwsresync'). Getting it from the same milestone requires manual work (throw away your solver, get the new one, rebuild if necessary). QA perspective: for serious QA you cannot accept that milestone as base for any CWS. No one knows by sure in what state such a CWS would be: does it already contain the late fix, or not? Of course you would gain a testable master milestone, but what is the difference in waiting for a rebuild of milestone x and waiting for milestone x+1 containg just that one fix? Technically you would win nothing. So, to summarize: no benefit for developers, more work to do for some developers, no real benefit for QA -> no solution at all. Scenario 1 does not need re-opening an existing milestone. Ad 2) Allthough we did not have this situation yet, there may be cases where we are required to undo master commits regardless from all negative consequences. What would be consequences of fixing bugs on existing milestone (in contrast to doing them ASAP for the next build)? - More work for developers (see above). - Unambiguity about the state of such a milestone and derived work. We have no versioning withing milestones, no one could tell whether something based on a redone milestone is done before or after that fix (see 'QA perspective' above). - Unambiguity about when a milestone is really ready for use. At the moment everyone can rely on the announce mails. If we start redoing milestones, when should a developer be shure a milestone is good? I f.e. would stop creating CWSs against the latest milestone, I would take the one before, just to be shure I do not have to redo my work. - Another question that comes up: what kind of P1 tasks is severe enough to redo a build? Who decides about that? Wha
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
On 8/2/06, Jörg Jahnke <[EMAIL PROTECTED]> wrote: _A) Reasons to always fix the issues on the next milestone_ +1 I'd personally like to to see even more continuous integration of CWS's than we currently have. The reason why a working milestone is so important for community developers is that it will usually be at least another -week- until a new one comes out. I'd personally be ready to occasionally accept slightly less stable milestones if that was balanced by the fact that a new milestone would be hours or days away. Here is a link to the buildbots: http://ooo-staging.osuosl.org:8010/ K -- Kai Backman, Software Engineer, [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
Hi, _A) Reasons to always fix the issues on the next milestone_ -1 for this one. I object because the _always_ is too strict. We had in the past situations, where we did for a single platform or a build configuration a fix, where a full rebuild for all platforms was not needed. Often these kind of errors were reported days or weeks after a release. So, as an exception, I strongly recommend to allow such kind of fixes after careful review. This makes communication about the _final_ milestone of a release erasier than communicating which milestones for what releases are relevent. I support to do regular bug fixes on new milestones. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
Hi, one more comment on B, I brought up at an internal discussion : Waiting for a QA approval for resyncing or creating a new CWS based on the master shouldn't stop the release processes for a new master. The integration of approved CWS should start directly after finishing the old master. But variant B should lead to master builds which couldn't be used for CWS handling. I want explain it on a sample : master build m179 is ready - release engineering run the smoke test successfully - release engineering enable the build for testing - automated testing starts with testing this master build - full test cycle needs per master 2-3 days - if a major issue (priority 1) is found (mostly in first day after the release of the master), a bug is filed - if the bug cannot be fixed in the current master (m179) the bug has to be fixed in m180 - only if m179 runs without any P1 issue, the master gets the approval for CWS handling (resync and creation of new CWS) - if a P1 issue were found in master m179 and it couldn't be fixed in this build anymore, the master should not get the approval to handle CWS with it. So the QA-Approval and the behavior to fix P1 issues on the next master can be handled in one process. But with the approval of QA you will get CWSs in a higher quality, because they do not based on broken master builds. But this will lead to master build, which cannot be used for CWS handling. BUT : I support the old handling we have since a long time. It is working well for most of the cases we had. So I do not require a new handling, but I want to bring it in discussion. Regards, Thorsten Jens-Heiner Rechtien wrote: Hi, regarding position _B) below: one should point out that the milestone will be delayed for more than 2-3 days in case something is wrong with the milestone. Creating a CWS, fixing the bug, rebuilding, repackaging, doing again the automated tests can possibly delay the milestone by a week or even more. Another thing is what criteria do we establish for a bug which is severe enough to stop a milestone? Certainly not the ones we do for for major and minor releases, this is just a development milestone after all. But what is a bad milestone for - say - using the writer in a meaningful way can be a perfect milestone to base a new calc CWS on if it contains urgent needed new stuff. Any criteria for such milestone stopper bug will be necessarily "subjective" in a way, at least everything short of saying that all automated tests must be successful. The latter criteria would be a nice one if it wouldn't take days to ensure this, I think we would become to inflexible if we adopt that. I would plead for keeping the current way to release development milestones, that is, do the smoketest and than announce it. Maybe we should enhance it with a "milestone is really really bad, please don't use, QA will not accept anything which is based on this" notification mechanism. +1 for _A) Heiner Jörg Jahnke wrote: Hi, the P1 issue i67982, that was found on the milestone m179 of SRC680, brought up the question whether there might be cases when it is useful to re-open a milestone that has already been announced as "ready for CWS usage", in order to integrate a P1 bugfix. As this matter does not only affect a few guys at Sun, I am trying to start this discussion again here on the OOo list. I will try to summarize some of the points which were already brought up in the recent discussion (ruthlessly copying & pasting from other people's emails ;-)). Please excuse if this mail gets quite long thereby. In replying it might be useful to keep only the part which seem relevant to you. _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. Ad 1) Developer perspective: for those not already working on that milestone it makes no difference, whether to wait for a rebuild or for a new milestone. For those who are already working on that milestone a re-open would cause additional trouble if they need to get the new fix. Getting it from a new milestone would be standard task with normal tooling support ('cwsresync'). Getting it from the same milestone requires manual wor
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
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]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
Martin Hollmichel wrote: Hi, _A) Reasons to always fix the issues on the next milestone_ -1 for this one. I object because the _always_ is too strict. We had in the past situations, where we did for a single platform or a build configuration a fix, where a full rebuild for all platforms was not needed. Often these kind of errors were reported days or weeks after a release. So, as an exception, I strongly recommend to allow such kind of fixes after careful review. This makes communication about the _final_ milestone of a release erasier than communicating which milestones for what releases are relevent. If fixes on an existing master are done in this same master it is absolutely *necessary* that this is *very* clearly communicated! -Bjoern - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
_A) Reasons to always fix the issues on the next milestone_ -1 for this one. I object because the _always_ is too strict. +1 from me because of a very simple reason: I just believe in processes if they are defined and documented clear and strictly. I personally could not see any real demand for doing fixes on finalized milestones. Sure, we need exceptions within our processes from time to time, but why opening this back door and keeping it open if we currently have no such demand? Lets agree on a common handling and discuss exceptions when they are really needed. Nils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
Ok, I think we have the same understanding on this, so I suggest the wording: "Issues should always be fixed on the next milestones", these leaves an exception open with mentioning it, the original statement didn't left any roon for exception, that's the reason why I objected, Additionally I would like to add the sentence: "QA teams can mark an milestone as not usable for accepting child workspaces" This only leaves the question open if we need to mark this in EIS, opinions on this ? Martin Nils Fuhrmann wrote: _A) Reasons to always fix the issues on the next milestone_ -1 for this one. I object because the _always_ is too strict. +1 from me because of a very simple reason: I just believe in processes if they are defined and documented clear and strictly. I personally could not see any real demand for doing fixes on finalized milestones. Sure, we need exceptions within our processes from time to time, but why opening this back door and keeping it open if we currently have no such demand? Lets agree on a common handling and discuss exceptions when they are really needed. Nils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
While talking about exceptions: even a possible rule of marking single milestones as not usable for accepting child workspaces needs exceptions. For example, there are childworkspaces working on build problems, code cleanup (license, remove obsolete files, ...), or CWS or build related tools which do not depend on the quality of an office. Such CWS of course would be acceptable even on 'bad' milestones. I would even completely refrain from such a rule. Different people have different needs. As mentioned earlier in this thread, there could be a milestone where writer is completely unusable, but developers working on impress would be quite happy with it. Do we really want to force everyone working on such a milestone to resync before QA, regardless what topic his CWS has? I would prefer to handle it case by case, not by a global rule. Question: how often did we have such cases in the past (milestones such bad we better had closed them)? If it's the exception, we do not need a framework of rules and tools and databases. If it's quite often, we are doing something wrong with childworkspaces, because that should not happen. Rüdiger Martin Hollmichel wrote: Ok, I think we have the same understanding on this, so I suggest the wording: "Issues should always be fixed on the next milestones", these leaves an exception open with mentioning it, the original statement didn't left any roon for exception, that's the reason why I objected, Additionally I would like to add the sentence: "QA teams can mark an milestone as not usable for accepting child workspaces" This only leaves the question open if we need to mark this in EIS, opinions on this ? Martin Nils Fuhrmann wrote: _A) Reasons to always fix the issues on the next milestone_ -1 for this one. I object because the _always_ is too strict. +1 from me because of a very simple reason: I just believe in processes if they are defined and documented clear and strictly. I personally could not see any real demand for doing fixes on finalized milestones. Sure, we need exceptions within our processes from time to time, but why opening this back door and keeping it open if we currently have no such demand? Lets agree on a common handling and discuss exceptions when they are really needed. Nils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
From: Martin Hollmichel <[EMAIL PROTECTED]> Date: Wed, 02 Aug 2006 15:51:44 +0200 > "Issues should always be fixed on the next milestones", I agree with this. But an idea: in the past we have seen several step milestones as well. So if the issue is critical enough, can't we just make *new* (next) "step" milestone with only the critical fix added and make it available faster than usual? This can fix the "We have to wait a week for fixed milestone" reply. -- Pavel Janík Keep it right when you make it faster. -- The Elements of Programming Style (Kernighan & Plaugher) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
From technical perspective there seem to be no difference between milestone and step anymore, Martin Pavel Janík wrote: From: Martin Hollmichel <[EMAIL PROTECTED]> Date: Wed, 02 Aug 2006 15:51:44 +0200 > "Issues should always be fixed on the next milestones", I agree with this. But an idea: in the past we have seen several step milestones as well. So if the issue is critical enough, can't we just make *new* (next) "step" milestone with only the critical fix added and make it available faster than usual? This can fix the "We have to wait a week for fixed milestone" reply. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
Hi, Martin Hollmichel wrote: From technical perspective there seem to be no difference between milestone and step anymore, There was never a technical difference. It was just about the time Hamburg RE will hold a milestone which is absolutely meaningless for OOo which is why it was dropped. There was a time when a milestone could be incompatible and a step not, but this distinction is meaningless as well nowadays. I'm just for increasing the milestone number, but if a majority wants an indicator if a milestone is meant as an emergency fix we should call them "m181fix" or even "m181fix1" or something. Heiner Martin Pavel Janík wrote: From: Martin Hollmichel <[EMAIL PROTECTED]> Date: Wed, 02 Aug 2006 15:51:44 +0200 > "Issues should always be fixed on the next milestones", I agree with this. But an idea: in the past we have seen several step milestones as well. So if the issue is critical enough, can't we just make *new* (next) "step" milestone with only the critical fix added and make it available faster than usual? This can fix the "We have to wait a week for fixed milestone" reply. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
-1 for introducing something like m181fix1 or similar Reason: This would be a change in the versioning scheme which would likely break something elsewhere where the version string is being parsed and broken up into subcomponents etc. This includes tooling like EIS as well as command-line tools and automated testing etc. +1 for just increasing the milestone - a fix is just a fix no matter with how much emergency it was fixed +-0 for using steps in these cases, as it does´t hurt because we already had them Kind regards, Bernd Jens-Heiner Rechtien wrote: Hi, Martin Hollmichel wrote: From technical perspective there seem to be no difference between milestone and step anymore, There was never a technical difference. It was just about the time Hamburg RE will hold a milestone which is absolutely meaningless for OOo which is why it was dropped. There was a time when a milestone could be incompatible and a step not, but this distinction is meaningless as well nowadays. I'm just for increasing the milestone number, but if a majority wants an indicator if a milestone is meant as an emergency fix we should call them "m181fix" or even "m181fix1" or something. Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
Hi Jorg, On Wed, 2006-08-02 at 10:46 +0200, Jörg Jahnke wrote: > What would be consequences of always fixing bugs in the next available > milestone? > > - Clear rules. What has been announced as finished is finished, no one > will touch it again. Neither inside nor outside SUN. I'm well up for this :-) as you know the concept of moving static tags in CVS is acutely painful for us. [ Particularly now we want to have a single source archive that has CVS repo. data and also .svn repo data - (for which it's critically important that it's in-sync ;-) ]. So - it seems to me the fix is simple: we're not running out of milestone numbers anytime soon ;-) '181' <<< 2^31, so surely just getting a very, very quick new milestone out with the fix is the right approach ? Anyhow - it seems you're thinking on these lines anyway; so - just cheering you on :-) Thanks, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as "ready for CWS usage"?
Martin Hollmichel wrote: > Ok, I think we have the same understanding on this, so I suggest the > wording: > > "Issues should always be fixed on the next milestones", > > these leaves an exception open with mentioning it, the original > statement didn't left any roon for exception, that's the reason why I > objected, > > Additionally I would like to add the sentence: "QA teams can mark an > milestone as not usable for accepting child workspaces" > This only leaves the question open if we need to mark this in EIS, > opinions on this ? Whereever we put this mark we should also describe what this means: IMHO it means that all CWS already built an that milestone need to be resynced before integration. This is definitely the best solution. I believe that developers will prefer to resync their CWS and invest some hours of their working time for it in those rare cases where it's necessary than waiting for additional 2-3 days for *every* milestone. Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]