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
affe
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 inte
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 o
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 i
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
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. Bu
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
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
_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 dem
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
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 wh
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 *n
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
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
-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 tool
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
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 re
17 matches
Mail list logo
