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]
[dev] OOo 2.0.4 status meeting
August 7th, 15pm - 15.15pm Participants: Kai Ahrens, Uwe Luebbers, Martin Hollmichel, Bettina Haberer This group meet on Mondays 3pm German time on regular basis, please contact me if there is the need to raise any issues for the next release in this forum, we try to move to irc then or at least try to put your issues onto our agenda. In case you get this email as private copy as well, we think you need to take action on this mail. * RE this week: Ivo, Ruediger, Heiner, OOD680m1 to start Thurssday 10th issue count for 2.0.4 went down to 63 from 144 last week, which seems to be a bit hight just 3 days after code freeze date but a number of them are related to (expected) l10n issues. OOD680m1 will start on Thursday with a few cvs declared as stoppers (also see http://qa.openoffice.org/issues/showdependencytree.cgi?id=68046), OOD680m2 will start Thurday 17th, which is last cws integration, will include localization12 (updated localizations), so that we still expect the release candidate for Tuesday 22. Initial response time (IRT) for patches has been decreased, http://eis.services.openoffice.org/patchreport/irt_index.html Initial inactivity time (IIT) for patches is still on the same level, http://eis.services.openoffice.org/patchreport/iit_index.html The Patchreports now includes nice grpahs, it's worth to take a look on them. The demand for branching off OOD680 is not that high as expected, so we are planning the branch around August 3rd to 10th, candidates for early integration for 2.0.5/2.1 are cws writercorehandoff, configdbbe and hcshared01. Martin PS: SRC680m182, which will be the start for OOo 2.1 release is planned for Monday, 14th. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
