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 Rick Hillegas <Ri...@Sun.COM> on 2006/09/29 21:18:31 UTC

10.2.1.5 status

First the good news:

1) So far,  no one has found any showstopping runtime problems with the 
product itself.

2) We've seen a marked decrease in the rate at which problems in the 
release structure pop up.

Now for the bad news:

3) A week into vetting, we've found some more issues with the release 
structure and with the release notes.

Once I understand the next rash of edits to the release notes, I'm 
inclined to spin a new release candidate and call a new vote. However, 
I'm concerned that we haven't found all of the structural problems yet 
and I'm worried about exhausting the community's patience by re-starting 
the test/vote cycle too many times. Would it be useful to do the following:

A) Post a new release candidate but don't call a vote yet. Just let the 
existing vote continue.

B) Ask the structure experts to scrutinize the new candidate carefully.

C) Call a new vote only after the structure experts are satisfied.

I would appreciate the community's advice about how to proceed.

Thanks,
-Rick


Re: Re: 10.2.1.5 status

Posted by Andrew McIntyre <mc...@gmail.com>.
On 9/29/06, Rajesh Kartha <ka...@gmail.com> wrote:
>
> Will DERBY-1900 be also addressed in 10.2.1.6 ? This  will avoid users to
> manually change permissions  on the scripts before running them.

Any easy solution to this occurred to me the other day: have Ant force
the execute bit on when building the archives, making the build
platform irrelevant. Fix checked into trunk and merged to 10.2.

andrew

Re: 10.2.1.5 status

Posted by Rajesh Kartha <ka...@gmail.com>.
Rick Hillegas wrote:

> Andrew McIntyre wrote:
>
>> On 9/29/06, Rick Hillegas <Ri...@sun.com> wrote:
>>
>>> First the good news:
>>>
>>> 1) So far,  no one has found any showstopping runtime problems with the
>>> product itself.
>>
>>
>>
>> Yay!
>>
>>> Would it be useful to do the following:
>>>
>>> A) Post a new release candidate but don't call a vote yet. Just let the
>>> existing vote continue.
>>>
>>> B) Ask the structure experts to scrutinize the new candidate carefully.
>>>
>>> C) Call a new vote only after the structure experts are satisfied.
>>
>>
>>
>> I think enough changes have accumulated that we may need a 10.2.1.6.
>> Just removing junit.jar was a small enough change that I felt
>> rerolling all the distributions from scratch wouldn't be needed, now
>> I'm not so sure. So how about:
>>
>> * roll a 10.2.1.5-and-a-half, we get today and the rest of the weekend
>> to poke at the new structure and such.
>>
>> * Merge the two or three recent doc changes that have gone in since
>> 10.2.1.5 that haven't already been merged over. I can take care of
>> that today, since I committed them to trunk.
>>
>> * Monday, roll 10.2.1.6. Call for a 3-day vote closes 5pm PDT. Should
>> be fine, since the difference between 10.2.1.5 and 10.2.1.6 code-wise
>> is very minimal and shouldn't need extensive testing, more of just a
>> sanity check.
>>
>> sound good?
>>
>> andrew
>
>
> Thanks, Andrew. I'm happy with this solution.
>
> Regards,
> -Rick
>
Hi Rick,

Will DERBY-1900 be also addressed in 10.2.1.6 ? This  will avoid users to
manually change permissions  on the scripts before running them.

In the thread
http://www.nabble.com/Re%3A-Questions-on-the-scripts-in--bin-directory-of-Derby-install-p6272490.html

Andrew had a question about which platform are these distributions built 
on, maybe the solution
to DERBY-1900 lies there.

-Rajesh




Re: 10.2.1.5 status

Posted by Rick Hillegas <Ri...@Sun.COM>.
Andrew McIntyre wrote:

> On 9/29/06, Rick Hillegas <Ri...@sun.com> wrote:
>
>> First the good news:
>>
>> 1) So far,  no one has found any showstopping runtime problems with the
>> product itself.
>
>
> Yay!
>
>> Would it be useful to do the following:
>>
>> A) Post a new release candidate but don't call a vote yet. Just let the
>> existing vote continue.
>>
>> B) Ask the structure experts to scrutinize the new candidate carefully.
>>
>> C) Call a new vote only after the structure experts are satisfied.
>
>
> I think enough changes have accumulated that we may need a 10.2.1.6.
> Just removing junit.jar was a small enough change that I felt
> rerolling all the distributions from scratch wouldn't be needed, now
> I'm not so sure. So how about:
>
> * roll a 10.2.1.5-and-a-half, we get today and the rest of the weekend
> to poke at the new structure and such.
>
> * Merge the two or three recent doc changes that have gone in since
> 10.2.1.5 that haven't already been merged over. I can take care of
> that today, since I committed them to trunk.
>
> * Monday, roll 10.2.1.6. Call for a 3-day vote closes 5pm PDT. Should
> be fine, since the difference between 10.2.1.5 and 10.2.1.6 code-wise
> is very minimal and shouldn't need extensive testing, more of just a
> sanity check.
>
> sound good?
>
> andrew

Thanks, Andrew. I'm happy with this solution.

Regards,
-Rick

Re: Re: 10.2.1.5 status

Posted by Andrew McIntyre <mc...@gmail.com>.
On 9/29/06, Andrew McIntyre <mc...@gmail.com> wrote:
>
> * Merge the two or three recent doc changes that have gone in since
> 10.2.1.5 that haven't already been merged over. I can take care of
> that today, since I committed them to trunk.

This part is now done with revision 451427.

andrew

Re: 10.2.1.5 status

Posted by Andrew McIntyre <mc...@gmail.com>.
On 9/29/06, Rick Hillegas <Ri...@sun.com> wrote:
> First the good news:
>
> 1) So far,  no one has found any showstopping runtime problems with the
> product itself.

Yay!

> Would it be useful to do the following:
>
> A) Post a new release candidate but don't call a vote yet. Just let the
> existing vote continue.
>
> B) Ask the structure experts to scrutinize the new candidate carefully.
>
> C) Call a new vote only after the structure experts are satisfied.

I think enough changes have accumulated that we may need a 10.2.1.6.
Just removing junit.jar was a small enough change that I felt
rerolling all the distributions from scratch wouldn't be needed, now
I'm not so sure. So how about:

* roll a 10.2.1.5-and-a-half, we get today and the rest of the weekend
to poke at the new structure and such.

* Merge the two or three recent doc changes that have gone in since
10.2.1.5 that haven't already been merged over. I can take care of
that today, since I committed them to trunk.

* Monday, roll 10.2.1.6. Call for a 3-day vote closes 5pm PDT. Should
be fine, since the difference between 10.2.1.5 and 10.2.1.6 code-wise
is very minimal and shouldn't need extensive testing, more of just a
sanity check.

sound good?

andrew