You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Rick Hillegas <Ri...@Sun.COM> on 2006/06/22 21:08:23 UTC
Proposal for 10.2 release schedule
Last week, Sun Microsystems announced that it will bundle Derby with the
next major release of the reference jdk, Java SE 6, also known as
Mustang or jdk1.6. If you download the latest Mustang build, you will
see that it contains our Derby 10.2.0.3 snapshot in the "db" directory
parallel to "lib" and "bin".
This is big news. It means that over the course of the next year, Derby
will turn up on the desktops of millions of developers. Hopefully,
Derby's user and developer communities will both grow dramatically.
I would like to support this bundling. Note that Mustang will need our
vetted 10.2 release candidate by September 15 so that they can QA it.
This is expected to take about 5 weeks, after which Mustang should go GA
in late October.
The JCP requires that our JDBC4-exposing release can not be generally
available until the JDBC4 specification is finalized, which happens when
Mustang is generally available. Until that date, this means that our
final, vetted release candidate can not be officially stamped as "GA"
and we can not promote it to the various Apache mirrors.
Here are proposed dates for 10.2 milestones:
August 10 - Feature work committed. 10.2 branch created.
August 24 - Last day to commit changes for 10.2
August 25 - Begin vetting 10.2 release candidate
September 15 - Target date for finishing the voting on Derby 10.2
End of October - Expected GA of JDBC4 with Mustang
End of October - GA of Derby 10.2. Release promoted to Apache mirrors.
Are this proposal and its dates reasonable?
Re: Status of adding BOOLEAN-type
Posted by Andrew McIntyre <mc...@gmail.com>.
Argh - should have gone to derby-dev. stupid gmail.
On 6/26/06, Andrew McIntyre <mc...@gmail.com> wrote:
> Rick Hillegas wrote:
> > Hi Kathey,
> >
> > Right now, I'm planning to back out BOOLEAN before the branch.
>
> Hi Rick,
>
> Don't you mean you'll back out the current BOOLEAN work from 10.2
> *after* it has been branched?
>
> Or do you think we should give up completely due to the issues with
> the DRDA spec committee that you mentioned?
>
> andrew
Re: Status of adding BOOLEAN-type
Posted by Andrew McIntyre <mc...@gmail.com>.
Rick Hillegas wrote:
> Hi Kathey,
>
> Right now, I'm planning to back out BOOLEAN before the branch.
Hi Rick,
Don't you mean you'll back out the current BOOLEAN work from 10.2
*after* it has been branched?
Or do you think we should give up completely due to the issues with
the DRDA spec committee that you mentioned?
andrew
Re: Status of adding BOOLEAN-type
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Kristian,
I have given up on re-enabling the BOOLEAN datatype in the near term,
for the following reasons:
1) I can't see when or whether the BOOLEAN datatype will make it into
the DRDA spec. After 9 months, the spec's governing body has failed to
revive. There seems to be very little industry interest in funding the
continuation of DRDA spec work.
2) The existing (10.1) behavior of Derby BOOLEAN violates the ANSI
casting rules. See DERBY-887. Fixing these casts will break Derby's ODBC
metadata and for that reason we suspect that customer applications will
break also. This appears to be the kind of compatibility issue which
requires a major rather than a minor release of Derby. I see the
following options:
a) Expose a BOOLEAN datatype which does not conform to the ANSI spec.
b) Break existing customer applications.
c) Wait until the next major release of Derby before re-enabling BOOLEAN.
My vote would be for (2c) but I don't sense enough enthusiasm for
BOOLEAN to justify a major release in the near term.
Regards,
-Rick
Kristian Waagan wrote:
> Rick Hillegas wrote:
>
>> Hi Kathey,
>>
>> Right now, I'm planning to back out BOOLEAN before the branch.
>
>
> Hi Rick,
>
> Does this mean the work already done for adding the BOOLEAN-type is
> not appropriate for completion in 10.3 (or a later release)?
>
> In case the work already done is to be discarded, can the reason(s)
> behind this decision be (briefly) stated?
>
>
>
>
> Thanks,
Re: Status of adding BOOLEAN-type
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Moving this thread back to derby-dev. Kristian responded to a thread
that was inadvertently put on derby-user.
Let's please keep release discussions on derby-dev. This is where
planning and decisions belong.
thanks,
-jean
-------- Original Message --------
Subject: Status of adding BOOLEAN-type (was: Re: Proposal for 10.2
release schedule)
Date: Mon, 26 Jun 2006 15:40:28 +0200
From: Kristian Waagan <Kr...@Sun.COM>
Reply-To: Derby Discussion <de...@db.apache.org>
Organization: Sun Microsystems Inc.
To: Derby Discussion <de...@db.apache.org>
References: <44...@sun.com>
<54...@mail.gmail.com>
<44...@sun.com> <44...@sbcglobal.net>
<44...@sun.com>
Rick Hillegas wrote:
> Hi Kathey,
>
> Right now, I'm planning to back out BOOLEAN before the branch.
Hi Rick,
Does this mean the work already done for adding the BOOLEAN-type is not
appropriate for completion in 10.3 (or a later release)?
In case the work already done is to be discarded, can the reason(s)
behind this decision be (briefly) stated?
Thanks,
--
Kristian
>
> Regards,
> -Rick
>
> Kathey Marsden wrote:
>
>> Rick Hillegas wrote:
>>
>>> Hi Andrew,
>>>
>>> Like you I'm happy that Geir Magnusson is working the JCP issues and
>>> I'm optimistic that the time line, which had been twisted into a
>>> pretzel, can be straightened out. I'm not ready to propose an
>>> alternative--but I expect to know more soon. Something along the
>>> lines of your proposal would be very attractive.
>>>
>>> I'm glad that you're comfortable with cutting a branch in early
>>> August. Perhaps we could move the discussion forward to this topic
>>> now. I know that several contributors still want to complete work on
>>> features for 10.2. Does everyone feel comfortable with having those
>>> features committed by August 10 so that we can cut a 10.2 branch then?
>>
>>
>> For BOOLEAN do you still plan back out that work right after the branch?
>> Relevant issues:
>> http://issues.apache.org/jira/browse/DERBY-1029
>> http://issues.apache.org/jira/browse/DERBY-984
>>
>>
>>
>
Re: Status of adding BOOLEAN-type
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Kristian,
I have given up on re-enabling the BOOLEAN datatype in the near term,
for the following reasons:
1) I can't see when or whether the BOOLEAN datatype will make it into
the DRDA spec. After 9 months, the spec's governing body has failed to
revive. There seems to be very little industry interest in funding the
continuation of DRDA spec work.
2) The existing (10.1) behavior of Derby BOOLEAN violates the ANSI
casting rules. See DERBY-887. Fixing these casts will break Derby's ODBC
metadata and for that reason we suspect that customer applications will
break also. This appears to be the kind of compatibility issue which
requires a major rather than a minor release of Derby. I see the
following options:
a) Expose a BOOLEAN datatype which does not conform to the ANSI spec.
b) Break existing customer applications.
c) Wait until the next major release of Derby before re-enabling BOOLEAN.
My vote would be for (2c) but I don't sense enough enthusiasm for
BOOLEAN to justify a major release in the near term.
Regards,
-Rick
Kristian Waagan wrote:
> Rick Hillegas wrote:
>
>> Hi Kathey,
>>
>> Right now, I'm planning to back out BOOLEAN before the branch.
>
>
> Hi Rick,
>
> Does this mean the work already done for adding the BOOLEAN-type is
> not appropriate for completion in 10.3 (or a later release)?
>
> In case the work already done is to be discarded, can the reason(s)
> behind this decision be (briefly) stated?
>
>
>
>
> Thanks,
Status of adding BOOLEAN-type (was: Re: Proposal for 10.2 release
schedule)
Posted by Kristian Waagan <Kr...@Sun.COM>.
Rick Hillegas wrote:
> Hi Kathey,
>
> Right now, I'm planning to back out BOOLEAN before the branch.
Hi Rick,
Does this mean the work already done for adding the BOOLEAN-type is not
appropriate for completion in 10.3 (or a later release)?
In case the work already done is to be discarded, can the reason(s)
behind this decision be (briefly) stated?
Thanks,
--
Kristian
>
> Regards,
> -Rick
>
> Kathey Marsden wrote:
>
>> Rick Hillegas wrote:
>>
>>> Hi Andrew,
>>>
>>> Like you I'm happy that Geir Magnusson is working the JCP issues and
>>> I'm optimistic that the time line, which had been twisted into a
>>> pretzel, can be straightened out. I'm not ready to propose an
>>> alternative--but I expect to know more soon. Something along the
>>> lines of your proposal would be very attractive.
>>>
>>> I'm glad that you're comfortable with cutting a branch in early
>>> August. Perhaps we could move the discussion forward to this topic
>>> now. I know that several contributors still want to complete work on
>>> features for 10.2. Does everyone feel comfortable with having those
>>> features committed by August 10 so that we can cut a 10.2 branch then?
>>
>>
>> For BOOLEAN do you still plan back out that work right after the branch?
>> Relevant issues:
>> http://issues.apache.org/jira/browse/DERBY-1029
>> http://issues.apache.org/jira/browse/DERBY-984
>>
>>
>>
>
Re: Proposal for 10.2 release schedule
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Kathey,
Right now, I'm planning to back out BOOLEAN before the branch.
Regards,
-Rick
Kathey Marsden wrote:
> Rick Hillegas wrote:
>
>> Hi Andrew,
>>
>> Like you I'm happy that Geir Magnusson is working the JCP issues and
>> I'm optimistic that the time line, which had been twisted into a
>> pretzel, can be straightened out. I'm not ready to propose an
>> alternative--but I expect to know more soon. Something along the
>> lines of your proposal would be very attractive.
>>
>> I'm glad that you're comfortable with cutting a branch in early
>> August. Perhaps we could move the discussion forward to this topic
>> now. I know that several contributors still want to complete work on
>> features for 10.2. Does everyone feel comfortable with having those
>> features committed by August 10 so that we can cut a 10.2 branch then?
>
>
> For BOOLEAN do you still plan back out that work right after the branch?
> Relevant issues:
> http://issues.apache.org/jira/browse/DERBY-1029
> http://issues.apache.org/jira/browse/DERBY-984
>
>
>
Re: Proposal for 10.2 release schedule
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
> Hi Andrew,
>
> Like you I'm happy that Geir Magnusson is working the JCP issues and
> I'm optimistic that the time line, which had been twisted into a
> pretzel, can be straightened out. I'm not ready to propose an
> alternative--but I expect to know more soon. Something along the lines
> of your proposal would be very attractive.
>
> I'm glad that you're comfortable with cutting a branch in early
> August. Perhaps we could move the discussion forward to this topic
> now. I know that several contributors still want to complete work on
> features for 10.2. Does everyone feel comfortable with having those
> features committed by August 10 so that we can cut a 10.2 branch then?
For BOOLEAN do you still plan back out that work right after the branch?
Relevant issues:
http://issues.apache.org/jira/browse/DERBY-1029
http://issues.apache.org/jira/browse/DERBY-984
Re: Proposal for 10.2 release schedule
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Andrew,
Like you I'm happy that Geir Magnusson is working the JCP issues and I'm
optimistic that the time line, which had been twisted into a pretzel,
can be straightened out. I'm not ready to propose an alternative--but I
expect to know more soon. Something along the lines of your proposal
would be very attractive.
I'm glad that you're comfortable with cutting a branch in early August.
Perhaps we could move the discussion forward to this topic now. I know
that several contributors still want to complete work on features for
10.2. Does everyone feel comfortable with having those features
committed by August 10 so that we can cut a 10.2 branch then?
Thanks,
-Rick
Andrew McIntyre wrote:
> OK, back to the 10.2 release schedule. How about this:
>
> early August - Feature work committed. 10.2 branch created.
>
> August/September - Proposed Final Draft of JDBC 4.0 goes public with
> updated evaluation license. Voting on a release candidate for 10.2 can
> begin as early as the day the PFD goes public
>
> September/October - GA of Derby 10.2.1, which includes whatever
> wording the spec requires regarding the JDBC 4.0 implementation in
> Derby. Release promoted to Apache mirrors.
>
> End of October - Expected GA of JDBC4 with Mustang, which includes a
> JavaDB version of Derby that is midstream between 10.2.1 and 10.2.2
>
> November/December - Derby 10.2.2 follow-on release to remove the
> wording surrounding JDBC 4 bits that had previously been required by
> the spec license.
>
> Sound good?
>
> andrew
Re: Proposal for 10.2 release schedule
Posted by Andrew McIntyre <mc...@gmail.com>.
OK, back to the 10.2 release schedule. How about this:
early August - Feature work committed. 10.2 branch created.
August/September - Proposed Final Draft of JDBC 4.0 goes public with
updated evaluation license. Voting on a release candidate for 10.2 can
begin as early as the day the PFD goes public
September/October - GA of Derby 10.2.1, which includes whatever
wording the spec requires regarding the JDBC 4.0 implementation in
Derby. Release promoted to Apache mirrors.
End of October - Expected GA of JDBC4 with Mustang, which includes a
JavaDB version of Derby that is midstream between 10.2.1 and 10.2.2
November/December - Derby 10.2.2 follow-on release to remove the
wording surrounding JDBC 4 bits that had previously been required by
the spec license.
Sound good?
andrew
Re: Proposal for 10.2 release schedule
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Jean T. Anderson wrote:
>>
>>I believe some of the features were already originally planning on
>>an august 15 or later date, and have adjusted to an august 10 date.
>>Some definitely won't make it with an earlier code freeze.
>
>
> There's no "code freeze" per se on ASF projects.
>
sorry, I never meant to imply a code freeze - I agree that there should
not be a freeze. Branching the code earlier gives the release and
developers what they need. And in the branch we should not "freeze",
though it is nice to either give the release coordinator a chance to
bump the release id in the branch, or to do so your self as was done
with the 10.1.3 release.
I meant that features that are being targeted for the 10.2 relese may
not make the proposed branch date.
Re: Proposal for 10.2 release schedule
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Mike Matrigali wrote:
>
>
> Rick Hillegas wrote:
>
>> Thanks, Kathy. I think I'm getting the message that the following
>> would be an acceptable and more traditional schedule:
>>
>> August 10 : Last feature work commits
>> August 11 : First release candidate generated
>> August 24 : Second release candidate generated
>> September 7: Third and hopefully last release candidate generated
>> September 15: Targetted end of voting on release candidates
>>
>> Is this a realistic schedule or is it still too aggressive?
>>
>> Thanks,
>> -Rick
>
>
> What kind of changes are you going to include in each of the
> release candidates (ie. all checkins to the branch, or some subset
> of those changes -- I think in the past andrew has used either)?
> The above seems reasonable assuming that
> the only changes are bug fixes addressing regressions shown
> up by testing. I assume it is reasonable to accept all additional
> tests during the release testing period.
>
> I believe some of the features were already originally planning on
> an august 15 or later date, and have adjusted to an august 10 date.
> Some definitely won't make it with an earlier code freeze.
There's no "code freeze" per se on ASF projects.
The release manager decides what changes should make it into a release.
Good info for the httpd project gets referenced by many:
http://httpd.apache.org/dev/release.html
> Let's repeat that: an impending release can not affect development of the project. It is the RM's responsibility to identify what changes should make it into the release. The RM may have an intermediate tag, so the RM can merge in or reject changes as they are committed to the repository's HEAD.
>
> Committers may voluntarily refrain from committing patches if they wish to ease the burden on the RM, but they are under no obligation to do so. This is one reason why we recommend that the RMs have plenty of time on their hands - they may have to deal with a rapidly changing target. It's not an easy job.
I just get a little worried when I hear the words "code freeze". I think
a better phrase would be "target date". After that date developers can
continue developing and it's up to the release manager to include that
work (or not).
-jean
Re: Proposal for 10.2 release schedule
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Mike,
Some responses follow. Regards-Rick
Mike Matrigali wrote:
>
>
> Rick Hillegas wrote:
>
>> Thanks, Kathy. I think I'm getting the message that the following
>> would be an acceptable and more traditional schedule:
>>
>> August 10 : Last feature work commits
>> August 11 : First release candidate generated
>> August 24 : Second release candidate generated
>> September 7: Third and hopefully last release candidate generated
>> September 15: Targetted end of voting on release candidates
>>
>> Is this a realistic schedule or is it still too aggressive?
>>
>> Thanks,
>> -Rick
>
>
> What kind of changes are you going to include in each of the
> release candidates (ie. all checkins to the branch, or some subset
> of those changes -- I think in the past andrew has used either)?
> The above seems reasonable assuming that
> the only changes are bug fixes addressing regressions shown
> up by testing. I assume it is reasonable to accept all additional
> tests during the release testing period.
I was hoping that only bug fixes would go into the branch and that each
release candidate would just roll up those bug fixes. The release
candidates would be snapshots of the branch at the time the candidates
are cut. I hope this is reasonable.
>
> I believe some of the features were already originally planning on
> an august 15 or later date, and have adjusted to an august 10 date.
> Some definitely won't make it with an earlier code freeze.
>
> What is the assumption about bug fixing of outstanding bugs
> known before august 10th? Maybe there is a published list of
> bugs that need to be fixed for a successful release?
>
I need to start compiling this list. Fortunately, Kathey is already
forging ahead, raising the priority of suspect bugs. I have been putting
off this task until we reach consensus about the date for branching.
Re: Proposal for 10.2 release schedule
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Rick Hillegas wrote:
> Thanks, Kathy. I think I'm getting the message that the following would
> be an acceptable and more traditional schedule:
>
> August 10 : Last feature work commits
> August 11 : First release candidate generated
> August 24 : Second release candidate generated
> September 7: Third and hopefully last release candidate generated
> September 15: Targetted end of voting on release candidates
>
> Is this a realistic schedule or is it still too aggressive?
>
> Thanks,
> -Rick
What kind of changes are you going to include in each of the
release candidates (ie. all checkins to the branch, or some subset
of those changes -- I think in the past andrew has used either)?
The above seems reasonable assuming that
the only changes are bug fixes addressing regressions shown
up by testing. I assume it is reasonable to accept all additional
tests during the release testing period.
I believe some of the features were already originally planning on
an august 15 or later date, and have adjusted to an august 10 date.
Some definitely won't make it with an earlier code freeze.
What is the assumption about bug fixing of outstanding bugs
known before august 10th? Maybe there is a published list of
bugs that need to be fixed for a successful release?
Re: Proposal for 10.2 release schedule
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Kathy Saunders wrote:
> Rick Hillegas wrote:
>
>> Thanks, Kathy. I think I'm getting the message that the following
>> would be an acceptable and more traditional schedule:
>>
>> August 10 : Last feature work commits
>> August 11 : First release candidate generated
>> August 24 : Second release candidate generated
>> September 7: Third and hopefully last release candidate generated
>> September 15: Targetted end of voting on release candidates
>>
>> Is this a realistic schedule or is it still too aggressive?
>>
>> Thanks,
>> -Rick
>
> In my opinion that is a reasonable schedule. Of course, number of
> release candidates and final dates are dependent on the quality of the
> code. But, based on what I've seen with Derby releases so far, this
> timeframe seems like it can work.
>
> Hopefully the licensing issues will be resolved prior to August 10 as well.
A license that allows creating the release candidate must be in place
before the release candidate is made available.
Lance, how do these dates work from a licensing perspective?
-jean
Re: Proposal for 10.2 release schedule
Posted by Kathy Saunders <ka...@mtrad.com>.
Rick Hillegas wrote:
> Thanks, Kathy. I think I'm getting the message that the following
> would be an acceptable and more traditional schedule:
>
> August 10 : Last feature work commits
> August 11 : First release candidate generated
> August 24 : Second release candidate generated
> September 7: Third and hopefully last release candidate generated
> September 15: Targetted end of voting on release candidates
>
> Is this a realistic schedule or is it still too aggressive?
>
> Thanks,
> -Rick
In my opinion that is a reasonable schedule. Of course, number of
release candidates and final dates are dependent on the quality of the
code. But, based on what I've seen with Derby releases so far, this
timeframe seems like it can work.
Hopefully the licensing issues will be resolved prior to August 10 as well.
>
> Kathy Saunders wrote:
>
>> Rick Hillegas wrote:
>>
>>> Thanks, Rajesh. In your scheme, when should feature work on 10.2
>>> wrap up? I had budgeted 2 weeks between the end of feature work and
>>> the first release candidate. Is that overkill? Should we propose
>>> that feature work wraps up by, say, July 27?
>>
>>
>>
>> Do we need to have a feature wrap up and then time to do more
>> development? Can't we just say that all planned work--features, bug
>> fixes, etc. should be done by August 10? Then you could post the
>> first RC on August 11 or shortly after that. It's true that feature
>> check-ins might cause some bugs that need to be dealt with, but those
>> can be dealt with in RC2 if need be.
>>
>> Kathy
>>
>>>
>>> Rajesh Kartha wrote:
>>>
>>>> Rick Hillegas wrote:
>>>>
>>>>> Last week, Sun Microsystems announced that it will bundle Derby
>>>>> with the next major release of the reference jdk, Java SE 6, also
>>>>> known as Mustang or jdk1.6. If you download the latest Mustang
>>>>> build, you will see that it contains our Derby 10.2.0.3 snapshot
>>>>> in the "db" directory parallel to "lib" and "bin".
>>>>>
>>>>> This is big news. It means that over the course of the next year,
>>>>> Derby will turn up on the desktops of millions of developers.
>>>>> Hopefully, Derby's user and developer communities will both grow
>>>>> dramatically.
>>>>>
>>>>> I would like to support this bundling. Note that Mustang will need
>>>>> our vetted 10.2 release candidate by September 15 so that they can
>>>>> QA it. This is expected to take about 5 weeks, after which Mustang
>>>>> should go GA in late October.
>>>>>
>>>>> The JCP requires that our JDBC4-exposing release can not be
>>>>> generally available until the JDBC4 specification is finalized,
>>>>> which happens when Mustang is generally available. Until that
>>>>> date, this means that our final, vetted release candidate can not
>>>>> be officially stamped as "GA" and we can not promote it to the
>>>>> various Apache mirrors.
>>>>>
>>>>> Here are proposed dates for 10.2 milestones:
>>>>>
>>>>> August 10 - Feature work committed. 10.2 branch created.
>>>>> August 24 - Last day to commit changes for 10.2
>>>>> August 25 - Begin vetting 10.2 release candidate
>>>>> September 15 - Target date for finishing the voting on Derby 10.2
>>>>> End of October - Expected GA of JDBC4 with Mustang
>>>>> End of October - GA of Derby 10.2. Release promoted to Apache
>>>>> mirrors.
>>>>>
>>>>> Are this proposal and its dates reasonable?
>>>>>
>>>>>
>>>> Hi Rick,
>>>>
>>>> On careful review of the dates you posted, it looks like the time
>>>> frame for testing is just about 3 weeks (Aug 25 - Sept 15). 10.2
>>>> being a major release with lots
>>>> of new features/fixes, we need to make sure there is enough time
>>>> for the community to test the release and 3 weeks sure seems less.
>>>> My experience during all the previous releases of Derby is that we
>>>> invariably had multiple release candidates - hence the 10.2 testing
>>>> time frame
>>>> needs to take this into account.
>>>>
>>>> I suggest one of the following two:
>>>>
>>>> 1) Keep the date to complete voting for Derby 10.2 as Sept 15:
>>>>
>>>> To achieve this, we move the last day to commit changes early,
>>>> which would mean: August 10 - Last day to commit changes for 10.2
>>>> August 11 - Release Candidate 1 ready for testing
>>>> September 15 - Target date for finishing the voting on Derby 10.2
>>>>
>>>> 2) Push the date to complete voting for Derby 10.2 to Oct 2:
>>>> August 24 - Last day to commit changes for 10.2
>>>> August 25 - Begin vetting 10.2 release candidate
>>>> Oct 2nd - Target date for finishing the voting on Derby 10.2
>>>> This will give us about 5 weeks in both the cases, within
>>>> which we can provision for RC2 if needed.
>>>>
>>>> Let me know what you think.
>>>>
>>>> Regards,
>>>> Rajesh
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
Re: Proposal for 10.2 release schedule
Posted by Rick Hillegas <Ri...@Sun.COM>.
Thanks, Kathy. I think I'm getting the message that the following would
be an acceptable and more traditional schedule:
August 10 : Last feature work commits
August 11 : First release candidate generated
August 24 : Second release candidate generated
September 7: Third and hopefully last release candidate generated
September 15: Targetted end of voting on release candidates
Is this a realistic schedule or is it still too aggressive?
Thanks,
-Rick
Kathy Saunders wrote:
> Rick Hillegas wrote:
>
>> Thanks, Rajesh. In your scheme, when should feature work on 10.2 wrap
>> up? I had budgeted 2 weeks between the end of feature work and the
>> first release candidate. Is that overkill? Should we propose that
>> feature work wraps up by, say, July 27?
>
>
> Do we need to have a feature wrap up and then time to do more
> development? Can't we just say that all planned work--features, bug
> fixes, etc. should be done by August 10? Then you could post the
> first RC on August 11 or shortly after that. It's true that feature
> check-ins might cause some bugs that need to be dealt with, but those
> can be dealt with in RC2 if need be.
>
> Kathy
>
>>
>> Rajesh Kartha wrote:
>>
>>> Rick Hillegas wrote:
>>>
>>>> Last week, Sun Microsystems announced that it will bundle Derby
>>>> with the next major release of the reference jdk, Java SE 6, also
>>>> known as Mustang or jdk1.6. If you download the latest Mustang
>>>> build, you will see that it contains our Derby 10.2.0.3 snapshot in
>>>> the "db" directory parallel to "lib" and "bin".
>>>>
>>>> This is big news. It means that over the course of the next year,
>>>> Derby will turn up on the desktops of millions of developers.
>>>> Hopefully, Derby's user and developer communities will both grow
>>>> dramatically.
>>>>
>>>> I would like to support this bundling. Note that Mustang will need
>>>> our vetted 10.2 release candidate by September 15 so that they can
>>>> QA it. This is expected to take about 5 weeks, after which Mustang
>>>> should go GA in late October.
>>>>
>>>> The JCP requires that our JDBC4-exposing release can not be
>>>> generally available until the JDBC4 specification is finalized,
>>>> which happens when Mustang is generally available. Until that date,
>>>> this means that our final, vetted release candidate can not be
>>>> officially stamped as "GA" and we can not promote it to the
>>>> various Apache mirrors.
>>>>
>>>> Here are proposed dates for 10.2 milestones:
>>>>
>>>> August 10 - Feature work committed. 10.2 branch created.
>>>> August 24 - Last day to commit changes for 10.2
>>>> August 25 - Begin vetting 10.2 release candidate
>>>> September 15 - Target date for finishing the voting on Derby 10.2
>>>> End of October - Expected GA of JDBC4 with Mustang
>>>> End of October - GA of Derby 10.2. Release promoted to Apache mirrors.
>>>>
>>>> Are this proposal and its dates reasonable?
>>>>
>>>>
>>> Hi Rick,
>>>
>>> On careful review of the dates you posted, it looks like the time
>>> frame for testing is just about 3 weeks (Aug 25 - Sept 15). 10.2
>>> being a major release with lots
>>> of new features/fixes, we need to make sure there is enough time
>>> for the community to test the release and 3 weeks sure seems less.
>>> My experience during all the previous releases of Derby is that we
>>> invariably had multiple release candidates - hence the 10.2 testing
>>> time frame
>>> needs to take this into account.
>>>
>>> I suggest one of the following two:
>>>
>>> 1) Keep the date to complete voting for Derby 10.2 as Sept 15:
>>>
>>> To achieve this, we move the last day to commit changes early,
>>> which would mean: August 10 - Last day to commit changes for 10.2
>>> August 11 - Release Candidate 1 ready for testing
>>> September 15 - Target date for finishing the voting on Derby 10.2
>>>
>>> 2) Push the date to complete voting for Derby 10.2 to Oct 2:
>>> August 24 - Last day to commit changes for 10.2
>>> August 25 - Begin vetting 10.2 release candidate
>>> Oct 2nd - Target date for finishing the voting on Derby 10.2
>>> This will give us about 5 weeks in both the cases, within
>>> which we can provision for RC2 if needed.
>>>
>>> Let me know what you think.
>>>
>>> Regards,
>>> Rajesh
>>
>>
>>
>>
>>
>>
>>
>>
>
>
Re: Proposal for 10.2 release schedule
Posted by Kathy Saunders <ka...@mtrad.com>.
Rick Hillegas wrote:
> Thanks, Rajesh. In your scheme, when should feature work on 10.2 wrap
> up? I had budgeted 2 weeks between the end of feature work and the
> first release candidate. Is that overkill? Should we propose that
> feature work wraps up by, say, July 27?
Do we need to have a feature wrap up and then time to do more
development? Can't we just say that all planned work--features, bug
fixes, etc. should be done by August 10? Then you could post the first
RC on August 11 or shortly after that. It's true that feature check-ins
might cause some bugs that need to be dealt with, but those can be dealt
with in RC2 if need be.
Kathy
>
> Rajesh Kartha wrote:
>
>> Rick Hillegas wrote:
>>
>>> Last week, Sun Microsystems announced that it will bundle Derby with
>>> the next major release of the reference jdk, Java SE 6, also known
>>> as Mustang or jdk1.6. If you download the latest Mustang build, you
>>> will see that it contains our Derby 10.2.0.3 snapshot in the "db"
>>> directory parallel to "lib" and "bin".
>>>
>>> This is big news. It means that over the course of the next year,
>>> Derby will turn up on the desktops of millions of developers.
>>> Hopefully, Derby's user and developer communities will both grow
>>> dramatically.
>>>
>>> I would like to support this bundling. Note that Mustang will need
>>> our vetted 10.2 release candidate by September 15 so that they can
>>> QA it. This is expected to take about 5 weeks, after which Mustang
>>> should go GA in late October.
>>>
>>> The JCP requires that our JDBC4-exposing release can not be
>>> generally available until the JDBC4 specification is finalized,
>>> which happens when Mustang is generally available. Until that date,
>>> this means that our final, vetted release candidate can not be
>>> officially stamped as "GA" and we can not promote it to the various
>>> Apache mirrors.
>>>
>>> Here are proposed dates for 10.2 milestones:
>>>
>>> August 10 - Feature work committed. 10.2 branch created.
>>> August 24 - Last day to commit changes for 10.2
>>> August 25 - Begin vetting 10.2 release candidate
>>> September 15 - Target date for finishing the voting on Derby 10.2
>>> End of October - Expected GA of JDBC4 with Mustang
>>> End of October - GA of Derby 10.2. Release promoted to Apache mirrors.
>>>
>>> Are this proposal and its dates reasonable?
>>>
>>>
>> Hi Rick,
>>
>> On careful review of the dates you posted, it looks like the time
>> frame for testing is just about 3 weeks (Aug 25 - Sept 15). 10.2
>> being a major release with lots
>> of new features/fixes, we need to make sure there is enough time for
>> the community to test the release and 3 weeks sure seems less.
>> My experience during all the previous releases of Derby is that we
>> invariably had multiple release candidates - hence the 10.2 testing
>> time frame
>> needs to take this into account.
>>
>> I suggest one of the following two:
>>
>> 1) Keep the date to complete voting for Derby 10.2 as Sept 15:
>>
>> To achieve this, we move the last day to commit changes early,
>> which would mean: August 10 - Last day to commit changes for 10.2
>> August 11 - Release Candidate 1 ready for testing
>> September 15 - Target date for finishing the voting on Derby 10.2
>>
>> 2) Push the date to complete voting for Derby 10.2 to Oct 2:
>> August 24 - Last day to commit changes for 10.2
>> August 25 - Begin vetting 10.2 release candidate
>> Oct 2nd - Target date for finishing the voting on Derby 10.2
>> This will give us about 5 weeks in both the cases, within which
>> we can provision for RC2 if needed.
>>
>> Let me know what you think.
>>
>> Regards,
>> Rajesh
>
>
>
>
>
>
>
Re: Proposal for 10.2 release schedule
Posted by Rick Hillegas <Ri...@Sun.COM>.
Thanks, Rajesh. In your scheme, when should feature work on 10.2 wrap
up? I had budgeted 2 weeks between the end of feature work and the first
release candidate. Is that overkill? Should we propose that feature work
wraps up by, say, July 27?
Rajesh Kartha wrote:
> Rick Hillegas wrote:
>
>> Last week, Sun Microsystems announced that it will bundle Derby with
>> the next major release of the reference jdk, Java SE 6, also known as
>> Mustang or jdk1.6. If you download the latest Mustang build, you will
>> see that it contains our Derby 10.2.0.3 snapshot in the "db"
>> directory parallel to "lib" and "bin".
>>
>> This is big news. It means that over the course of the next year,
>> Derby will turn up on the desktops of millions of developers.
>> Hopefully, Derby's user and developer communities will both grow
>> dramatically.
>>
>> I would like to support this bundling. Note that Mustang will need
>> our vetted 10.2 release candidate by September 15 so that they can QA
>> it. This is expected to take about 5 weeks, after which Mustang
>> should go GA in late October.
>>
>> The JCP requires that our JDBC4-exposing release can not be generally
>> available until the JDBC4 specification is finalized, which happens
>> when Mustang is generally available. Until that date, this means that
>> our final, vetted release candidate can not be officially stamped as
>> "GA" and we can not promote it to the various Apache mirrors.
>>
>> Here are proposed dates for 10.2 milestones:
>>
>> August 10 - Feature work committed. 10.2 branch created.
>> August 24 - Last day to commit changes for 10.2
>> August 25 - Begin vetting 10.2 release candidate
>> September 15 - Target date for finishing the voting on Derby 10.2
>> End of October - Expected GA of JDBC4 with Mustang
>> End of October - GA of Derby 10.2. Release promoted to Apache mirrors.
>>
>> Are this proposal and its dates reasonable?
>>
>>
> Hi Rick,
>
> On careful review of the dates you posted, it looks like the time
> frame for testing is just about 3 weeks (Aug 25 - Sept 15). 10.2
> being a major release with lots
> of new features/fixes, we need to make sure there is enough time for
> the community to test the release and 3 weeks sure seems less.
> My experience during all the previous releases of Derby is that we
> invariably had multiple release candidates - hence the 10.2 testing
> time frame
> needs to take this into account.
>
> I suggest one of the following two:
>
> 1) Keep the date to complete voting for Derby 10.2 as Sept 15:
>
> To achieve this, we move the last day to commit changes early,
> which would mean:
> August 10 - Last day to commit changes for 10.2
> August 11 - Release Candidate 1 ready for testing
> September 15 - Target date for finishing the voting on Derby 10.2
>
> 2) Push the date to complete voting for Derby 10.2 to Oct 2:
> August 24 - Last day to commit changes for 10.2
> August 25 - Begin vetting 10.2 release candidate
> Oct 2nd - Target date for finishing the voting on Derby 10.2
> This will give us about 5 weeks in both the cases, within which
> we can provision for RC2 if needed.
>
> Let me know what you think.
>
> Regards,
> Rajesh
Re: Proposal for 10.2 release schedule
Posted by Rajesh Kartha <ka...@gmail.com>.
Rick Hillegas wrote:
> Last week, Sun Microsystems announced that it will bundle Derby with
> the next major release of the reference jdk, Java SE 6, also known as
> Mustang or jdk1.6. If you download the latest Mustang build, you will
> see that it contains our Derby 10.2.0.3 snapshot in the "db" directory
> parallel to "lib" and "bin".
>
> This is big news. It means that over the course of the next year,
> Derby will turn up on the desktops of millions of developers.
> Hopefully, Derby's user and developer communities will both grow
> dramatically.
>
> I would like to support this bundling. Note that Mustang will need our
> vetted 10.2 release candidate by September 15 so that they can QA it.
> This is expected to take about 5 weeks, after which Mustang should go
> GA in late October.
>
> The JCP requires that our JDBC4-exposing release can not be generally
> available until the JDBC4 specification is finalized, which happens
> when Mustang is generally available. Until that date, this means that
> our final, vetted release candidate can not be officially stamped as
> "GA" and we can not promote it to the various Apache mirrors.
>
> Here are proposed dates for 10.2 milestones:
>
> August 10 - Feature work committed. 10.2 branch created.
> August 24 - Last day to commit changes for 10.2
> August 25 - Begin vetting 10.2 release candidate
> September 15 - Target date for finishing the voting on Derby 10.2
> End of October - Expected GA of JDBC4 with Mustang
> End of October - GA of Derby 10.2. Release promoted to Apache mirrors.
>
> Are this proposal and its dates reasonable?
>
>
Hi Rick,
On careful review of the dates you posted, it looks like the time frame
for testing is just about 3 weeks (Aug 25 - Sept 15). 10.2 being a
major release with lots
of new features/fixes, we need to make sure there is enough time for
the community to test the release and 3 weeks sure seems less.
My experience during all the previous releases of Derby is that we
invariably had multiple release candidates - hence the 10.2 testing time
frame
needs to take this into account.
I suggest one of the following two:
1) Keep the date to complete voting for Derby 10.2 as Sept 15:
To achieve this, we move the last day to commit changes early, which
would mean:
August 10 - Last day to commit changes for 10.2
August 11 - Release Candidate 1 ready for testing
September 15 - Target date for finishing the voting on Derby 10.2
2) Push the date to complete voting for Derby 10.2 to Oct 2:
August 24 - Last day to commit changes for 10.2
August 25 - Begin vetting 10.2 release candidate
Oct 2nd - Target date for finishing the voting on Derby 10.2
This will give us about 5 weeks in both the cases, within which we
can provision for RC2 if needed.
Let me know what you think.
Regards,
Rajesh
Re: Proposal for 10.2 release schedule
Posted by Daniel John Debrunner <dj...@apache.org>.
Daniel John Debrunner wrote:
> Thomas Dudziak wrote:
tw, to which files does the COPYRIGHT containing an IBM copyright
>>notice refer to ? A search in the Derby sources did not bring up any
>>source copyrighted by IBM.
>
>
> The original contribution of Derby was from IBM, hence IBM has the
> copyright on all those original files.
Just in case this wasn't clear, IBM holds the copyright on its
contributions in those files, just like any other contributor to an
Apache project. Contributors to an Apache project retain the copyright
on their contributions, they are licencing it to the ASF under the
Apache Licence Version 2.
Dan.
Re: Derby copyright questions (was Re: Proposal for 10.2 release schedule)
Posted by Thomas Dudziak <to...@gmail.com>.
Hi Jean,
On 6/26/06, Jean T. Anderson <jt...@bristowhill.com> wrote:
> The original Software Grant provides an ASF record of the files that
> were originally contributed -- as does the subversion repository itself,
> which provides a record of both the files that were contributed
> originally and the files that were added later.
>
> The convention Derby uses in the code headers came out of lengthy
> discussions on general@incubator.apache.org and derby-dev@db.apache.org
> -- see the archives at http://mail-archives.apache.org/mod_mbox in the
> September/October 2004 time frame.
Thanks for the clarification.
cheers,
Tom
Derby copyright questions (was Re: Proposal for 10.2 release schedule)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Thomas Dudziak wrote:
> On 6/24/06, Daniel John Debrunner <dj...@apache.org> wrote:
...
>> > Btw, to which files does the COPYRIGHT containing an IBM copyright
>> > notice refer to ? A search in the Derby sources did not bring up any
>> > source copyrighted by IBM.
>>
>> The original contribution of Derby was from IBM, hence IBM has the
>> copyright on all those original files. The ASF policy is not to have
>> individiual copyright statements in each source file and the new policy
>> (I think) is to remove the copyright statement in each source file,
>> leaving just the reference to the Apache Licence in the source file.
>
> Yeah, sure, Apache uses a Copyright license instead of a copyright
> transfer. But, well, the interesting thing is that in the individual
> files there is always a line like:
>
> Copyright 2005 The Apache Software Foundation or its licensors, as
> applicable.
>
> Which basically means that there is no means to distinguish the files
> IBM contributed originally, and the new ones.
The original Software Grant provides an ASF record of the files that
were originally contributed -- as does the subversion repository itself,
which provides a record of both the files that were contributed
originally and the files that were added later.
The convention Derby uses in the code headers came out of lengthy
discussions on general@incubator.apache.org and derby-dev@db.apache.org
-- see the archives at http://mail-archives.apache.org/mod_mbox in the
September/October 2004 time frame.
I hope this helps clarify things (at least a little),
-jean
Re: Proposal for 10.2 release schedule
Posted by Thomas Dudziak <to...@gmail.com>.
On 6/24/06, Daniel John Debrunner <dj...@apache.org> wrote:
> Thomas Dudziak wrote:
> > On 6/22/06, Rick Hillegas <Ri...@sun.com> wrote:
> >
> >> Last week, Sun Microsystems announced that it will bundle Derby with the
> >> next major release of the reference jdk, Java SE 6, also known as
> >> Mustang or jdk1.6. If you download the latest Mustang build, you will
> >> see that it contains our Derby 10.2.0.3 snapshot in the "db" directory
> >> parallel to "lib" and "bin".
> >
> >
> > Is this Derby or JavaDB ?
>
> Sun Microsystems announced that it will bundle "Java DB"
> with Mustang.
>
> http://biz.yahoo.com/prnews/060621/sfw063.html?.v=66
IMHO they definitely should put in a link to JavaDB (and perhaps
Derby) in a README in the db folder.
> > I imagine that the Derby update
> > cycle will synchronize somewhat with the JDK update cycle,
>
> I doubt Derby's release cycle will synchronize with the Sun's JDK
> release. Sun's JDK is just one of many that distribute Derby technology.
>
> http://wiki.apache.org/db-derby/UsesOfDerby
Yes, well, but how many of these bundle Derby ? And how many of them
have the 'reach' of the JDK ? I'd think that if the JDK enters the
cycle for, say, update 1, there is a strong incentive that a
Derby/JavaDB release is finished by then in order to include it in the
JDK.
> > Btw, to which files does the COPYRIGHT containing an IBM copyright
> > notice refer to ? A search in the Derby sources did not bring up any
> > source copyrighted by IBM.
>
> The original contribution of Derby was from IBM, hence IBM has the
> copyright on all those original files. The ASF policy is not to have
> individiual copyright statements in each source file and the new policy
> (I think) is to remove the copyright statement in each source file,
> leaving just the reference to the Apache Licence in the source file.
Yeah, sure, Apache uses a Copyright license instead of a copyright
transfer. But, well, the interesting thing is that in the individual
files there is always a line like:
Copyright 2005 The Apache Software Foundation or its licensors, as applicable.
Which basically means that there is no means to distinguish the files
IBM contributed originally, and the new ones.
Tom
Re: Proposal for 10.2 release schedule
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Daniel John Debrunner wrote:
> Thomas Dudziak wrote:
...
>>Btw, to which files does the COPYRIGHT containing an IBM copyright
>>notice refer to ? A search in the Derby sources did not bring up any
>>source copyrighted by IBM.
>
> The original contribution of Derby was from IBM, hence IBM has the
> copyright on all those original files. The ASF policy is not to have
> individiual copyright statements in each source file and the new policy
> (I think) is to remove the copyright statement in each source file,
> leaving just the reference to the Apache Licence in the source file.
two clarifying notes ...
The thread for the new policy starts at [1]. It moves only the ASF
copyright to the NOTICE file [2]. Users interested in this change wrt to
DERBY can track DERBY-1377 [3].
The derby NOTICE file [4] already references the IBM contribution, which
ties back into Dan's point (I hope).
-jean
[1]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/%3c1551070F-EDE7-40DC-9C97-79BF24E9FD59@apache.org%3e
[2]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/%3c8042AD24-06D7-4A38-B748-F80361F14082@gbiv.com%3e
[3] http://issues.apache.org/jira/browse/DERBY-1377
[4] https://svn.apache.org/repos/asf/db/derby/code/trunk/NOTICE
Re: Counting subscribers
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Leslie Software wrote:
> ----- Original Message ----
> From: Jean T. Anderson <jt...@bristowhill.com>
> <snip>>Derby graduated last July -- time flies! -- and the user community has
>
>>grown rapidly. derby-user started with 0 subscribers in August 2004, had
>>grown to 282 when it graduated in July 2005, and today has 411.
>
> <snip>
>
> I am curious. How are the number of subscribers you quoted counted? I want to make sure I have done the right thing to be counted:-)
Mail statistics are here:
http://people.apache.org/~coar/mlists.html#db.apache.org
Today derby-user has 412 subscribers (362 on the main list and 50
subscribed to the digest).
cheers,
-jean
Counting subscribers (was Re: Proposal for 10.2 release schedule)
Posted by Leslie Software <le...@yahoo.com>.
----- Original Message ----
From: Jean T. Anderson <jt...@bristowhill.com>
<snip>>Derby graduated last July -- time flies! -- and the user community has
>grown rapidly. derby-user started with 0 subscribers in August 2004, had
>grown to 282 when it graduated in July 2005, and today has 411.
<snip>
I am curious. How are the number of subscribers you quoted counted? I want to make sure I have done the right thing to be counted:-)
Thanks,
Ian
RE: Proposal for 10.2 release schedule
Posted by Michael Segel <ms...@segel.com>.
> -----Original Message-----
> From: Jean T. Anderson [mailto:jta@bristowhill.com]
> Sent: Sunday, June 25, 2006 9:38 AM
> To: Derby Discussion
> Subject: Re: Proposal for 10.2 release schedule
>
> Daniel John Debrunner wrote:
> > derby@segel.com wrote:
> >>>-----Original Message-----
> >>>From: Daniel John Debrunner [mailto:djd@apache.org]
> >>>
> >>>The original contribution of Derby was from IBM, hence IBM has the
> >>>copyright on all those original files. The ASF policy is not to have
> >>>individiual copyright statements in each source file and the new policy
> >>>(I think) is to remove the copyright statement in each source file,
> >>>leaving just the reference to the Apache Licence in the source file.
> >>>
> >>>Dan.
> >>
> >>
> >>[mjs]
> >>That would not be a good idea, and I suggest that you have IP attorneys
> from
> >>IBM make a final recommendation on this. (No need for Apache to spend
> money
> >>if IBM has the resources and its in IBM's best interest to do
> something.)
> >>
> >>Here's why:
> >
> > <legal stuff snipped>
> >
> > Michael, you should probably check out the legal-disucss mailing list
> > archives, I'm sure all of this was covered.
>
[mjs]
Naw.
I'd rather watch the World Cup. Or maybe have a root canal. ;-)
> It might be helpful for derby-user as a whole to understand that the
> Apache Incubator requires resolving any ip issues *before* a project
> graduates from the Incubator. Lots of information is at
> http://incubator.apache.org/ . A project simply won't graduate if there
> is a pending legal matter. After graduation, legal oversight continues
> by the project's PMC (Derby is a subproject of the DB PMC).
>
>
> -jean
>
[mjs] Uhm
Maybe I'm not being clear.
Derby may have graduated from Incubator status, but that doesn't mean that
the potential for copyright infringement or theft of IP issues are completed
and done with.
If I'm not mistaken, there's a lot of feature requests. It's possible that
in solving a feature request, an IP/Copyright violation may occur, or the
threat of litigation arising from a contribution can occur.
My point is that you're going to want to leave as much detail that is in the
code as possible.
The reason is that its easier to defend against any lawsuit or to identify
the potential violator.
(Sure you can go through the source code tree, but even then, you may have
issues.)
Here in the US, we live in a society that has too many lawyers....
Even if someone wrote some code from scratch, yet it has many similarities
to some source code that is copyrighted, you're going to have the potential
of litigation.
Re: Proposal for 10.2 release schedule
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Daniel John Debrunner wrote:
> derby@segel.com wrote:
>>>-----Original Message-----
>>>From: Daniel John Debrunner [mailto:djd@apache.org]
>>>
>>>The original contribution of Derby was from IBM, hence IBM has the
>>>copyright on all those original files. The ASF policy is not to have
>>>individiual copyright statements in each source file and the new policy
>>>(I think) is to remove the copyright statement in each source file,
>>>leaving just the reference to the Apache Licence in the source file.
>>>
>>>Dan.
>>
>>
>>[mjs]
>>That would not be a good idea, and I suggest that you have IP attorneys from
>>IBM make a final recommendation on this. (No need for Apache to spend money
>>if IBM has the resources and its in IBM's best interest to do something.)
>>
>>Here's why:
>
> <legal stuff snipped>
>
> Michael, you should probably check out the legal-disucss mailing list
> archives, I'm sure all of this was covered.
It might be helpful for derby-user as a whole to understand that the
Apache Incubator requires resolving any ip issues *before* a project
graduates from the Incubator. Lots of information is at
http://incubator.apache.org/ . A project simply won't graduate if there
is a pending legal matter. After graduation, legal oversight continues
by the project's PMC (Derby is a subproject of the DB PMC).
Derby graduated last July -- time flies! -- and the user community has
grown rapidly. derby-user started with 0 subscribers in August 2004, had
grown to 282 when it graduated in July 2005, and today has 411.
Here's to the next 100 users!
-jean
Re: Proposal for 10.2 release schedule
Posted by Daniel John Debrunner <dj...@apache.org>.
derby@segel.com wrote:
>
>>-----Original Message-----
>>From: Daniel John Debrunner [mailto:djd@apache.org]
>>
>>The original contribution of Derby was from IBM, hence IBM has the
>>copyright on all those original files. The ASF policy is not to have
>>individiual copyright statements in each source file and the new policy
>>(I think) is to remove the copyright statement in each source file,
>>leaving just the reference to the Apache Licence in the source file.
>>
>>Dan.
>
>
> [mjs]
> That would not be a good idea, and I suggest that you have IP attorneys from
> IBM make a final recommendation on this. (No need for Apache to spend money
> if IBM has the resources and its in IBM's best interest to do something.)
>
> Here's why:
<legal stuff snipped>
Michael, you should probably check out the legal-disucss mailing list
archives, I'm sure all of this was covered.
Dan.
RE: Proposal for 10.2 release schedule
Posted by de...@segel.com.
> -----Original Message-----
> From: Daniel John Debrunner [mailto:djd@apache.org]
>
> The original contribution of Derby was from IBM, hence IBM has the
> copyright on all those original files. The ASF policy is not to have
> individiual copyright statements in each source file and the new policy
> (I think) is to remove the copyright statement in each source file,
> leaving just the reference to the Apache Licence in the source file.
>
> Dan.
[mjs]
That would not be a good idea, and I suggest that you have IP attorneys from
IBM make a final recommendation on this. (No need for Apache to spend money
if IBM has the resources and its in IBM's best interest to do something.)
Here's why:
Indemnification. Each contributor of Derby agrees to indemnify Apache in the
case of a lawsuit due to copyright infringement.
In simple terms, this means, if you contribute code, and then someone claims
that said code violates either their copyright, patent or was stolen, then
you and your company is on the hook for the cost of any legal challenge.
By leaving the copyright notice intact, you're preserving the forensic
information, thus making it easier to 1) determine the source of the alleged
code, and 2) determine who's going to be ultimately responsible to defend
the code...
If you think this is hogwash, then ask yourself how much has IBM spent
defending itself in the SCO suit. Regardless of merit, only Sun and IBM
have deep enough pockets to pay for a defense.
But hey! What do I know? Its not like I had to spend time with IBM legal on
contracts over my tenure at IBM. ;-)
-G
Re: Proposal for 10.2 release schedule
Posted by Daniel John Debrunner <dj...@apache.org>.
Thomas Dudziak wrote:
> On 6/22/06, Rick Hillegas <Ri...@sun.com> wrote:
>
>> Last week, Sun Microsystems announced that it will bundle Derby with the
>> next major release of the reference jdk, Java SE 6, also known as
>> Mustang or jdk1.6. If you download the latest Mustang build, you will
>> see that it contains our Derby 10.2.0.3 snapshot in the "db" directory
>> parallel to "lib" and "bin".
>
>
> Is this Derby or JavaDB ?
Sun Microsystems announced that it will bundle "Java DB"
with Mustang.
http://biz.yahoo.com/prnews/060621/sfw063.html?.v=66
> I imagine that the Derby update
> cycle will synchronize somewhat with the JDK update cycle,
I doubt Derby's release cycle will synchronize with the Sun's JDK
release. Sun's JDK is just one of many that distribute Derby technology.
http://wiki.apache.org/db-derby/UsesOfDerby
>
> Btw, to which files does the COPYRIGHT containing an IBM copyright
> notice refer to ? A search in the Derby sources did not bring up any
> source copyrighted by IBM.
The original contribution of Derby was from IBM, hence IBM has the
copyright on all those original files. The ASF policy is not to have
individiual copyright statements in each source file and the new policy
(I think) is to remove the copyright statement in each source file,
leaving just the reference to the Apache Licence in the source file.
Dan.
Re: Proposal for 10.2 release schedule
Posted by Thomas Dudziak <to...@gmail.com>.
On 6/22/06, Rick Hillegas <Ri...@sun.com> wrote:
> Last week, Sun Microsystems announced that it will bundle Derby with the
> next major release of the reference jdk, Java SE 6, also known as
> Mustang or jdk1.6. If you download the latest Mustang build, you will
> see that it contains our Derby 10.2.0.3 snapshot in the "db" directory
> parallel to "lib" and "bin".
Is this Derby or JavaDB ? I've had a quick look at the JDK, and I
could not find a single link to the Derby project (nor to JavaDB for
that matter), only a NOTICE stating that Derby is included. I think
this should be changed, so that the unwary JDK user exactly knows
where to look for info. Perhaps a README file would be the best place
?
Also, I think the version info given should be more detailed by
stating the exact Derby version (e.g. 10.2.0) once the JDK is
finalized (probably in the README). I imagine that the Derby update
cycle will synchronize somewhat with the JDK update cycle, and then
the revision number (third part of the version number) becomes
important.
Btw, to which files does the COPYRIGHT containing an IBM copyright
notice refer to ? A search in the Derby sources did not bring up any
source copyrighted by IBM.
> This is big news. It means that over the course of the next year, Derby
> will turn up on the desktops of millions of developers. Hopefully,
> Derby's user and developer communities will both grow dramatically.
Just out of curiosity, what is the reason that the JDK bundles a
database (and the JRE does not) ? I mean, there was quite a few
criticism in the blogosphere, so could you perhaps elaborate a bit ?
cheers,
Tom
Re: Proposal for 10.2 release schedule
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Last week, Sun Microsystems announced that it will bundle Derby with the
> next major release of the reference jdk, Java SE 6, also known as
> Mustang or jdk1.6.
To be precise, Sun Microsystems announced that it will bundle "Java DB"
with Mustang.
http://biz.yahoo.com/prnews/060621/sfw063.html?.v=66
Dan.
Re: Proposal for 10.2 release schedule
Posted by "Lance J. Andersen" <La...@Sun.COM>.
David Van Couvering wrote:
> Lance J. Andersen wrote:
>>>
>> You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
>> final.
>
> Are you *sure* you can't *have* a GA version, e.g the bits can't exist
> somewhere, as long as they're not officially declared generally
> available? If we can't even create the bits, then it is physically
> and logically impossible for us to give anything to the JDK team for
> integration.
I think we are talking different things here as you are talking about
getting your final version of your product ready to be released based on
a JSR which is getting ready to go final , which is fine, which is
different from what i was trying to say.
http://jcp.org/en/resources/guide#fab gives you an overview of how a
JSR goes final.
>
> Personally, I think we need to get clarification from the JCP folks on
> this before we make any final conclusions about this.
>
> Thanks,
>
> David
>
Re: Proposal for 10.2 release schedule
Posted by David Van Couvering <Da...@Sun.COM>.
Hi, Lance. Sorry I had to challenge you publicly on the list, but
I'm really worried that if we're not very careful we are going to paint
ourselves into a corner and we are going to have to fork Derby in order
to do a Java DB release.
I think we need the JCP lawyers (and it sounds like the ASF lawyers) to
weigh in on this question before we make any conclusions that could
cause us real trouble.
Thanks,
David
David Van Couvering wrote:
> Lance J. Andersen wrote:
>>>
>> You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final.
>
> Are you *sure* you can't *have* a GA version, e.g the bits can't exist
> somewhere, as long as they're not officially declared generally
> available? If we can't even create the bits, then it is physically and
> logically impossible for us to give anything to the JDK team for
> integration.
>
> Personally, I think we need to get clarification from the JCP folks on
> this before we make any final conclusions about this.
>
> Thanks,
>
> David
>
Re: Proposal for 10.2 release schedule
Posted by David Van Couvering <Da...@Sun.COM>.
Lance J. Andersen wrote:
>>
> You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final.
Are you *sure* you can't *have* a GA version, e.g the bits can't exist
somewhere, as long as they're not officially declared generally
available? If we can't even create the bits, then it is physically and
logically impossible for us to give anything to the JDK team for
integration.
Personally, I think we need to get clarification from the JCP folks on
this before we make any final conclusions about this.
Thanks,
David
Re: Proposal for 10.2 release schedule
Posted by "Lance J. Andersen" <La...@Sun.COM>.
Daniel John Debrunner wrote:
> Andrew McIntyre wrote:
>
>
>> Call in the lawyers:
>>
>>
>>> From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
>>>
>> has executed, being a JCP Member (they've even got quotes from Geir
>> prominently featured on their "about JCP 2.6 page" [2]):
>>
>> 5.B. License to Create Independent Implementations.
>>
>
> Dumb question, is Derby:
>
> - creating an independent implementation of JSR221
> - or is it implementing a driver that adheres to JSR221?
>
> I would say Apache Harmony (when/if they tackle Jave SE 6) would be
> creating an independent implementation of JSR221 and that Derby is not.
>
You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final.
The Derby Embedded and Network Client drivers provide implementations of
the JDBC drivers based on JSR 221.
A Java SE implementation provides the interfaces and concrete classes
that are used by a JDBC driver for the given Java SE implementation.
JSR 221 falls under the umbrella spec for Java SE 6. They all go final
together.
> Dan.
>
>
>
>
>
Re: Proposal for 10.2 release schedule
Posted by Daniel John Debrunner <dj...@apache.org>.
Andrew McIntyre wrote:
> Call in the lawyers:
>
>> From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
>
> has executed, being a JCP Member (they've even got quotes from Geir
> prominently featured on their "about JCP 2.6 page" [2]):
>
> 5.B. License to Create Independent Implementations.
Dumb question, is Derby:
- creating an independent implementation of JSR221
- or is it implementing a driver that adheres to JSR221?
I would say Apache Harmony (when/if they tackle Jave SE 6) would be
creating an independent implementation of JSR221 and that Derby is not.
Dan.
Re: Proposal for 10.2 release schedule
Posted by David Van Couvering <Da...@Sun.COM>.
That said, it's probably also good to hear from the JCP as well. It
would probably help the ASF gauge what their exposure is and what
approaches they feel comfortable with.
David
David Van Couvering wrote:
> OK, good point, thanks.
>
> David
>
> Daniel John Debrunner wrote:
>> David Van Couvering wrote:
>>
>>> Andrew McIntyre wrote:
>>
>>>> Or maybe ask Geir, since he's VP of Java Community Process for the
>>>> Apache Software Foundation, since similar instances may have come up
>>>> fairly recently. [3]
>>>>
>>> Even if we did ask Geir, he's not the last word on it. I'd rather hear
>>> it from the horse's mouth. I or someone else will get back to you.
>>
>> From the ASF point of view, which is what we are discussing here, I
>> rather think Geir is the "horse's mouth". It's the ASF's interpretation
>> of the licence the ASF signed and the risks the ASF is willing to take
>> that matter with a Apache Derby release.
>>
>> Dan.
>>
>>
Re: Proposal for 10.2 release schedule
Posted by David Van Couvering <Da...@Sun.COM>.
OK, good point, thanks.
David
Daniel John Debrunner wrote:
> David Van Couvering wrote:
>
>> Andrew McIntyre wrote:
>
>>> Or maybe ask Geir, since he's VP of Java Community Process for the
>>> Apache Software Foundation, since similar instances may have come up
>>> fairly recently. [3]
>>>
>> Even if we did ask Geir, he's not the last word on it. I'd rather hear
>> it from the horse's mouth. I or someone else will get back to you.
>
> From the ASF point of view, which is what we are discussing here, I
> rather think Geir is the "horse's mouth". It's the ASF's interpretation
> of the licence the ASF signed and the risks the ASF is willing to take
> that matter with a Apache Derby release.
>
> Dan.
>
>
Re: Proposal for 10.2 release schedule
Posted by Daniel John Debrunner <dj...@apache.org>.
David Van Couvering wrote:
> Andrew McIntyre wrote:
>> Or maybe ask Geir, since he's VP of Java Community Process for the
>> Apache Software Foundation, since similar instances may have come up
>> fairly recently. [3]
>>
>
> Even if we did ask Geir, he's not the last word on it. I'd rather hear
> it from the horse's mouth. I or someone else will get back to you.
>From the ASF point of view, which is what we are discussing here, I
rather think Geir is the "horse's mouth". It's the ASF's interpretation
of the licence the ASF signed and the risks the ASF is willing to take
that matter with a Apache Derby release.
Dan.
Re: Proposal for 10.2 release schedule
Posted by David Van Couvering <Da...@Sun.COM>.
Andrew McIntyre wrote:
> Anyway, what's the trigger for breaching the contract here? If it's
> 'creation' alone, then rolling that release candidate surely qualifies
> as as creation. If it's 'creation and distribution,' well, is posting
> the release candidate in a public forum and on a public website (like
> one would have to do to vote on it) considered distribution in this
> case? I have no idea, because i'm not a lawyer.
I don't either. I will try and get someone here to discuss this with
the JCP lawyers and try and get some clarification about 'creation' vs.
'creation and distribution'. I can't see how you can be in trouble for
creating a set of bits that nobody has access to, but IANAL.
I guess you have somewhat answered my question from my other email: you
must, even temporarily, make the official GA bits available for
download, just so we can vote on the release.
Could we remove the download once it's voted on, at least to keep the
window of vulnerability to a minimum? I'm not saying that would satisfy
the lawyers, but I'd like to know what is possible before we talk to them.
How do we handle this normally, if you create a release candidate with
the GA bit set, and then we reject the release. Don't we have the same
problem already, with people getting access to a release that looks and
smells like an official Apache release but actually isn't?
>
> Or maybe ask Geir, since he's VP of Java Community Process for the
> Apache Software Foundation, since similar instances may have come up
> fairly recently. [3]
>
Even if we did ask Geir, he's not the last word on it. I'd rather hear
it from the horse's mouth. I or someone else will get back to you.
Thanks for all your input, and your research!
> andrew
>
> p.s. I'm assuming there's no TCK for JSR-221.
P.S. I am pretty sure there is, but as I understand it, it just
validates the interfaces are there. It's part of the overall TCK for
Java SE 6, is my understanding. I am sure Lance will be happy to clarify.
>
> [1] http://www.jcp.org/aboutJava/communityprocess/JSPA2.pdf
> [2] http://jcp.org/aboutJava/communityprocess/announce/2004/JCP2.6.html
> [3]
> http://www.apache.org/foundation/records/minutes/2005/board_minutes_2005_12_21.txt
>
> (search for "SUN ISSUES")
Re: Proposal for 10.2 release schedule
Posted by Andrew McIntyre <mc...@gmail.com>.
On 6/22/06, Rick Hillegas <Ri...@sun.com> wrote:
> >> I think we want that database to play well with the approved
> >> release candidate which goes GA.
> >>
> >>
> >
> >The mid-Sep Derby release candidate will be marked alpha or beta (JCP
> >rules) so the databases won't upgrade anyway.
> >
> >
> I apologize for creating confusion here. We'd like Mustang to ship with
> a fully functional Derby, which creates upgradeable databases. So I'm
> assuming that we turn off the beta marker on the vetted candidate before
> handing the candidate to Mustang for QA bake-in.
A release candidate that the Derby community votes on would not be
marked alpha/beta by necessity. A vote on a release candidate is for
that set of bits to become the release. If the release candidate is
marked alpha/beta, and that's what people had voted on, and then the
RM rebuilds the distributions to change the version string and
publishes that, then the RM would be publishing something that the
community had not vetted. Not a good idea.
Elsewhere, Daniel John Debrunner wrote:
>
> Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA
> until Mustang ships. How can it be marked GA without violating the JCP
> requirements
Call in the lawyers:
>From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
has executed, being a JCP Member (they've even got quotes from Geir
prominently featured on their "about JCP 2.6 page" [2]):
5.B. License to Create Independent Implementations.
For any Specification produced under a new JSR, the Spec Lead for such
JSR shall offer to grant a perpetual, non-exclusive, worldwide, fully
paid-up, royalty free, irrevocable license under its licensable
copyrights in and patent claims covering the Specification (including
rights licensed to the Spec Lead pursuant to Section 4.A and 4.C) to
anyone who wishes to create and/or distribute an Independent
Implementation of the Spec. Such license will authorize the creation
and distribution of Independent Implementations provided such
Independent Implementations:
(a) fully implement the Spec(s) including all its required interfaces
and functionality;
(b) do not modify, subset, superset or otherwise extend the Licensor
Name Space, or
include any public or protected packages, classes, Java interfaces,
fields or methods within the Licensor Name Space other than those
required/authorized by the Spec or Specs being implemented; and
(c) pass the TCK for such Spec.
So, all we really need is for Lance, as Spec Lead, to indemnify the
ASF from any legal action regarding Derby's implementation of the JDBC
4 spec. Hey Lance, just send a note to the ASF Board that Sun's not
going to sue the ASF. Thanks! ;o)
Anyway, what's the trigger for breaching the contract here? If it's
'creation' alone, then rolling that release candidate surely qualifies
as as creation. If it's 'creation and distribution,' well, is posting
the release candidate in a public forum and on a public website (like
one would have to do to vote on it) considered distribution in this
case? I have no idea, because i'm not a lawyer.
Or maybe ask Geir, since he's VP of Java Community Process for the
Apache Software Foundation, since similar instances may have come up
fairly recently. [3]
andrew
p.s. I'm assuming there's no TCK for JSR-221.
[1] http://www.jcp.org/aboutJava/communityprocess/JSPA2.pdf
[2] http://jcp.org/aboutJava/communityprocess/announce/2004/JCP2.6.html
[3] http://www.apache.org/foundation/records/minutes/2005/board_minutes_2005_12_21.txt
(search for "SUN ISSUES")
Re: Proposal for 10.2 release schedule
Posted by Rick Hillegas <Ri...@Sun.COM>.
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>
>> Rick Hillegas wrote:
>>
>>
>>
>>> Hi Dan,
>>>
>>> Thanks for your comments. Some further remarks follow.
>>>
>>> Regards,
>>> -Rick
>>>
>>> Daniel John Debrunner wrote:
>>>
>>>
>>>
>>>> Rick Hillegas wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Kathey Marsden wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Rick Hillegas wrote:
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> What happens between September 15 and End of October on the 10.2
>>>>>> branch?
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> If we fix critical bugs during that time in the 10.2 branch can't
>>>>>> they
>>>>>> go into the release end of October?
>>>>>>
>>>>>
>>>> They should be able to. Since we won't have had a GA release (JCP
>>>> rules)
>>>> until Mustang ships, it seems any critical bug that we find and fix
>>>> between Sep 15th and Mustang shipping has the potential to require
>>>> a new
>>>> release candidate and new vote. Could even be a database format
>>>> change.
>>>>
>>>>
>>>>
>>>
>>> Let me work out the implications of this.
>>>
>>> o Mustang would ship with a release candidate which the community
>>> rejected.
>>> o The community would approve a later release candidate and promote it
>>> to GA status.
>>> o Bug reports would come in against both the rejected candidate bundled
>>> into Mustang and the approved candidate which was promoted to GA
>>> status.
>>>
>>> A couple issues come to mind:
>>>
>>> o In those bug reports, how would we disambiguate the release
>>> candidates? We could bump the last digit of the release identifier
>>> after
>>> producing the first candidate. Or we could rely on the full version id
>>> produced by sysinfo, which contains the subversion revision number.
>>>
>>
>>
>> I think we have bumped the fourth version ("point") digit after
>> producing a release candidate. That can be done pretty much at any time,
>> so no issues disambiguating release candidates.
>>
>>
>>
>>> o The database format change troubles me. What happens if someone
>>> creates a database with the rejected release candidate bundled with
>>> Mustang? I think we want that database to play well with the approved
>>> release candidate which goes GA.
>>>
>>
>>
>> The mid-Sep Derby release candidate will be marked alpha or beta (JCP
>> rules) so the databases won't upgrade anyway.
>>
>>
> I apologize for creating confusion here. We'd like Mustang to ship
> with a fully functional Derby, which creates upgradeable databases. So
> I'm assuming that we turn off the beta marker on the vetted candidate
> before handing the candidate to Mustang for QA bake-in.
>
Re-reading your comment, I see another issue which I need to clarify.
The release candidate is not a GA implementation under the JCP as I
understand this process. The candidate does not become GA until we post
it on the Apache mirrors and announce, via the Derby website, that it is
the latest Derby release.
Re: Proposal for 10.2 release schedule
Posted by Rob Stephens <Ro...@Sun.COM>.
that was MUCH clearer than what rick wrote.. thanks
David Van Couvering wrote:
> Ok, this is very tricky. First, I'd like to make sure we're on the
> same page here about Java DB going into the JDK. I think in general
> the community thinks it's a good thing for Derby for Java DB to be in
> the JDK. It gives us great exposure and distribution. I also think
> the community would probably like it if databases created by the
> version of Java DB to be upgradable to a subsequent release of Derby,
> so that users can get the latest and greatest functionality of Derby
> directly from the Apache web site, or even upgrade to a future release
> of Cloudscape if they decide to get support from IBM.
>
> In order for this to work, we need Java DB to be based on an official,
> "GA-ready" release of Derby to be what Sun redistributes in Mustang.
> Otherwise databases created in Mustang will be "locked in" to Java DB.
>
> The problem is that it can't *actually* be GA until after JCP approves
> JSR 221, JDBC 4.0, which will happen in tandem with the GA release of
> the JDK, around 5 weeks after the JDK team needs their final
> integration bits from all the pieces going into it.
>
> I think what Rick is asking for is a release that is voted as
> "GA-ready", has the GA-bit turned on, but because of JCP rules is not
> actually *made* generally available until JSR 220 becomes final.
> Since we all need to vet this release and approve it, it would be
> available to the Derby community, but not *generally* available by
> distributing it on all the Apache mirrors.
>
> I know this seems like a fine hair to split, but it's the only way we
> can be successful without Sun having to do a non-upgradable fork of
> Derby, which I don't think any of us want.
>
> I hope this helps to clear things up, even if it doesn't make things
> simpler :)
>
> David
>
> Daniel John Debrunner wrote:
>> Rick Hillegas wrote:
>>
>>> Daniel John Debrunner wrote:
>>
>>>> The mid-Sep Derby release candidate will be marked alpha or beta (JCP
>>>> rules) so the databases won't upgrade anyway.
>>>>
>>>>
>>> I apologize for creating confusion here. We'd like Mustang to ship with
>>> a fully functional Derby, which creates upgradeable databases. So I'm
>>> assuming that we turn off the beta marker on the vetted candidate
>>> before
>>> handing the candidate to Mustang for QA bake-in.
>>
>> Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA
>> until Mustang ships. How can it be marked GA without violating the JCP
>> requirements.
>>
>> Sorry if I'm being dense.
>> Dan.
>>
>>
--
<http://www.sun.com> * Rob Stephens *
Chief of Staff, Database Technology Group
OPG
*Sun Microsystems, Inc.*
Bay Area, California US
Phone 1-877-244-4740 or x51734
Mobile 1-510-928-2996
Fax 1-877-244-4740
Email Robert.Stephens@Sun.COM
<http://www.sun.com/solaris>
<http://www.sun.com>
Re: Proposal for 10.2 release schedule
Posted by David Van Couvering <Da...@Sun.COM>.
Jean and Dan, you raise good points
(a) what happens if someone downloads this "GA-ready but not GA" release
of Derby. If for some reason we have to do a respin of the release (see
(b)), how will they later know that it's not actually an official
release of Apache?
(b) is there a possibility, however, slight, that the JDBC spec could
change after we have marked a release "GA-ready"
I think these are great points for discussion.
I get the sense that we all want to make this work, but are not sure how
just yet.
I have a suggestion, and I'm sure I'm missing something, but here goes.
Is there a way we can vote on the release, and if it passes, Rick can
flip the GA bit, sign it and put it on the shelf, but not make it
available for download, even from the Derby site? This would allow us
to re-spin if necessary (although I don't think it's likely) due to a
last-minute change to JDBC, and would prevent a user from ending up with
a release that looks and smells like it's an official Apache release but
actually isn't.
David
Daniel John Debrunner wrote:
> Jean T. Anderson wrote:
>
>> David Van Couvering wrote:
>> ...
>>
>>> In order for this to work, we need Java DB to be based on an official,
>>> "GA-ready" release of Derby to be what Sun redistributes in Mustang.
>>> Otherwise databases created in Mustang will be "locked in" to Java DB.
>>>
>>> The problem is that it can't *actually* be GA until after JCP approves
>>> JSR 221, JDBC 4.0, which will happen in tandem with the GA release of
>>> the JDK, around 5 weeks after the JDK team needs their final integration
>>> bits from all the pieces going into it.
>>
>> in other words, we have a classic catch-22. :-)
>
> Are there any dates around JDBC 4.0/JSR221 that need to be factored in?
>
> I'm curious as to how we can vote on the release that's supporting JDBC
> 4.0 if the spec isn't final and/or generally available for people to
> read. Maybe we would be just voting on the current functionality of
> *Derby* and if it happens to match JDBC 4.0 that's a bonus.
>
> Dan.
>
>
Re: Proposal for 10.2 release schedule
Posted by Daniel John Debrunner <dj...@apache.org>.
Jean T. Anderson wrote:
> David Van Couvering wrote:
> ...
>
>>In order for this to work, we need Java DB to be based on an official,
>>"GA-ready" release of Derby to be what Sun redistributes in Mustang.
>>Otherwise databases created in Mustang will be "locked in" to Java DB.
>>
>>The problem is that it can't *actually* be GA until after JCP approves
>>JSR 221, JDBC 4.0, which will happen in tandem with the GA release of
>>the JDK, around 5 weeks after the JDK team needs their final integration
>>bits from all the pieces going into it.
>
>
> in other words, we have a classic catch-22. :-)
Are there any dates around JDBC 4.0/JSR221 that need to be factored in?
I'm curious as to how we can vote on the release that's supporting JDBC
4.0 if the spec isn't final and/or generally available for people to
read. Maybe we would be just voting on the current functionality of
*Derby* and if it happens to match JDBC 4.0 that's a bonus.
Dan.
Re: Proposal for 10.2 release schedule
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
David Van Couvering wrote:
...
> In order for this to work, we need Java DB to be based on an official,
> "GA-ready" release of Derby to be what Sun redistributes in Mustang.
> Otherwise databases created in Mustang will be "locked in" to Java DB.
>
> The problem is that it can't *actually* be GA until after JCP approves
> JSR 221, JDBC 4.0, which will happen in tandem with the GA release of
> the JDK, around 5 weeks after the JDK team needs their final integration
> bits from all the pieces going into it.
in other words, we have a classic catch-22. :-)
> I think what Rick is asking for is a release that is voted as
> "GA-ready", has the GA-bit turned on, but because of JCP rules is not
> actually *made* generally available until JSR 220 becomes final. Since
> we all need to vet this release and approve it, it would be available to
> the Derby community, but not *generally* available by distributing it on
> all the Apache mirrors.
It would still be easily available. And once downloaded, and probably
redistributed further, downstream users would have no idea that they
aren't working with an official Apache release.
What is the specific legal verbiage we're working with here?
-jean
> I know this seems like a fine hair to split, but it's the only way we
> can be successful without Sun having to do a non-upgradable fork of
> Derby, which I don't think any of us want.
>
> I hope this helps to clear things up, even if it doesn't make things
> simpler :)
>
> David
Re: Proposal for 10.2 release schedule
Posted by David Van Couvering <Da...@Sun.COM>.
Ok, this is very tricky. First, I'd like to make sure we're on the same
page here about Java DB going into the JDK. I think in general the
community thinks it's a good thing for Derby for Java DB to be in the
JDK. It gives us great exposure and distribution. I also think the
community would probably like it if databases created by the version of
Java DB to be upgradable to a subsequent release of Derby, so that users
can get the latest and greatest functionality of Derby directly from the
Apache web site, or even upgrade to a future release of Cloudscape if
they decide to get support from IBM.
In order for this to work, we need Java DB to be based on an official,
"GA-ready" release of Derby to be what Sun redistributes in Mustang.
Otherwise databases created in Mustang will be "locked in" to Java DB.
The problem is that it can't *actually* be GA until after JCP approves
JSR 221, JDBC 4.0, which will happen in tandem with the GA release of
the JDK, around 5 weeks after the JDK team needs their final integration
bits from all the pieces going into it.
I think what Rick is asking for is a release that is voted as
"GA-ready", has the GA-bit turned on, but because of JCP rules is not
actually *made* generally available until JSR 220 becomes final. Since
we all need to vet this release and approve it, it would be available to
the Derby community, but not *generally* available by distributing it on
all the Apache mirrors.
I know this seems like a fine hair to split, but it's the only way we
can be successful without Sun having to do a non-upgradable fork of
Derby, which I don't think any of us want.
I hope this helps to clear things up, even if it doesn't make things
simpler :)
David
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>
>> Daniel John Debrunner wrote:
>
>>> The mid-Sep Derby release candidate will be marked alpha or beta (JCP
>>> rules) so the databases won't upgrade anyway.
>>>
>>>
>> I apologize for creating confusion here. We'd like Mustang to ship with
>> a fully functional Derby, which creates upgradeable databases. So I'm
>> assuming that we turn off the beta marker on the vetted candidate before
>> handing the candidate to Mustang for QA bake-in.
>
> Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA
> until Mustang ships. How can it be marked GA without violating the JCP
> requirements.
>
> Sorry if I'm being dense.
> Dan.
>
>
Re: Proposal for 10.2 release schedule
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> The mid-Sep Derby release candidate will be marked alpha or beta (JCP
>> rules) so the databases won't upgrade anyway.
>>
>>
> I apologize for creating confusion here. We'd like Mustang to ship with
> a fully functional Derby, which creates upgradeable databases. So I'm
> assuming that we turn off the beta marker on the vetted candidate before
> handing the candidate to Mustang for QA bake-in.
Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA
until Mustang ships. How can it be marked GA without violating the JCP
requirements.
Sorry if I'm being dense.
Dan.
Re: Proposal for 10.2 release schedule
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
>Rick Hillegas wrote:
>
>
>
>>Hi Dan,
>>
>>Thanks for your comments. Some further remarks follow.
>>
>>Regards,
>>-Rick
>>
>>Daniel John Debrunner wrote:
>>
>>
>>
>>>Rick Hillegas wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Kathey Marsden wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Rick Hillegas wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>>>What happens between September 15 and End of October on the 10.2
>>>>>branch?
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>>>If we fix critical bugs during that time in the 10.2 branch can't they
>>>>>go into the release end of October?
>>>>>
>>>>>
>>>>>
>>>They should be able to. Since we won't have had a GA release (JCP rules)
>>>until Mustang ships, it seems any critical bug that we find and fix
>>>between Sep 15th and Mustang shipping has the potential to require a new
>>>release candidate and new vote. Could even be a database format change.
>>>
>>>
>>>
>>>
>>Let me work out the implications of this.
>>
>>o Mustang would ship with a release candidate which the community rejected.
>>o The community would approve a later release candidate and promote it
>>to GA status.
>>o Bug reports would come in against both the rejected candidate bundled
>>into Mustang and the approved candidate which was promoted to GA status.
>>
>>A couple issues come to mind:
>>
>>o In those bug reports, how would we disambiguate the release
>>candidates? We could bump the last digit of the release identifier after
>>producing the first candidate. Or we could rely on the full version id
>>produced by sysinfo, which contains the subversion revision number.
>>
>>
>
>I think we have bumped the fourth version ("point") digit after
>producing a release candidate. That can be done pretty much at any time,
>so no issues disambiguating release candidates.
>
>
>
>>o The database format change troubles me. What happens if someone
>>creates a database with the rejected release candidate bundled with
>>Mustang? I think we want that database to play well with the approved
>>release candidate which goes GA.
>>
>>
>
>The mid-Sep Derby release candidate will be marked alpha or beta (JCP
>rules) so the databases won't upgrade anyway.
>
>
I apologize for creating confusion here. We'd like Mustang to ship with
a fully functional Derby, which creates upgradeable databases. So I'm
assuming that we turn off the beta marker on the vetted candidate before
handing the candidate to Mustang for QA bake-in.
>Dan.
>
>
>
>
Re: Proposal for 10.2 release schedule
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Hi Dan,
>
> Thanks for your comments. Some further remarks follow.
>
> Regards,
> -Rick
>
> Daniel John Debrunner wrote:
>
>> Rick Hillegas wrote:
>>
>>
>>
>>
>>> Kathey Marsden wrote:
>>>
>>>
>>>
>>>> Rick Hillegas wrote:
>>>>
>>>>
>>
>>
>>
>>
>>>> What happens between September 15 and End of October on the 10.2
>>>> branch?
>>>>
>>
>>
>>
>>
>>>> If we fix critical bugs during that time in the 10.2 branch can't they
>>>> go into the release end of October?
>>>>
>>
>>
>> They should be able to. Since we won't have had a GA release (JCP rules)
>> until Mustang ships, it seems any critical bug that we find and fix
>> between Sep 15th and Mustang shipping has the potential to require a new
>> release candidate and new vote. Could even be a database format change.
>>
>>
> Let me work out the implications of this.
>
> o Mustang would ship with a release candidate which the community rejected.
> o The community would approve a later release candidate and promote it
> to GA status.
> o Bug reports would come in against both the rejected candidate bundled
> into Mustang and the approved candidate which was promoted to GA status.
>
> A couple issues come to mind:
>
> o In those bug reports, how would we disambiguate the release
> candidates? We could bump the last digit of the release identifier after
> producing the first candidate. Or we could rely on the full version id
> produced by sysinfo, which contains the subversion revision number.
I think we have bumped the fourth version ("point") digit after
producing a release candidate. That can be done pretty much at any time,
so no issues disambiguating release candidates.
> o The database format change troubles me. What happens if someone
> creates a database with the rejected release candidate bundled with
> Mustang? I think we want that database to play well with the approved
> release candidate which goes GA.
The mid-Sep Derby release candidate will be marked alpha or beta (JCP
rules) so the databases won't upgrade anyway.
Dan.
Re: Proposal for 10.2 release schedule
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
>Rick Hillegas wrote:
>
>
>
>
>>Kathey Marsden wrote:
>>
>>
>>
>>>Rick Hillegas wrote:
>>>
>>>
>>>
>
>
>
>>>What happens between September 15 and End of October on the 10.2 branch?
>>>
>>>
>
>
>
>>>If we fix critical bugs during that time in the 10.2 branch can't they
>>>go into the release end of October?
>>>
>>>
>
>They should be able to. Since we won't have had a GA release (JCP rules)
>until Mustang ships, it seems any critical bug that we find and fix
>between Sep 15th and Mustang shipping has the potential to require a new
>release candidate and new vote. Could even be a database format change.
>
>
Let me work out the implications of this.
o Mustang would ship with a release candidate which the community rejected.
o The community would approve a later release candidate and promote it
to GA status.
o Bug reports would come in against both the rejected candidate bundled
into Mustang and the approved candidate which was promoted to GA status.
A couple issues come to mind:
o In those bug reports, how would we disambiguate the release
candidates? We could bump the last digit of the release identifier after
producing the first candidate. Or we could rely on the full version id
produced by sysinfo, which contains the subversion revision number.
o The database format change troubles me. What happens if someone
creates a database with the rejected release candidate bundled with
Mustang? I think we want that database to play well with the approved
release candidate which goes GA.
>>Suppose we were able to publish the 10.2 release candidate (make it GA)
>>right after we vetted it in mid-September. When would you want to
>>produce the follow-on bug fix release? At the end of October? A couple
>>months later? We could do either. The community may want to defer the
>>follow-on bug fix release for a couple months. That would give us time
>>to collect more feedback from users of the published, GA release.
>>However, we could "release early, release often" and produce another
>>release from the 10.2 branch at the end of October.
>>
>>
>
>Not sure I understand the point of this paragraph. I thought the JCP
>rules mean we can't make 10.2 GA in mid-Sep, thus it seems to be a
>hypothetical impossible situation.
>
>Dan.
>
>
>
That's right. This is an impossible, hypothetical situation. I was
trying to compare Kathey's scenario to a scenario which could arise if
we didn't have the JCP restrictions: Suppose we produce a GA feature
release and a week later we discover that the release has a horrendous,
data-corrupting bug. We might produce a bug fix release a couple weeks
after the bad release.
Re: Proposal for 10.2 release schedule
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Kathey Marsden wrote:
>
>> Rick Hillegas wrote:
>>
>> What happens between September 15 and End of October on the 10.2 branch?
>
>> If we fix critical bugs during that time in the 10.2 branch can't they
>> go into the release end of October?
They should be able to. Since we won't have had a GA release (JCP rules)
until Mustang ships, it seems any critical bug that we find and fix
between Sep 15th and Mustang shipping has the potential to require a new
release candidate and new vote. Could even be a database format change.
> Suppose we were able to publish the 10.2 release candidate (make it GA)
> right after we vetted it in mid-September. When would you want to
> produce the follow-on bug fix release? At the end of October? A couple
> months later? We could do either. The community may want to defer the
> follow-on bug fix release for a couple months. That would give us time
> to collect more feedback from users of the published, GA release.
> However, we could "release early, release often" and produce another
> release from the 10.2 branch at the end of October.
Not sure I understand the point of this paragraph. I thought the JCP
rules mean we can't make 10.2 GA in mid-Sep, thus it seems to be a
hypothetical impossible situation.
Dan.
Re: Proposal for 10.2 release schedule
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Kathey,
Thanks for raising these issues. Here are some clarifications.
Regards,
-Rick
Kathey Marsden wrote:
> Rick Hillegas wrote:
>
>> The JCP requires that our JDBC4-exposing release can not be generally
>> available until the JDBC4 specification is finalized.
>
>
> Is this something that the Derby community is bound to?
The JCP rules are the license you accept when you publish a GA
implementation of a JSR. In our case this is JSR 221, which governs
JDBC4. The Derby community accepts this license by exposing a GA
implementation of JDBC4 in release 10.2.
>
>>
>> Here are proposed dates for 10.2 milestones:
>>
>> August 10 - Feature work committed. 10.2 branch created.
>> August 24 - Last day to commit changes for 10.2
>> August 25 - Begin vetting 10.2 release candidate
>> September 15 - Target date for finishing the voting on Derby 10.2
>
>
> What happens between September 15 and End of October on the 10.2 branch?
Between September 15 and the end of October, the vetted 10.2 release
candidate is still available to anyone who needs it, just as the 10.1.3
release candidate is available right now.
> Does bug fixing and work on 10.2.1 begin?
Forgive me for being pedantic about release numbers. I think that the
first release cut off the 10.2 branch will be called 10.2.1.0. I think
that you are asking about bug fixing for the second release cut off the
10.2 branch, which would be 10.2.2.0.
I think that we can begin putting more bug fixes into the 10.2 branch as
soon as we produce the first 10.2 release candidate. So that would be
mid-September.
> If we fix critical bugs during that time in the 10.2 branch can't they
> go into the release end of October?
Suppose we were able to publish the 10.2 release candidate (make it GA)
right after we vetted it in mid-September. When would you want to
produce the follow-on bug fix release? At the end of October? A couple
months later? We could do either. The community may want to defer the
follow-on bug fix release for a couple months. That would give us time
to collect more feedback from users of the published, GA release.
However, we could "release early, release often" and produce another
release from the 10.2 branch at the end of October.
>
>> End of October - Expected GA of JDBC4 with Mustang
>> End of October - GA of Derby 10.2. Release promoted to Apache mirrors.
>>
>>
>
>
>
Re: Proposal for 10.2 release schedule
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
> The JCP requires that our JDBC4-exposing release can not be generally
> available until the JDBC4 specification is finalized.
Is this something that the Derby community is bound to?
>
> Here are proposed dates for 10.2 milestones:
>
> August 10 - Feature work committed. 10.2 branch created.
> August 24 - Last day to commit changes for 10.2
> August 25 - Begin vetting 10.2 release candidate
> September 15 - Target date for finishing the voting on Derby 10.2
What happens between September 15 and End of October on the 10.2 branch?
Does bug fixing and work on 10.2.1 begin?
If we fix critical bugs during that time in the 10.2 branch can't they
go into the release end of October?
> End of October - Expected GA of JDBC4 with Mustang
> End of October - GA of Derby 10.2. Release promoted to Apache mirrors.
>
>