db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Bugs and 10.1.2 release
Date Mon, 29 Aug 2005 17:45:36 GMT
Hi Kathey,

This sounds like a reasonable plan. By the way, what happened to the 
discussions about having a regular release schedule? Sounds like you're 
targetting October for releasing 10.1.2. Do we have a release date for 
10.2? Here are two possibilities:

Scenario 1:

October '05:  Release 10.1.2
January '06: Release 10.2

Scenario 2:

October '05:  Release 10.1.2
January '06: Release 10.1.3
April '06: Release 10.2


Kathey Marsden wrote:

>We are beginning to accumulate quite a bug backlog. There is a filter
>available on Jira  that shows the current open bug backlog, "Derby open
>code bugs".  Currently there are 108 bugs.
>In order to avoid the mad dash at 10.2 release time and to make fixes
>available to users, I was thinking it would be good to plan for a 10.1.2
>Here are my thoughts  for developers...
> 1)  Pick a bug and fix it.
>     Developers, look at the bug backlog and pick a bug 
>     you would like to fix and fix it  in the *trunk*.
> 2)  Submit your patch for the trunk.
>     Indicate if you would like the fix to go into the 10.1 branch. 
>     (Risky code changes or behavior change best stay in the trunk).
> 3)  Merge the change to 10.1
>     After you patch has been committed, if no one has objected
>     to the patch going into 10.1, test your change on the 10.1 branch,
>and submit either
>          a) the svn command to integrate your change to 10.1
>          b) a 10.1 patch if the merge was not automatic.
> 4) Repeat 1-3 many times.
> 5) Release.
>    Have a vote for release in October or potentially sooner if
>    we get a large number of fixes in the branch or there is a
>    show stopper along the way.
>Related  items:
>I would  send a mail to derby-user to encourage folks to start voting
>for issues that they would like fixed. This will help us prioritize the
>bugs we want to fix.
> It would be great if we had more folks reviewing patches.  Ideally
>fixes will have already been through one review by another developer 
>before a committer looks at it.
>Thoughts ?

View raw message