You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Andrew McIntyre <mc...@gmail.com> on 2006/09/12 03:02:54 UTC
10.2 plans (was Re: 10.2 licensing issue)
Taking this over to derby-dev...
On 9/11/06, Kathey Marsden <km...@sbcglobal.net> wrote:
>
> Many of these regressions sadly have already made their way into 10.1.3
> and therefore are being picked up by users for production. I
> think we need to notify the user community of the situation, try to get
> more user input on 10.2 and flush out more regressions. We port fixes
> to 10.1 to try to get it to a stable state and then release 10.2. Also
> any ideas anyone has for new optimizer tests would be good and folks
> could write those.
>
> Those are all my ideas for now. It could be that lots of users have
> tried 10.2 without problems but haven't reported in and then it is just
> a matter of getting them to speak up.
I don't think we should hold up the 10.2 release except for known
regressions. I think it's a chicken-and-egg problem. Users aren't
motivated to try out the beta, because it's extra time and effort on
their part, so you aren't actually informed about regressions until
the regression is in a release that people actually try to use. Better
to release early so new code gets into actual user's hands so
regressions can be flushed out sooner. Regressions happen, and no
release is ever go to be perfect (although that would be nice,
wouldn't it?).
Better to release often so code where regressions have been identified
and fixed get into user's hands sooner.
I think releasing early and often is an area we as a community, and
individually through the tasks we take on for any particular release,
could improve.
andrew
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Laura Stewart wrote:
> On 9/12/06, Daniel John Debrunner <dj...@apache.org> wrote:
>
>> In both cases the current state of the 10.2 branch is left unchanged wrt
>> JDBC 4.0, ie. no removal of JDBC 4.0 from code or documentation.
>
> If either of these approaches are used, the doc issue needs to be
> handled carefully. The JDBC 4.0 information will be in the
> documentation. Even if a statement is put into the Release Notes
> about this, it is very likely that a user (or 2) will miss the
> statement about JDBC 4.0 in the Release Notes and run into some
> problems.
So let's nail down the doc problem.
I think https://issues.apache.org/jira/browse/DERBY-1271 summarizes the
changes. Scroll down past the description to the comments section. You
should see a tab marked "Subversion Commits". Click on that and you'll
see all the files that were changed for JDBC 4.
It looks like 6 files were added to the Reference Guide specifically for
the new JDBC 4.0 features:
rrefjdbc4_0connection.dita
rrefjdbc4_0sqlexception.dita
rrefjdbc4_0databaseMetaData.dita
rrefjdbc4_0statement.dita
rrefjdbc4_0dataSource.dita
rrefjdbc4_0summary.dita
What if we were to add a short notice to each file along the lines of
(the specific wording would need to get nailed down): "This is new jdbc
4 functionality that is only available to developers who build Derby
with jdk16".
Are there any other key files that would also need a notice?
--I'm willing to help put these notices in (and pull them back out when
they are no longer needed).
> Something should also be posted on the Web Pages for Derby as well.
>
> I am not entirely comfortable with leaving a feature in the
> documentation that is not being delivered.
But the source will be there, so the documentation would be useful for
anyone who wants to build Derby with jdk16.
> If the docs are left as is, then I would prefer a feature release 10.3
> when we formally support JDBC 4.0.
I disagree because developers will already have that functionality if
they choose to build Derby themselves. The 10.2 maintenance release
would just need to be recompiled with jdk16 to enable that jdbc 4
functionality for users.
I do agree that we need to do what we can to avoid confusion.
-jean
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Laura Stewart <sc...@gmail.com>.
On 9/12/06, Daniel John Debrunner <dj...@apache.org> wrote:
>
> In both cases the current state of the 10.2 branch is left unchanged wrt
> JDBC 4.0, ie. no removal of JDBC 4.0 from code or documentation.
>
> Dan.
>
>
If either of these approaches are used, the doc issue needs to be
handled carefully. The JDBC 4.0 information will be in the
documentation. Even if a statement is put into the Release Notes
about this, it is very likely that a user (or 2) will miss the
statement about JDBC 4.0 in the Release Notes and run into some
problems.
Something should also be posted on the Web Pages for Derby as well.
I am not entirely comfortable with leaving a feature in the
documentation that is not being delivered.
If the docs are left as is, then I would prefer a feature release 10.3
when we formally support JDBC 4.0.
--
Laura Stewart
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
Bernt M. Johnsen wrote:
> Daniel John Debrunner wrote:
>
>>Since this is an open-*source* project, we do have other options that
>>seem to have no legal issues to me (IANAL).
>>
>>Option A - Source only release with JDBC 4.0 based on proposed final draft
>> Derby 10.2 release is source only, no pre-compiled jars, removes the
>>dependency on the Mustang download.
>>
>>Option B - Release pre-compiled jars without JDBC 4.0 optional build
>> Option A plus pre-compiled jars without JDBC 4.0, already supported by
>>just compiling without a Java SE 6/Mustang JDK.
>>
>>In both cases the current state of the 10.2 branch is left unchanged wrt
>>JDBC 4.0, ie. no removal of JDBC 4.0 from code or documentation.
>
>
> I think this is brilliant. Just leave the source code as it is but
> release binaries without JDBC4 (read: don't compile them with JDK 6).
> Anyone that want to "experiment" with JDBC4 may of course get the Derby
> 10.2 source and JDK 6 beta-build x and do whatever seems fit for the
> experiments.....
BTW: IANAL too.....
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
Daniel John Debrunner wrote:
> Since this is an open-*source* project, we do have other options that
> seem to have no legal issues to me (IANAL).
>
> Option A - Source only release with JDBC 4.0 based on proposed final draft
> Derby 10.2 release is source only, no pre-compiled jars, removes the
> dependency on the Mustang download.
>
> Option B - Release pre-compiled jars without JDBC 4.0 optional build
> Option A plus pre-compiled jars without JDBC 4.0, already supported by
> just compiling without a Java SE 6/Mustang JDK.
>
> In both cases the current state of the 10.2 branch is left unchanged wrt
> JDBC 4.0, ie. no removal of JDBC 4.0 from code or documentation.
I think this is brilliant. Just leave the source code as it is but
release binaries without JDBC4 (read: don't compile them with JDK 6).
Anyone that want to "experiment" with JDBC4 may of course get the Derby
10.2 source and JDK 6 beta-build x and do whatever seems fit for the
experiments.....
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Andrew McIntyre wrote:
> On 9/12/06, Rick Hillegas <Ri...@sun.com> wrote:
>> Daniel John Debrunner wrote:
...
>> > Option B - Release pre-compiled jars without JDBC 4.0 optional build
>> > Option A plus pre-compiled jars without JDBC 4.0, already supported by
>> > just compiling without a Java SE 6/Mustang JDK.
>>
>> I'm afraid I don't understand option (B). How does this differ from
>> option (1)?
>
> With this option the binaries that are shipped do not contain the
> optional JDBC 4 compiled in, and thus are not compiled against the JDK
> 1.6 runtime classes or use the JDK 1.6 compiler and are thus
> unencumbered. i.e. just take the 'jdk16' property out of your
> ant.properties when you're building the release. The source
> distribution, because it isn't compiled, is not encumbered by either
> of these restraints either.
>
>> I would certainly welcome a solution which doesn't involve yanking out
>> the JDBC4 documentation!
>
> If we go with option B (which I think is a great idea, btw) then maybe
> just add a note for 10.2 about the need to compiling from the source
> to use the feature and a note about the legal/technical ramifications
> of using the JDBC 4 features.
We might be able to avoid most end user confusion ("hey! how come this
doesn't work with jdbc 4?") by adding a short warning to the half dozen
doc pages that reference 4.0 functionality. I think these are mostly:
/db/derby/docs/trunk/src/ref/rrefjdbc4_0*.dita
Some confusion is inevitable and we'd just deal with it on the user list.
> Once the JDK has shipped, I personally would be ok with doing a 10.2.2
> that includes JDBC 4.0 without moving immediately to 10.3. Although,
> by the time the JDK has shipped, there may be bunch of new features
> that we may want to release, so maybe 10.3 will be the right thing to
> do at that point.
I'd also have no problem enabling jdbc 4 in a 10.2.2 release.
-jean
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Rick Hillegas <Ri...@Sun.COM>.
Andrew McIntyre wrote:
> On 9/12/06, Rick Hillegas <Ri...@sun.com> wrote:
>
>> Hi Dan,
>>
>> Daniel John Debrunner wrote:
>>
>> >Since this is an open-*source* project, we do have other options that
>> >seem to have no legal issues to me (IANAL).
>> >
>> >Option A - Source only release with JDBC 4.0 based on proposed final
>> draft
>> > Derby 10.2 release is source only, no pre-compiled jars, removes the
>> >dependency on the Mustang download.
>>
>> This would seem to require that users become developers, at least to the
>> point of creating a development environment.
>
>
> I'm not in favor of this option, but not because I think setting up a
> build is difficult. I think a lot of users would simply pass on the
> release if there were not precompiled binaries because they won't go
> to the trouble if it's not a completely out-of-the-box procedure. Too
> easy to just go get some other embedded database that's has binaries
> available.
>
>> > Option B - Release pre-compiled jars without JDBC 4.0 optional build
>> > Option A plus pre-compiled jars without JDBC 4.0, already supported by
>> > just compiling without a Java SE 6/Mustang JDK.
>>
>> I'm afraid I don't understand option (B). How does this differ from
>> option (1)?
>
>
> With this option the binaries that are shipped do not contain the
> optional JDBC 4 compiled in, and thus are not compiled against the JDK
> 1.6 runtime classes or use the JDK 1.6 compiler and are thus
> unencumbered. i.e. just take the 'jdk16' property out of your
> ant.properties when you're building the release. The source
> distribution, because it isn't compiled, is not encumbered by either
> of these restraints either.
>
>> I would certainly welcome a solution which doesn't involve yanking out
>> the JDBC4 documentation!
>
>
> If we go with option B (which I think is a great idea, btw) then maybe
> just add a note for 10.2 about the need to compiling from the source
> to use the feature and a note about the legal/technical ramifications
> of using the JDBC 4 features.
Thanks, Andrew. I think I now understand that option (B) is option (1)
with these changes:
i) No need to yank out the JDBC4 documentation
ii) Simply add a paragraph to the Release Notes explaining how to
compile the JDBC4 bits. Also add a note explaining the legal and
compatibility issues.
I think we would nevertheless also need the following:
iii) Various changes to the documentation to explain that, by default,
you will get the JDBC3 implementation if you run your application on JDK
6 but that, by compiling in the JDBC4 bits you can get an encumbered
early access JDBC4 implementation. These changes would only have to go
into the 10.2 branch and could be removed when we release a
JDBC4-enabled version of Derby.
I am happy with this solution.
>
> Once the JDK has shipped, I personally would be ok with doing a 10.2.2
> that includes JDBC 4.0 without moving immediately to 10.3. Although,
> by the time the JDK has shipped, there may be bunch of new features
> that we may want to release, so maybe 10.3 will be the right thing to
> do at that point.
I agree that we can probably defer the discussion about release
numbering and branch management.
Regards,
-Rick
>
> andrew
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Andrew McIntyre <mc...@gmail.com>.
On 9/12/06, Rick Hillegas <Ri...@sun.com> wrote:
> Hi Dan,
>
> Daniel John Debrunner wrote:
>
> >Since this is an open-*source* project, we do have other options that
> >seem to have no legal issues to me (IANAL).
> >
> >Option A - Source only release with JDBC 4.0 based on proposed final draft
> > Derby 10.2 release is source only, no pre-compiled jars, removes the
> >dependency on the Mustang download.
>
> This would seem to require that users become developers, at least to the
> point of creating a development environment.
I'm not in favor of this option, but not because I think setting up a
build is difficult. I think a lot of users would simply pass on the
release if there were not precompiled binaries because they won't go
to the trouble if it's not a completely out-of-the-box procedure. Too
easy to just go get some other embedded database that's has binaries
available.
> > Option B - Release pre-compiled jars without JDBC 4.0 optional build
> > Option A plus pre-compiled jars without JDBC 4.0, already supported by
> > just compiling without a Java SE 6/Mustang JDK.
>
> I'm afraid I don't understand option (B). How does this differ from
> option (1)?
With this option the binaries that are shipped do not contain the
optional JDBC 4 compiled in, and thus are not compiled against the JDK
1.6 runtime classes or use the JDK 1.6 compiler and are thus
unencumbered. i.e. just take the 'jdk16' property out of your
ant.properties when you're building the release. The source
distribution, because it isn't compiled, is not encumbered by either
of these restraints either.
> I would certainly welcome a solution which doesn't involve yanking out
> the JDBC4 documentation!
If we go with option B (which I think is a great idea, btw) then maybe
just add a note for 10.2 about the need to compiling from the source
to use the feature and a note about the legal/technical ramifications
of using the JDBC 4 features.
Once the JDK has shipped, I personally would be ok with doing a 10.2.2
that includes JDBC 4.0 without moving immediately to 10.3. Although,
by the time the JDK has shipped, there may be bunch of new features
that we may want to release, so maybe 10.3 will be the right thing to
do at that point.
andrew
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
David Van Couvering wrote:
> A quick chime in. I am not comfortable with a source-only release of
> 10.2. I think a binary release without JDBC4, plus the source for the
> JDBC4 functionality for those who want it and are prepared to do a build
> (e.g. option 2) seems quite reasonable to me.
Neither am I. I was thinking combined. 10.2 w/o JDBC4 compiled with JDK
1.5, 10.2 source compilable with JDK 6 for this interested in JDBC4.
>
> David
>
> Bernt M. Johnsen wrote:
>
>> Rick Hillegas wrote:
>>
>>> Hi Dan,
>>>
>>> Daniel John Debrunner wrote:
>>>
>>>> Since this is an open-*source* project, we do have other options that
>>>> seem to have no legal issues to me (IANAL).
>>>>
>>>> Option A - Source only release with JDBC 4.0 based on proposed final
>>>> draft
>>>> Derby 10.2 release is source only, no pre-compiled jars, removes the
>>>> dependency on the Mustang download.
>>>>
>>>>
>>> This would seem to require that users become developers, at least to the
>>> point of creating a development environment.
>>
>>
>> Well. Derby is *not* an end-user product, so the Derby users are
>> themselves developers.
>>
>>> I had an unhappy initial
>>> experience as a Derby developer a year ago. Perhaps the situation has
>>> gotten better. I recall that setting up a development environment
>>> involved a lot of steps and moving parts--fetching various pieces of
>>> software from various locations, editting ant configuration files, etc..
>>> I think that may discourage many users. That in turn will limit the
>>> commodity testing and feedback which we hope to get from users of the
>>> official release.
>>
>>
>> I see your concerns. But I have done this maneouver several times in my
>> career with various open source products (the list is very long, but I
>> started with some platform problems with emacs on Sun386i in the late
>> 80s), and the build process wasn't always smooth (I even once had to
>> edit a files in SunOS /usr/include to make gcc compile). Don't
>> underestimate the Derby users.
>>
>>> In addition, an uncontrolled build process would very likely complicate
>>> bug reporting. For these reasons, I would recommend against this option.
>>
>>
>> The option will always be there for the most eager users, since JDBC4 is
>> always in the trunk, and even if we remove JDBC4, we can't rollback svn
>> and undo what we've done.
>>
>>
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by David Van Couvering <Da...@Sun.COM>.
A quick chime in. I am not comfortable with a source-only release of
10.2. I think a binary release without JDBC4, plus the source for the
JDBC4 functionality for those who want it and are prepared to do a build
(e.g. option 2) seems quite reasonable to me.
David
Bernt M. Johnsen wrote:
> Rick Hillegas wrote:
>> Hi Dan,
>>
>> Daniel John Debrunner wrote:
>>
>>> Since this is an open-*source* project, we do have other options that
>>> seem to have no legal issues to me (IANAL).
>>>
>>> Option A - Source only release with JDBC 4.0 based on proposed final
>>> draft
>>> Derby 10.2 release is source only, no pre-compiled jars, removes the
>>> dependency on the Mustang download.
>>>
>>>
>> This would seem to require that users become developers, at least to the
>> point of creating a development environment.
>
> Well. Derby is *not* an end-user product, so the Derby users are
> themselves developers.
>
>> I had an unhappy initial
>> experience as a Derby developer a year ago. Perhaps the situation has
>> gotten better. I recall that setting up a development environment
>> involved a lot of steps and moving parts--fetching various pieces of
>> software from various locations, editting ant configuration files, etc..
>> I think that may discourage many users. That in turn will limit the
>> commodity testing and feedback which we hope to get from users of the
>> official release.
>
> I see your concerns. But I have done this maneouver several times in my
> career with various open source products (the list is very long, but I
> started with some platform problems with emacs on Sun386i in the late
> 80s), and the build process wasn't always smooth (I even once had to
> edit a files in SunOS /usr/include to make gcc compile). Don't
> underestimate the Derby users.
>
>> In addition, an uncontrolled build process would very likely complicate
>> bug reporting. For these reasons, I would recommend against this option.
>
> The option will always be there for the most eager users, since JDBC4 is
> always in the trunk, and even if we remove JDBC4, we can't rollback svn
> and undo what we've done.
>
>
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
Rick Hillegas wrote:
> Hi Dan,
>
> Daniel John Debrunner wrote:
>
>> Since this is an open-*source* project, we do have other options that
>> seem to have no legal issues to me (IANAL).
>>
>> Option A - Source only release with JDBC 4.0 based on proposed final
>> draft
>> Derby 10.2 release is source only, no pre-compiled jars, removes the
>> dependency on the Mustang download.
>>
>>
> This would seem to require that users become developers, at least to the
> point of creating a development environment.
Well. Derby is *not* an end-user product, so the Derby users are
themselves developers.
> I had an unhappy initial
> experience as a Derby developer a year ago. Perhaps the situation has
> gotten better. I recall that setting up a development environment
> involved a lot of steps and moving parts--fetching various pieces of
> software from various locations, editting ant configuration files, etc..
> I think that may discourage many users. That in turn will limit the
> commodity testing and feedback which we hope to get from users of the
> official release.
I see your concerns. But I have done this maneouver several times in my
career with various open source products (the list is very long, but I
started with some platform problems with emacs on Sun386i in the late
80s), and the build process wasn't always smooth (I even once had to
edit a files in SunOS /usr/include to make gcc compile). Don't
underestimate the Derby users.
>
> In addition, an uncontrolled build process would very likely complicate
> bug reporting. For these reasons, I would recommend against this option.
The option will always be there for the most eager users, since JDBC4 is
always in the trunk, and even if we remove JDBC4, we can't rollback svn
and undo what we've done.
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Dan,
Daniel John Debrunner wrote:
>Since this is an open-*source* project, we do have other options that
>seem to have no legal issues to me (IANAL).
>
>Option A - Source only release with JDBC 4.0 based on proposed final draft
> Derby 10.2 release is source only, no pre-compiled jars, removes the
>dependency on the Mustang download.
>
>
This would seem to require that users become developers, at least to the
point of creating a development environment. I had an unhappy initial
experience as a Derby developer a year ago. Perhaps the situation has
gotten better. I recall that setting up a development environment
involved a lot of steps and moving parts--fetching various pieces of
software from various locations, editting ant configuration files, etc..
I think that may discourage many users. That in turn will limit the
commodity testing and feedback which we hope to get from users of the
official release.
In addition, an uncontrolled build process would very likely complicate
bug reporting. For these reasons, I would recommend against this option.
>Option B - Release pre-compiled jars without JDBC 4.0 optional build
> Option A plus pre-compiled jars without JDBC 4.0, already supported by
>just compiling without a Java SE 6/Mustang JDK.
>
>
I'm afraid I don't understand option (B). How does this differ from
option (1)? Are you recommending that we add some top-level build
targets so that developers can build jars which contain just the JDBC4
bits for layering on top of official 10.2 jars?
>In both cases the current state of the 10.2 branch is left unchanged wrt
>JDBC 4.0, ie. no removal of JDBC 4.0 from code or documentation.
>
>Dan.
>
>
I would certainly welcome a solution which doesn't involve yanking out
the JDBC4 documentation!
Regards,
-Rick
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Daniel John Debrunner <dj...@apache.org>.
Since this is an open-*source* project, we do have other options that
seem to have no legal issues to me (IANAL).
Option A - Source only release with JDBC 4.0 based on proposed final draft
Derby 10.2 release is source only, no pre-compiled jars, removes the
dependency on the Mustang download.
Option B - Release pre-compiled jars without JDBC 4.0 optional build
Option A plus pre-compiled jars without JDBC 4.0, already supported by
just compiling without a Java SE 6/Mustang JDK.
In both cases the current state of the 10.2 branch is left unchanged wrt
JDBC 4.0, ie. no removal of JDBC 4.0 from code or documentation.
Dan.
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Rick Hillegas <Ri...@Sun.COM>.
Rajesh Kartha wrote:
...
lots of good discussion
...
>
> Now another point for discussion is, after 10.2, when Mustang gets
> released what should be the version for DERBY
> with the JDBC4 support be called - 10.3 ?
>
> -Rajesh
>
>
Hi Rajesh,
There seem to be at least two issues here:
1) Release numbering. What should we call the JDBC4-exposing release:
10.2.x or 10.3? Since JDBC4 is a big feature, would it be deceptive to
expose it in bug-fix release?
2) Branch management. Suppose we decided to call this JDBC4-exposing
release 10.3.. Would it be confusing or would something break if we made
the following changes in the 10.2 branch three months hence:
a) changed the release identifier from 10.2.x to 10.3
b) made appropriate changes to the documentation
Regards,
-Rick
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Rajesh Kartha <ka...@gmail.com>.
Kathy Saunders wrote:
> Myrna van Lunteren wrote:
>
>> For what it's worth, my position is somewhere in the middle. I think
>> there are some worrying aspects to some of those optimizer-related
>> regressions. Also, I feel we're still scrambling on 10.2.; still
>> documentation changes are being worked on...Now that in a way some of
>> the pressure to release is off, we need to take another look at
>> changes slated for 10.2.2 and see if there are any that really should
>> go in to make the first release of 10.2 but we've dropped because of
>> lack of time.
>>
>> If we release now, we should focus activities for 10.2.2 with the goal
>> of making it more robust as well as having the jdbc40 support in.
>>
>> Myrna
>>
> Hi,
>
> To clarify my opinions, here's what I'm concerned about:
>
> 1 - If there are quality issues that anyone thinks we should fix,
> then what are those specific issues? Advocate to get them on Rick's
> list to fix before a release should happen. General concerns about
> quality at this point are a problem for me as I don't understand what
> we are to do before we can have a release. I do believe there are
> regressions out there. I do believe there are regressions in the
> optimizer specifically because that's difficult code and from other
> products I've worked on when you make significant changes to the
> optimizer, you almost always have other issues pop up, and it's not
> necessarily easy to get them to surface. But, if you continue to hold
> up a release because of regression concerns, you'll never have one.
> In my opinion, it's generally time to get this release done, once we
> have the known significant issues resolved. If we really believe we
> need more testing, then what is that testing and who is going to do
> it? Discussion on quality is healthy, but at this point in the
> release process I believe we need to be specific about what actions or
> outcome we need to complete the release.
> 2 - Regarding the Mustang and JDBC 4 issue, my general opinion is that
> if Mustang is still coming out in October then it may be worth it to
> continue on our current path and do a release that includes JDBC 4.
> If Mustang is delayed, then I think it's just time to get 10.2 done to
> get some of the other good features out there. It's been quite a
> while since we've had a feature release. Does anyone know the current
> schedule for Mustang?
>
> Kathy
>
>
The optimizer related regression that I am aware of :
DERBY-1633 - fixed
DERBY-1777 - Army has a patch submitted
DERBY-1806 - from the last comments, unable to replicate.
Is there anything else that I am missing ?
I would assume DERBY-1777 will get committed soon. So from the above and
given
the uncertainty of the exact date of JDK 6 shipment, I don't see why we
should hold up a 10.2 release.
Now another point for discussion is, after 10.2, when Mustang gets
released what should be the version for DERBY
with the JDBC4 support be called - 10.3 ?
-Rajesh
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Myrna van Lunteren <m....@gmail.com>.
On 9/12/06, Kathy Saunders <ka...@mtrad.com> wrote:
> Lance J. Andersen wrote:
>
> >
> >
> >>
> >> 2 - Regarding the Mustang and JDBC 4 issue, my general opinion is
> >> that if Mustang is still coming out in October then it may be worth
> >> it to continue on our current path and do a release that includes
> >> JDBC 4. If Mustang is delayed, then I think it's just time to get
> >> 10.2 done to get some of the other good features out there. It's
> >> been quite a while since we've had a feature release. Does anyone
> >> know the current schedule for Mustang?
> >
> >
> > see http://blogs.sun.com/mr/entry/java_se_6_schedule_update for
> > details on the SE 6 schedule
> >
> >>
> >> Kathy
> >>
> >
> Thank you for the link, Lance. Given these new dates, my vote is to go
> ahead and release Derby 10.2 without JDBC 4.
>
> Kathy
>
>
I may not have been clear earlier. I vote to also go ahead without JDBC4.
Which I guess also means one more round of release candidate-testing.
Myrna
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Kathy Saunders <ka...@mtrad.com>.
Lance J. Andersen wrote:
>
>
>>
>> 2 - Regarding the Mustang and JDBC 4 issue, my general opinion is
>> that if Mustang is still coming out in October then it may be worth
>> it to continue on our current path and do a release that includes
>> JDBC 4. If Mustang is delayed, then I think it's just time to get
>> 10.2 done to get some of the other good features out there. It's
>> been quite a while since we've had a feature release. Does anyone
>> know the current schedule for Mustang?
>
>
> see http://blogs.sun.com/mr/entry/java_se_6_schedule_update for
> details on the SE 6 schedule
>
>>
>> Kathy
>>
>
Thank you for the link, Lance. Given these new dates, my vote is to go
ahead and release Derby 10.2 without JDBC 4.
Kathy
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by "Lance J. Andersen" <La...@Sun.COM>.
>
> 2 - Regarding the Mustang and JDBC 4 issue, my general opinion is that
> if Mustang is still coming out in October then it may be worth it to
> continue on our current path and do a release that includes JDBC 4.
> If Mustang is delayed, then I think it's just time to get 10.2 done to
> get some of the other good features out there. It's been quite a
> while since we've had a feature release. Does anyone know the current
> schedule for Mustang?
see http://blogs.sun.com/mr/entry/java_se_6_schedule_update for details
on the SE 6 schedule
>
> Kathy
>
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Kathy Saunders <ka...@mtrad.com>.
Myrna van Lunteren wrote:
> For what it's worth, my position is somewhere in the middle. I think
> there are some worrying aspects to some of those optimizer-related
> regressions. Also, I feel we're still scrambling on 10.2.; still
> documentation changes are being worked on...Now that in a way some of
> the pressure to release is off, we need to take another look at
> changes slated for 10.2.2 and see if there are any that really should
> go in to make the first release of 10.2 but we've dropped because of
> lack of time.
>
> If we release now, we should focus activities for 10.2.2 with the goal
> of making it more robust as well as having the jdbc40 support in.
>
> Myrna
>
Hi,
To clarify my opinions, here's what I'm concerned about:
1 - If there are quality issues that anyone thinks we should fix, then
what are those specific issues? Advocate to get them on Rick's list to
fix before a release should happen. General concerns about quality at
this point are a problem for me as I don't understand what we are to do
before we can have a release. I do believe there are regressions out
there. I do believe there are regressions in the optimizer specifically
because that's difficult code and from other products I've worked on
when you make significant changes to the optimizer, you almost always
have other issues pop up, and it's not necessarily easy to get them to
surface. But, if you continue to hold up a release because of
regression concerns, you'll never have one. In my opinion, it's
generally time to get this release done, once we have the known
significant issues resolved. If we really believe we need more testing,
then what is that testing and who is going to do it? Discussion on
quality is healthy, but at this point in the release process I believe
we need to be specific about what actions or outcome we need to complete
the release.
2 - Regarding the Mustang and JDBC 4 issue, my general opinion is that
if Mustang is still coming out in October then it may be worth it to
continue on our current path and do a release that includes JDBC 4. If
Mustang is delayed, then I think it's just time to get 10.2 done to get
some of the other good features out there. It's been quite a while
since we've had a feature release. Does anyone know the current
schedule for Mustang?
Kathy
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Myrna van Lunteren <m....@gmail.com>.
On 9/11/06, Suresh Thalamati <su...@gmail.com> wrote:
> Andrew McIntyre wrote:
> > Taking this over to derby-dev...
> >
> > On 9/11/06, Kathey Marsden <km...@sbcglobal.net> wrote:
> >
> >>
> >> Many of these regressions sadly have already made their way into 10.1.3
> >> and therefore are being picked up by users for production. I
> >> think we need to notify the user community of the situation, try to get
> >> more user input on 10.2 and flush out more regressions. We port fixes
> >> to 10.1 to try to get it to a stable state and then release 10.2. Also
> >> any ideas anyone has for new optimizer tests would be good and folks
> >> could write those.
> >>
> >> Those are all my ideas for now. It could be that lots of users have
> >> tried 10.2 without problems but haven't reported in and then it is just
> >> a matter of getting them to speak up.
> >
> >
> > I don't think we should hold up the 10.2 release except for known
> > regressions. I think it's a chicken-and-egg problem. Users aren't
> > motivated to try out the beta, because it's extra time and effort on
> > their part, so you aren't actually informed about regressions until
> > the regression is in a release that people actually try to use. Better
> > to release early so new code gets into actual user's hands so
> > regressions can be flushed out sooner. Regressions happen, and no
> > release is ever go to be perfect (although that would be nice,
> > wouldn't it?).
> > Better to release often so code where regressions have been identified
> > and fixed get into user's hands sooner.
> >
> > I think releasing early and often is an area we as a community, and
> > individually through the tasks we take on for any particular release,
> > could improve.
> >
> > andrew
> >
>
>
> I agree with Andrew, unless there are known regression to be fixed, it
> is not practical to wait for the users to report if there are any
> issues with 10.2. Or there need to be some kind of time frame when
> the beta testing closes.
>
>
> /suresh
>
For what it's worth, my position is somewhere in the middle. I think
there are some worrying aspects to some of those optimizer-related
regressions. Also, I feel we're still scrambling on 10.2.; still
documentation changes are being worked on...Now that in a way some of
the pressure to release is off, we need to take another look at
changes slated for 10.2.2 and see if there are any that really should
go in to make the first release of 10.2 but we've dropped because of
lack of time.
If we release now, we should focus activities for 10.2.2 with the goal
of making it more robust as well as having the jdbc40 support in.
Myrna
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Suresh Thalamati <su...@gmail.com>.
Andrew McIntyre wrote:
> Taking this over to derby-dev...
>
> On 9/11/06, Kathey Marsden <km...@sbcglobal.net> wrote:
>
>>
>> Many of these regressions sadly have already made their way into 10.1.3
>> and therefore are being picked up by users for production. I
>> think we need to notify the user community of the situation, try to get
>> more user input on 10.2 and flush out more regressions. We port fixes
>> to 10.1 to try to get it to a stable state and then release 10.2. Also
>> any ideas anyone has for new optimizer tests would be good and folks
>> could write those.
>>
>> Those are all my ideas for now. It could be that lots of users have
>> tried 10.2 without problems but haven't reported in and then it is just
>> a matter of getting them to speak up.
>
>
> I don't think we should hold up the 10.2 release except for known
> regressions. I think it's a chicken-and-egg problem. Users aren't
> motivated to try out the beta, because it's extra time and effort on
> their part, so you aren't actually informed about regressions until
> the regression is in a release that people actually try to use. Better
> to release early so new code gets into actual user's hands so
> regressions can be flushed out sooner. Regressions happen, and no
> release is ever go to be perfect (although that would be nice,
> wouldn't it?).
> Better to release often so code where regressions have been identified
> and fixed get into user's hands sooner.
>
> I think releasing early and often is an area we as a community, and
> individually through the tasks we take on for any particular release,
> could improve.
>
> andrew
>
I agree with Andrew, unless there are known regression to be fixed, it
is not practical to wait for the users to report if there are any
issues with 10.2. Or there need to be some kind of time frame when
the beta testing closes.
/suresh
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by David Van Couvering <Da...@Sun.COM>.
Might I suggest we have a very simple build script for building the
JDBC4 functionality and adding it to derby.jar and derbyclient.jar, and
that this build script be well tested and documented? All you should
have to do is set one property indicating where your JDK 6 JAVA_HOME is
and you're off and running...
Thanks,
David
Rick Hillegas wrote:
> Thanks, Jean!
>
> Jean T. Anderson wrote:
>
>> Rick Hillegas wrote:
>> ...
>>
>>
>>> Hi Jean,
>>>
>>> I will definitely want to mega-merge before building a new beta
>>> candidate. The following issues prevent us from building a release
>>> candidate, however:
>>>
>>> 1) We need to wrap up or downgrade the urgency of the remaining Urgent
>>> issues
>>> (http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12311108).
>>>
>>>
>>> 2) As you've described, we need to adjust the user guides to clarify how
>>> a customer would see JDBC4 behavior.
>>>
>>
>> I'll offer to work issue #2.
>>
>> -jean
>>
>>
>>
>>> 3) We need to bundle Release Notes with the distribution. I'm working on
>>> this right now.
>>>
>>> Regards,
>>> -Rick
>>>
>
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Rick Hillegas <Ri...@Sun.COM>.
Thanks, Jean!
Jean T. Anderson wrote:
>Rick Hillegas wrote:
>...
>
>
>>Hi Jean,
>>
>>I will definitely want to mega-merge before building a new beta
>>candidate. The following issues prevent us from building a release
>>candidate, however:
>>
>>1) We need to wrap up or downgrade the urgency of the remaining Urgent
>>issues
>>(http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12311108).
>>
>>2) As you've described, we need to adjust the user guides to clarify how
>>a customer would see JDBC4 behavior.
>>
>>
>
>I'll offer to work issue #2.
>
> -jean
>
>
>
>>3) We need to bundle Release Notes with the distribution. I'm working on
>>this right now.
>>
>>Regards,
>>-Rick
>>
>>
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Rick Hillegas wrote:
...
> Hi Jean,
>
> I will definitely want to mega-merge before building a new beta
> candidate. The following issues prevent us from building a release
> candidate, however:
>
> 1) We need to wrap up or downgrade the urgency of the remaining Urgent
> issues
> (http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12311108).
>
> 2) As you've described, we need to adjust the user guides to clarify how
> a customer would see JDBC4 behavior.
I'll offer to work issue #2.
-jean
> 3) We need to bundle Release Notes with the distribution. I'm working on
> this right now.
>
> Regards,
> -Rick
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Rick Hillegas <Ri...@Sun.COM>.
Jean T. Anderson wrote:
>Kathey Marsden wrote:
>
>
>>Kathy Saunders wrote:
>>
>>
>>
>>>I'm not sure what decisive action we can take prior to a 10.2
>>>release. We've asked the user community to test with some response,
>>>but not a lot. The users will only do their testing when they are
>>>motivated.
>>>
>>>
>>My proposal is that we embark on a three week motivation campaign until
>>October 3.
>>
>>
>
><snipped>
>
>We don't have a release candidate yet -- don't we need to get some ducks
>in a row?
>
>(1) Declare consensus on how to proceed with the release.
>
>I believe I hear general agreement that Dan's Plan B is the preferred path:
>
>
>
>>Option A - Source only release with JDBC 4.0 based on proposed final draft
>> Derby 10.2 release is source only, no pre-compiled jars, removes the
>>dependency on the Mustang download.
>>
>>Option B - Release pre-compiled jars without JDBC 4.0 optional build
>> Option A plus pre-compiled jars without JDBC 4.0, already supported by
>>just compiling without a Java SE 6/Mustang JDK.
>>
>>
>
>Are there any objections? If not, I recommend moving on to #2.
>
>(2) Produce an actual release candidate for people to test.
>
>The 10.2.1.3-beta is not a releasable candidate because it was built
>with jdk16 (correct?) and I assume that Rick might want to mega-merge in
>any changes since the last mega-merge. Is that a good/bad assumption, Rick?
>
>
Hi Jean,
I will definitely want to mega-merge before building a new beta
candidate. The following issues prevent us from building a release
candidate, however:
1) We need to wrap up or downgrade the urgency of the remaining Urgent
issues
(http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12311108).
2) As you've described, we need to adjust the user guides to clarify how
a customer would see JDBC4 behavior.
3) We need to bundle Release Notes with the distribution. I'm working on
this right now.
Regards,
-Rick
>The "motivation campaign" Kathey talks about could be part of this test.
>I bet there might be some debate over how long that test period should
>be, but it might be more productive to debate over an actual release
>candidate.
>
>(3) Vote on that release candidate if it seems stable.
>
> -jean
>
>
>
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Kathey Marsden wrote:
> Kathy Saunders wrote:
>
>> I'm not sure what decisive action we can take prior to a 10.2
>> release. We've asked the user community to test with some response,
>> but not a lot. The users will only do their testing when they are
>> motivated.
>
> My proposal is that we embark on a three week motivation campaign until
> October 3.
<snipped>
We don't have a release candidate yet -- don't we need to get some ducks
in a row?
(1) Declare consensus on how to proceed with the release.
I believe I hear general agreement that Dan's Plan B is the preferred path:
> Option A - Source only release with JDBC 4.0 based on proposed final draft
> Derby 10.2 release is source only, no pre-compiled jars, removes the
> dependency on the Mustang download.
>
> Option B - Release pre-compiled jars without JDBC 4.0 optional build
> Option A plus pre-compiled jars without JDBC 4.0, already supported by
> just compiling without a Java SE 6/Mustang JDK.
Are there any objections? If not, I recommend moving on to #2.
(2) Produce an actual release candidate for people to test.
The 10.2.1.3-beta is not a releasable candidate because it was built
with jdk16 (correct?) and I assume that Rick might want to mega-merge in
any changes since the last mega-merge. Is that a good/bad assumption, Rick?
The "motivation campaign" Kathey talks about could be part of this test.
I bet there might be some debate over how long that test period should
be, but it might be more productive to debate over an actual release
candidate.
(3) Vote on that release candidate if it seems stable.
-jean
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Rick Hillegas <Ri...@Sun.COM>.
Kathey Marsden wrote:
> Kathy Saunders wrote:
>
>> I'm not sure what decisive action we can take prior to a 10.2
>> release. We've asked the user community to test with some response,
>> but not a lot. The users will only do their testing when they are
>> motivated.
>
>
> My proposal is that we embark on a three week motivation campaign
> until October 3. I know it is late to start on this but I would
> really like to try and rattle the bushes and think we can get more
> interest. Then wait for a steady state of a week without any new
> regressions. If there have been no regressions filed for a week as of
> October 3, we call a vote. Does that sound ok?
>
> This is what I propose in terms of beta marketing.
>
> - Come up with a list of ideas of beta things to try that might pop
> issues. For example Army's list [1] is very good. Specific risk
> areas that might be of interest to users. I will start a wiki page
> where they can be added.
> - Folks can send out targeted beta test requests to as many users as
> they can where they work and elsewhere that use Derby. Best to ask
> them to try something specific that might interest them and of course
> ask them to ask two more, chain letter style #:)
> - Get the beta announcement prominently on the download site with a
> link to the beta. with the pre-release upgrade option. Is this legal
> and ok?
>
> I sent beta out to some interested users a while back and need to
> pester them and collect feedback and will try to contact more. Rick,
> did you contact the users on UsesOfDerby. I noticed you added email
> addresses. Did you contact these folks? What Apache lists would be
> good to query about trying Derby?
Hi Kathey,
I have not sent any notice to these email addresses. It's worth a try if
we extend the testing period.
Regards,
-Rick
>
> Sorry for the late start on this, but I am ready to jump on this
> effort myself and hope others are motivated to do it as well.
>
> Kathey
>
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Kathey Marsden <km...@sbcglobal.net>.
Kathy Saunders wrote:
> I'm not sure what decisive action we can take prior to a 10.2
> release. We've asked the user community to test with some response,
> but not a lot. The users will only do their testing when they are
> motivated.
My proposal is that we embark on a three week motivation campaign until
October 3. I know it is late to start on this but I would really like
to try and rattle the bushes and think we can get more interest. Then
wait for a steady state of a week without any new regressions. If there
have been no regressions filed for a week as of October 3, we call a
vote. Does that sound ok?
This is what I propose in terms of beta marketing.
- Come up with a list of ideas of beta things to try that might pop
issues. For example Army's list [1] is very good. Specific risk areas
that might be of interest to users. I will start a wiki page where they
can be added.
- Folks can send out targeted beta test requests to as many users as
they can where they work and elsewhere that use Derby. Best to ask
them to try something specific that might interest them and of course
ask them to ask two more, chain letter style #:)
- Get the beta announcement prominently on the download site with a
link to the beta. with the pre-release upgrade option. Is this legal
and ok?
I sent beta out to some interested users a while back and need to
pester them and collect feedback and will try to contact more. Rick, did
you contact the users on UsesOfDerby. I noticed you added email
addresses. Did you contact these folks? What Apache lists would be
good to query about trying Derby?
Sorry for the late start on this, but I am ready to jump on this effort
myself and hope others are motivated to do it as well.
Kathey
Re: 10.2 plans (was Re: 10.2 licensing issue)
Posted by Kathy Saunders <ka...@mtrad.com>.
Andrew McIntyre wrote:
> Taking this over to derby-dev...
>
> On 9/11/06, Kathey Marsden <km...@sbcglobal.net> wrote:
>
>>
>> Many of these regressions sadly have already made their way into 10.1.3
>> and therefore are being picked up by users for production. I
>> think we need to notify the user community of the situation, try to get
>> more user input on 10.2 and flush out more regressions. We port fixes
>> to 10.1 to try to get it to a stable state and then release 10.2. Also
>> any ideas anyone has for new optimizer tests would be good and folks
>> could write those.
>>
>> Those are all my ideas for now. It could be that lots of users have
>> tried 10.2 without problems but haven't reported in and then it is just
>> a matter of getting them to speak up.
>
>
> I don't think we should hold up the 10.2 release except for known
> regressions. I think it's a chicken-and-egg problem. Users aren't
> motivated to try out the beta, because it's extra time and effort on
> their part, so you aren't actually informed about regressions until
> the regression is in a release that people actually try to use. Better
> to release early so new code gets into actual user's hands so
> regressions can be flushed out sooner. Regressions happen, and no
> release is ever go to be perfect (although that would be nice,
> wouldn't it?).
> Better to release often so code where regressions have been identified
> and fixed get into user's hands sooner.
>
> I think releasing early and often is an area we as a community, and
> individually through the tasks we take on for any particular release,
> could improve.
>
> andrew
>
I second Andrew's comments. Kathey has been a great quality advocate
for Derby, and I hope will continue to speak up. But, in this case, I'm
not sure what decisive action we can take prior to a 10.2 release.
We've asked the user community to test with some response, but not a
lot. The users will only do their testing when they are motivated. I
think it's excellent that users were invited to do testing, and I see
that Kathey posted again asking for more testing, which is great.
However, unless we have a specific regression or action that needs to be
taken, I don't believe it makes sense to talk about holding up Derby
10.2 for quality issues. Let's get it out there, and if there are
regressions (in my experience working in technical support for
commercial products for 15 years, there are always regressions), we can
get new builds and/or a maintenance release out. On the other hand, if
we have any specific quality issues that should be addressed prior to a
10.2 release, let's talk about those.
Kathy