You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Andrew McIntyre <mc...@gmail.com> on 2008/04/29 09:04:22 UTC
10.3.3 release
Hi all,
The 10.3 branch has accumulated almost 90 fixes, we've had users
asking if we're going to make another release on the 10.3 branch, and
we have a corruption bug that has been fixed that we should be warning
our users about and providing an official release to fix.
While I'm somewhat short on time, I intend to create a 10.3 release as
soon as I can. I am currently cranking a 10.3 release build to see if
I'm missing any details. I'm probably not up to speed on the current
release notes generation process, but I'm hoping this doesn't slow me
down much. I'll post my 'test candidate' as soon as I have it so
others can check it for flaws. After that, I'll post a real 10.3.3
candidate and call for a vote. If anyone wants to help out, feel free
to pitch in testing, checking the release notes or whatever.
Please let me know if you have any questions or concerns, especially
if there are specific fixes that you think ought to go in a new 10.3
release that might not have been merged from the trunk yet. I already
see that Kathey has suggested we wait for another fix she's got ready
for the 10.3 branch. That should be fine, as I'm not sure that I'll
have time to create a real release candidate until the weekend. I'm
shooting to have a release candidate posted this weekend, with voting
going next week and the announcement going out next Friday.
Thanks,
andrew
Re: 10.3.3 release
Posted by Dy...@Sun.COM.
Andrew McIntyre <mc...@gmail.com> writes:
> On Tue, Apr 29, 2008 at 2:37 AM, <Dy...@sun.com> wrote:
>> Andrew McIntyre <mc...@gmail.com> writes:
>>
>> Fwiw, my experience from 10.4 is that you need to patch the code to make
>> it work. I'm working on a cleanup of both tools that I plan to commit to
>> trunk at some point, but I don't know if it will be ready by the time
>> you need it...
>
> I didn't seem to have a problem, actually since a search for just bugs
> in release 10.3.2.2 turned out pretty much the list of changes I
> expected to see.
Oh, good :) If works, why fix it? :)
--
dt
Re: 10.3.3 release
Posted by Andrew McIntyre <mc...@gmail.com>.
On Wed, Apr 30, 2008 at 2:22 AM, Knut Anders Hatlen <Kn...@sun.com> wrote:
>
> What about issues that were reported against 10.3.2.2 and fixed in
> 10.3.2.2? Should we remove them from the list? For instance, DERBY-3560
> fixed a build failure that was introduced on the 10.3 branch after the
> previous release. Since this bug never was present in an official
> release, it's probably not that interesting to the users.
Thanks, Knut, this is good feedback for the release notes and changes.
I'm planning to remove all test and 'regression test failure' issues
from the report, as I don't think this will be particularly
interesting to our users. Issues that don't need to be in the fixed
bug list, like 3560, I'll remove from the JIRA report by hand.
Thanks,
andrew
Re: 10.3.3 release
Posted by Kim Haase <Ca...@Sun.COM>.
Perfect, Andrew -- thanks!
Kim
Andrew McIntyre wrote:
> On Thu, May 1, 2008 at 6:26 AM, Kim Haase <Ca...@sun.com> wrote:
>> Thanks very much, Andrew. I forgot to mention that the <copyryear> tag in
>> the ditamap files for the books also needs to be changed, though you may
>> have remembered this already.
>
> I updated the copyright year in all the locations I was aware of.
> Please let me know if I missed anything.
>
> Thanks,
> andrew
Re: 10.3.3 release
Posted by Andrew McIntyre <mc...@gmail.com>.
On Thu, May 1, 2008 at 6:26 AM, Kim Haase <Ca...@sun.com> wrote:
> Thanks very much, Andrew. I forgot to mention that the <copyryear> tag in
> the ditamap files for the books also needs to be changed, though you may
> have remembered this already.
I updated the copyright year in all the locations I was aware of.
Please let me know if I missed anything.
Thanks,
andrew
Re: 10.3.3 release
Posted by Kim Haase <Ca...@Sun.COM>.
Thanks very much, Andrew. I forgot to mention that the <copyryear> tag
in the ditamap files for the books also needs to be changed, though you
may have remembered this already.
Kim
Andrew McIntyre wrote:
> On Wed, Apr 30, 2008 at 8:29 AM, Kim Haase <Ca...@sun.com> wrote:
>> Thanks for doing this, Andrew. I did a spot check of the docs and they're
>> the right ones (10.3).
>>
>> Should the copyright files in each doc be updated to say "2004-2008"
>> instead of 2007?
>
> Yes, they should be updated to include 2008. I will update these
> tomorrow. Thanks for checking this.
>
> andrew
Re: 10.3.3 release
Posted by Andrew McIntyre <mc...@gmail.com>.
On Wed, Apr 30, 2008 at 8:29 AM, Kim Haase <Ca...@sun.com> wrote:
> Thanks for doing this, Andrew. I did a spot check of the docs and they're
> the right ones (10.3).
>
> Should the copyright files in each doc be updated to say "2004-2008"
> instead of 2007?
Yes, they should be updated to include 2008. I will update these
tomorrow. Thanks for checking this.
andrew
Re: 10.3.3 release
Posted by Kim Haase <Ca...@Sun.COM>.
Thanks for doing this, Andrew. I did a spot check of the docs and
they're the right ones (10.3).
Should the copyright files in each doc be updated to say "2004-2008"
instead of 2007?
Kim Haase
Knut Anders Hatlen wrote:
> Andrew McIntyre <mc...@gmail.com> writes:
>
>> On Tue, Apr 29, 2008 at 11:46 PM, Knut Anders Hatlen
>> <Kn...@sun.com> wrote:
>>> Andrew McIntyre <mc...@gmail.com> writes:
>>>
>>> > OK, my 'test candidate' is up at:
>>> >
>>> > http://people.apache.org/~fuzzylogic/10.3.3.0/
>>>
>>> Wow, that was quick! :)
>>>
>>> I'm afraid I'm not able to access the files. Perhaps you forgot to make
>>> them world readable?
>> I thought I checked this, but maybe I had no problem accessing them
>> via the web because it's my account. Chmod'ed the files all public
>> just to be sure. Note no signatures, version number is wrong, etc. I
>> was just trying to make sure I didn't miss something generating the
>> files. The candidate I post a vote for will be a real candidate.
>
> Thanks! Some small nits after looking at CHANGES.html:
>
> The first issue mentioned (DERBY-3641) has resolution "duplicate". I
> removed the fix version in that issue so that it won't appear in your
> next search. It's probably a good idea to update the filter so that it
> only shows fixed issues.
>
> What about issues that were reported against 10.3.2.2 and fixed in
> 10.3.2.2? Should we remove them from the list? For instance, DERBY-3560
> fixed a build failure that was introduced on the 10.3 branch after the
> previous release. Since this bug never was present in an official
> release, it's probably not that interesting to the users.
>
>>> The only problem I see with a 72-hour vote, is that the bylaws of the DB
>>> PMC[1] require at least 7 days, unless a majority of the PMC members
>>> have voted +1 (or -1) before that:
>>>
>>> The minimum and default requirement for a passing vote is simple
>>> majority of PMC members casting ballots. The default voting period is
>>> 10 days and the minimum is 7 days unless the success or failure is
>>> arithmetically known.
>>>
>>> [1] http://db.apache.org/management.html
>> Yes, that is the policy, isn't it. :-)
>
> I'm afraid so. But the Apache guidelines only say that "[votes] should
> generally be permitted to run for at least 72 hours to provide an
> opportunity for all concerned persons to participate regardless of their
> geographic locations." (http://www.apache.org/foundation/voting.html) So
> there's nothing preventing the DB PMC from allowing a voting period
> shorter than 7 days. I think this has been brought up in the PMC before,
> but no decision was made as far as I remember.
>
>> I have no problem calling for a vote Friday, May 2, or thereabouts,
>> and ending it and announcing it on the Monday ten days later, May 12
>> if there are no issues that come up and everyone is ok with the
>> release. I'm hoping to get consensus earlier rather than later, and to
>> avoid publishing an announcement near a weekend.
>
> Sounds like a good plan. I didn't want to push you to having a voting
> period longer than the minimum, but I see your point about not
> announcing the release near a weekend.
>
Re: 10.3.3 release
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Andrew McIntyre <mc...@gmail.com> writes:
> On Tue, Apr 29, 2008 at 11:46 PM, Knut Anders Hatlen
> <Kn...@sun.com> wrote:
>> Andrew McIntyre <mc...@gmail.com> writes:
>>
>> > OK, my 'test candidate' is up at:
>> >
>> > http://people.apache.org/~fuzzylogic/10.3.3.0/
>>
>> Wow, that was quick! :)
>>
>> I'm afraid I'm not able to access the files. Perhaps you forgot to make
>> them world readable?
>
> I thought I checked this, but maybe I had no problem accessing them
> via the web because it's my account. Chmod'ed the files all public
> just to be sure. Note no signatures, version number is wrong, etc. I
> was just trying to make sure I didn't miss something generating the
> files. The candidate I post a vote for will be a real candidate.
Thanks! Some small nits after looking at CHANGES.html:
The first issue mentioned (DERBY-3641) has resolution "duplicate". I
removed the fix version in that issue so that it won't appear in your
next search. It's probably a good idea to update the filter so that it
only shows fixed issues.
What about issues that were reported against 10.3.2.2 and fixed in
10.3.2.2? Should we remove them from the list? For instance, DERBY-3560
fixed a build failure that was introduced on the 10.3 branch after the
previous release. Since this bug never was present in an official
release, it's probably not that interesting to the users.
>> The only problem I see with a 72-hour vote, is that the bylaws of the DB
>> PMC[1] require at least 7 days, unless a majority of the PMC members
>> have voted +1 (or -1) before that:
>>
>> The minimum and default requirement for a passing vote is simple
>> majority of PMC members casting ballots. The default voting period is
>> 10 days and the minimum is 7 days unless the success or failure is
>> arithmetically known.
>>
>> [1] http://db.apache.org/management.html
>
> Yes, that is the policy, isn't it. :-)
I'm afraid so. But the Apache guidelines only say that "[votes] should
generally be permitted to run for at least 72 hours to provide an
opportunity for all concerned persons to participate regardless of their
geographic locations." (http://www.apache.org/foundation/voting.html) So
there's nothing preventing the DB PMC from allowing a voting period
shorter than 7 days. I think this has been brought up in the PMC before,
but no decision was made as far as I remember.
> I have no problem calling for a vote Friday, May 2, or thereabouts,
> and ending it and announcing it on the Monday ten days later, May 12
> if there are no issues that come up and everyone is ok with the
> release. I'm hoping to get consensus earlier rather than later, and to
> avoid publishing an announcement near a weekend.
Sounds like a good plan. I didn't want to push you to having a voting
period longer than the minimum, but I see your point about not
announcing the release near a weekend.
--
Knut Anders
Re: 10.3.3 release
Posted by Andrew McIntyre <mc...@gmail.com>.
On Tue, Apr 29, 2008 at 11:46 PM, Knut Anders Hatlen
<Kn...@sun.com> wrote:
> Andrew McIntyre <mc...@gmail.com> writes:
>
> > OK, my 'test candidate' is up at:
> >
> > http://people.apache.org/~fuzzylogic/10.3.3.0/
>
> Wow, that was quick! :)
>
> I'm afraid I'm not able to access the files. Perhaps you forgot to make
> them world readable?
I thought I checked this, but maybe I had no problem accessing them
via the web because it's my account. Chmod'ed the files all public
just to be sure. Note no signatures, version number is wrong, etc. I
was just trying to make sure I didn't miss something generating the
files. The candidate I post a vote for will be a real candidate.
> The only problem I see with a 72-hour vote, is that the bylaws of the DB
> PMC[1] require at least 7 days, unless a majority of the PMC members
> have voted +1 (or -1) before that:
>
> The minimum and default requirement for a passing vote is simple
> majority of PMC members casting ballots. The default voting period is
> 10 days and the minimum is 7 days unless the success or failure is
> arithmetically known.
>
> [1] http://db.apache.org/management.html
Yes, that is the policy, isn't it. :-)
I have no problem calling for a vote Friday, May 2, or thereabouts,
and ending it and announcing it on the Monday ten days later, May 12
if there are no issues that come up and everyone is ok with the
release. I'm hoping to get consensus earlier rather than later, and to
avoid publishing an announcement near a weekend.
So, I will amend my plan. Last call is still this Friday, build and
vote posted then or on the weekend, with the vote closing Monday, May
12 and announcement shortly thereafter. Please let me know if anyone
feels they need more time.
Thanks,
andrew
Re: 10.3.3 release
Posted by Dy...@Sun.COM.
Knut Anders Hatlen <Kn...@Sun.COM> writes:
> Andrew McIntyre <mc...@gmail.com> writes:
>> Then, as mentioned before, last call will be Friday, and I'll build
>> the candidate Friday or this weekend and call for a vote, with voting
>> ending next Wednesday. I'd like to have a 72-hour vote for this since
>> it's a bugfix off the branch, so the announcement can go out mid-week.
>> Please let me know if you think we should give it a full week.
>
> The only problem I see with a 72-hour vote, is that the bylaws of the DB
> PMC[1] require at least 7 days, unless a majority of the PMC members
> have voted +1 (or -1) before that:
>
> The minimum and default requirement for a passing vote is simple
> majority of PMC members casting ballots. The default voting period is
> 10 days and the minimum is 7 days unless the success or failure is
> arithmetically known.
>
> [1] http://db.apache.org/management.html
I would welcome the ability to have a shorter voting period and
genereally a simplified release process in certain circumstances.
In http://www.nabble.com/Testing-tt16333791.html I argued for a
simplified voting process for beta releases to make it easier to
(legally) gather feedback from users, but back then there did not seem
to be much support for it...
--
dt
Re: 10.3.3 release
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Andrew McIntyre <mc...@gmail.com> writes:
> On Tue, Apr 29, 2008 at 2:37 AM, <Dy...@sun.com> wrote:
>> Andrew McIntyre <mc...@gmail.com> writes:
>>
>> Fwiw, my experience from 10.4 is that you need to patch the code to make
>> it work. I'm working on a cleanup of both tools that I plan to commit to
>> trunk at some point, but I don't know if it will be ready by the time
>> you need it...
>
> I didn't seem to have a problem, actually since a search for just bugs
> in release 10.3.2.2 turned out pretty much the list of changes I
> expected to see.
>
>> > I'll post my 'test candidate' as soon as I have it so
>> > others can check it for flaws. After that, I'll post a real 10.3.3
>> > candidate and call for a vote. If anyone wants to help out, feel free
>> > to pitch in testing, checking the release notes or whatever.
>
> OK, my 'test candidate' is up at:
>
> http://people.apache.org/~fuzzylogic/10.3.3.0/
Wow, that was quick! :)
I'm afraid I'm not able to access the files. Perhaps you forgot to make
them world readable?
> I put the RELEASE-NOTES.html and CHANGES.html in that directory as
> well so you don't need to download the whole package to review those
> if that's all you want to review. The release notes obviously need
> some work, I'll finesse those a bit tomorrow.
>
> Then, as mentioned before, last call will be Friday, and I'll build
> the candidate Friday or this weekend and call for a vote, with voting
> ending next Wednesday. I'd like to have a 72-hour vote for this since
> it's a bugfix off the branch, so the announcement can go out mid-week.
> Please let me know if you think we should give it a full week.
The only problem I see with a 72-hour vote, is that the bylaws of the DB
PMC[1] require at least 7 days, unless a majority of the PMC members
have voted +1 (or -1) before that:
The minimum and default requirement for a passing vote is simple
majority of PMC members casting ballots. The default voting period is
10 days and the minimum is 7 days unless the success or failure is
arithmetically known.
[1] http://db.apache.org/management.html
--
Knut Anders
Re: 10.3.3 release
Posted by Andrew McIntyre <mc...@gmail.com>.
On Tue, Apr 29, 2008 at 2:37 AM, <Dy...@sun.com> wrote:
> Andrew McIntyre <mc...@gmail.com> writes:
>
> Fwiw, my experience from 10.4 is that you need to patch the code to make
> it work. I'm working on a cleanup of both tools that I plan to commit to
> trunk at some point, but I don't know if it will be ready by the time
> you need it...
I didn't seem to have a problem, actually since a search for just bugs
in release 10.3.2.2 turned out pretty much the list of changes I
expected to see.
> > I'll post my 'test candidate' as soon as I have it so
> > others can check it for flaws. After that, I'll post a real 10.3.3
> > candidate and call for a vote. If anyone wants to help out, feel free
> > to pitch in testing, checking the release notes or whatever.
OK, my 'test candidate' is up at:
http://people.apache.org/~fuzzylogic/10.3.3.0/
I put the RELEASE-NOTES.html and CHANGES.html in that directory as
well so you don't need to download the whole package to review those
if that's all you want to review. The release notes obviously need
some work, I'll finesse those a bit tomorrow.
Then, as mentioned before, last call will be Friday, and I'll build
the candidate Friday or this weekend and call for a vote, with voting
ending next Wednesday. I'd like to have a 72-hour vote for this since
it's a bugfix off the branch, so the announcement can go out mid-week.
Please let me know if you think we should give it a full week.
Thanks,
andrew
Re: 10.3.3 release
Posted by Dy...@Sun.COM.
Andrew McIntyre <mc...@gmail.com> writes:
> Hi all,
>
> The 10.3 branch has accumulated almost 90 fixes, we've had users
> asking if we're going to make another release on the 10.3 branch, and
> we have a corruption bug that has been fixed that we should be warning
> our users about and providing an official release to fix.
>
> While I'm somewhat short on time, I intend to create a 10.3 release as
> soon as I can. I am currently cranking a 10.3 release build to see if
> I'm missing any details. I'm probably not up to speed on the current
> release notes generation process, but I'm hoping this doesn't slow me
> down much.
Fwiw, my experience from 10.4 is that you need to patch the code to make
it work. I'm working on a cleanup of both tools that I plan to commit to
trunk at some point, but I don't know if it will be ready by the time
you need it...
There is a Jira for this, DERBY-3598. There is a preliminary patch there
which I used to create the release notes and changes for 10.4, but I'm
working on implementing Rick's suggestion.
> I'll post my 'test candidate' as soon as I have it so
> others can check it for flaws. After that, I'll post a real 10.3.3
> candidate and call for a vote. If anyone wants to help out, feel free
> to pitch in testing, checking the release notes or whatever.
>
> Please let me know if you have any questions or concerns, especially
> if there are specific fixes that you think ought to go in a new 10.3
> release that might not have been merged from the trunk yet. I already
> see that Kathey has suggested we wait for another fix she's got ready
> for the 10.3 branch. That should be fine, as I'm not sure that I'll
> have time to create a real release candidate until the weekend. I'm
> shooting to have a release candidate posted this weekend, with voting
> going next week and the announcement going out next Friday.
Thanks for offering to do this.
--
dt