db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: [VOTE] 10.1.3.0 release
Date Thu, 22 Jun 2006 05:36:51 GMT
On 6/20/06, Kathey Marsden <kmarsdenderby@sbcglobal.net> wrote:
> Mike Matrigali wrote:
>
> > I would like to see the fix for DERBY-1392 included in the 10.1.3
> > release if there is a second release candidate.  While the bug
> > is an edge error case, the result is a corrupt db.  I believe
> > there is little risk as again the path is not one usually taken.
> > The change has already been fixed in the trunk and the 10.1 branch.
>
> +1 to including DERBY-1392  and thanks so much to Anders for finding and
> fixing this issue!

Is this a serious enough issue to warrant another release candidate?
Tests that exercise the issue were not contributed along with the fix,
and it would be nice to know that this is an issue that is likely to
be hit in known circumstances. If so, a release note is probably in
order since it supposedly can cause corruption to a database.

There is also DERBY-1373, the fix for loading an encrypted database
via the jar subprotocol, but due to a recent review by Sunitha [1], it
appears that there is more that needs to be done before the patch can
be committed. If the contributor (Mathias Herberts) can address the
known issues with the patch, then it seems like a very useful fix to
have in the release.

If you feel these fixes are a requirement for 10.1.3, please speak up.
If I get another vote for DERBY-1392, or similar opinions regarding
DERBY-1373, then I will take that as consensus and prepare another
release candidate. Once we reach consensus on the two issues and get
the fix for DERBY-1373 committed if there is consensus for that
particular issue, I can generate another release candidate.

If we have another release candidate, and assuming that the relevant
fixes for it can be committed by Friday, are those testing the release
candidate comfortable with a 72-hour turnaround on the vote for the
new release candidate or will we need another two weeks?

A 72-hour turnaround should allow us to get the new release candidate
approved by next Wednesday (assuming a release candidate is posted for
a vote on Friday), which would mean that I could still get the release
announced to the public by Friday, June 30.

A two-week voting period will cause the announce date to be in the
second week of July, due to the longer voting period and the 24-hour
wait after the vote for confirmation that the release has hit the
mirrors. That said, I'm ok with the longer turnaround on the vote, but
another two weeks from a vote posted this Friday would mean a publish
date of July 10, which is a over a week's departure from the currently
posted release date on the wiki, which states June 30.

That's a significant difference, so I think we should discuss the pros
and cons here. At the moment, I'm leaning toward letting the vote for
10.1.3.0 continue since all current test results are positive, but I
can be persuaded otherwise if there is consensus that the fixes
mentioned above are a must-have for 10.1.3.

andrew

[1] http://issues.apache.org/jira/browse/DERBY-1373#action_12417195

Mime
View raw message