[rvm-core] Upcoming releases and JIRA "Fix for" version targets

[David P Grove]

Looking forward over the next few months, I'd like to suggest timing for
the next couple of releases:

(1) We make a 2.9.3 release within the next 2 weeks (before the end of
April).  We use JIRA to coordinate this.  As long as there are any items
with a fix for version of 2.9.3, we are not ready to make a release.  We
can obviously get rid of items either by fixing them, or by pushing them
off to 2.9.4.  Please look at any items you own/opened that have a 2.9.3
fix target and make a judgement about the proper action.

(2) We make a 3.0 release by the first week of June (pre-PLDI).  This is a
bit of a stretch, since there are a number of things we "want" to have done
in 3.0, but at some point I think we need to decide that we are close
enough and go ahead with this major version increment.   If we really
aren't ready in 7 weeks, then we can make a 2.9.4 release instead.

Also, I created a version 1000 release in JIRA as a placeholder for all
items that we plan to do "some day" but that aren't gating a particular
release. Clearly these can be done much sooner than v1000, but I think it
will be useful (at least for me) to be able to use the fix for release to
distinguish between things that have been sitting around for a long time
and that we want to do sometime and things that have been just opened
(possibly by users) and not yet prioritized with a fix target.  Before we
had about 170 items that were unscheduled.  I put about 150 of these
against v1000, but there were a dozen or so lurking in there that really
did need to be fixed sooner than that and were in danger of getting
overlooked.  It would be great when you are opening new items if you could
select the fix for target.  Otherwise I will probably make arbitrary
decisions every few weeks and schedule all unscheduled items to some
version.

I think we probably should have 3 "active" targets most of the time and try
to put items in the appropriate bucket when we open them.
      the next minor release (currently 2.9.3/2.9.4).  Bugs/regressions &
small items that really should be dealt with before the next release.
      the next major release (currently 3.0).  Larger work items that won't
block a minor release, but are focus items for forward looking development
      eventually (currently 1000)   All of the good ideas we wish we had
enough time to do....

When you do close something, be sure to update the fix version to be that
of the next release so it gets included in the release notes (we generate
the release notes entirely from JIRA now based on the fix version of closed
items).

--dave


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers]

Hi everyone,

I think Dave's plan makes complete sense and I'm really looking forward
to the coming releases. Whilst organizing the trackers it may be a good
time for people to bring across tracker items that have been left behind
sourceforge. A number of the tracker items require cattrack searches to
see if they have cleared up. When I try to do a search in cattrack I get
the 502 proxy error (error reading from remote server), could we make it
either a high priority to fix this problem or just move these issues
into 2.9.4?

Regards,
Ian

David P Grove wrote:

> Looking forward over the next few months, I'd like to suggest timing for
> the next couple of releases:
>
> (1) We make a 2.9.3 release within the next 2 weeks (before the end of
> April).  We use JIRA to coordinate this.  As long as there are any items
> with a fix for version of 2.9.3, we are not ready to make a release.  We
> can obviously get rid of items either by fixing them, or by pushing them
> off to 2.9.4.  Please look at any items you own/opened that have a 2.9.3
> fix target and make a judgement about the proper action.
>
> (2) We make a 3.0 release by the first week of June (pre-PLDI).  This is a
> bit of a stretch, since there are a number of things we "want" to have done
> in 3.0, but at some point I think we need to decide that we are close
> enough and go ahead with this major version increment.   If we really
> aren't ready in 7 weeks, then we can make a 2.9.4 release instead.
>
> Also, I created a version 1000 release in JIRA as a placeholder for all
> items that we plan to do "some day" but that aren't gating a particular
> release. Clearly these can be done much sooner than v1000, but I think it
> will be useful (at least for me) to be able to use the fix for release to
> distinguish between things that have been sitting around for a long time
> and that we want to do sometime and things that have been just opened
> (possibly by users) and not yet prioritized with a fix target.  Before we
> had about 170 items that were unscheduled.  I put about 150 of these
> against v1000, but there were a dozen or so lurking in there that really
> did need to be fixed sooner than that and were in danger of getting
> overlooked.  It would be great when you are opening new items if you could
> select the fix for target.  Otherwise I will probably make arbitrary
> decisions every few weeks and schedule all unscheduled items to some
> version.
>
> I think we probably should have 3 "active" targets most of the time and try
> to put items in the appropriate bucket when we open them.
>       the next minor release (currently 2.9.3/2.9.4).  Bugs/regressions &
> small items that really should be dealt with before the next release.
>       the next major release (currently 3.0).  Larger work items that won't
> block a minor release, but are focus items for forward looking development
>       eventually (currently 1000)   All of the good ideas we wish we had
> enough time to do....
>
> When you do close something, be sure to update the fix version to be that
> of the next release so it gets included in the release notes (we generate
> the release notes entirely from JIRA now based on the fix version of closed
> items).
>
> --dave
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>  

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core