10.2 release in August?

[Knut Anders Hatlen <Kn...@Sun.COM>]

Hi all,

I was just about to send out a mail yesterday, proposing a 10.2
release in August, when I noticed that Kathey and Andrew had published
the 10.1.3 release schedule on the wiki. Although there might be
collisions between the two schedules, I will post my proposal, and
then we can discuss whether this is doable and desirable, and whether
we need to adjust the schedules.

The reason why I want a 10.2 release in August, is that we have a lot
of new features in trunk that should be made available to our
users. The spirit of open source is "release early, release often",
and in August it is one year since the previous feature release. A
bug-fix release on the 10.1 branch is very good for Derby in my
opinion, but I would also really like to see that we got all the new
features out to our users.

Another 10.2 release process was started earlier this year, but it was
postponed because it could not have JDBC 4.0 support before the JDBC
4.0 spec is generally available. I would therefore like to have a 10.2
release not depending on the JDBC 4.0 schedule (which means that the
release most likely will be without JDBC 4.0 support). If we choose to
go for such a release, I am willing to be release manager.

This is the schedule I was planning to propose:

  May 29: Feature freeze. All new features must have been committed. 

  May 31: Release an alpha version that users can test in order to
  find bugs and provide feedback on the new features.

  June 23: Release a new alpha (beta?) version with (hopefully) many
  bugs fixed since the previous alpha.

  July 21: Have a release candidate ready. Start testing and voting.

  August 1: Release Apache Derby 10.2.1.0.

Obviously, the dates need to be aligned with the 10.1.3 schedule.

Is this something the community wants and would support? And are the
proposed dates for feature freeze and release possible to meet for
those of you who plan to have new features for the 10.2 release?

Thanks,
Knut Anders

Re: 10.2 release in August?

[Andrew McIntyre <mc...@gmail.com>]

On 4/26/06, Bryan Pendleton <bp...@amberpoint.com> wrote:
>
> If the JDK 1.6 and JDBC 4.0 schedules should slip further, for example
> into 2007, it would be a shame to have our hands tied and be unable to
> ship any sort of a 10.2 release until then.

+1. It's the closeness of what I think the two proposed schedules are.
If the later release moved out to December or later then I'd have time
to help with both those releases.

As Jean pointed out, my negative vote is simply a measure of my
support. They're free to have an earlier release in July: it's just
that I know I won't have a whole lot of time to help with testing and
review and such, since I'm still planning on doing the 10.1.3
maintenance release that would wrap up in late June.

Ah, if only the release dates for big, complicated projects like the
JDK were concrete and never moved and we knew when JDBC 4.0 would be
finalized. ;;-D

andrew

Re: 10.2 release in August?

[Bryan Pendleton <bp...@amberpoint.com>]

> Seems close to the Sept/Oct timeframe proposed for the 10.2 release with
> JDBC 4.0.

How confident are we of that proposal?

What I heard, a month ago, seemed like it could be paraphrased as: "JDK 1.6
and JDBC 4.0 have slipped, and we aren't sure really when they will be
done, but it won't be before this fall, so we won't be ready to release
the JDBC 4.0 support until at least then." The message I am remembering was:
http://www.nabble.com/pushing-back-release-date-for-jdbc4-capable-Derby-p3637293.html

https://mustang.dev.java.net/ simply says: "Mustang is targeted for final
release in fall 2006." In my experience, that could mean any time from
early September through late December.

If the JDK 1.6 and JDBC 4.0 schedules should slip further, for example
into 2007, it would be a shame to have our hands tied and be unable to
ship any sort of a 10.2 release until then.

thanks,

bryan

Re: 10.2 release in August?

[Andrew McIntyre <mc...@gmail.com>]

On 4/26/06, Daniel John Debrunner <dj...@apache.org> wrote:
>
> Knut Anders Hatlen wrote:
>
> > You make valid points, and I wholeheartedly agree that we should do a
> > better job with documenting our snapshots. But, as I'm sure you know,
> > alpha quality snapshots cannot be used in production.
>
> Yes, but we want the feedback early so we can fix bugs before people use
> the software in production systems.
>
> If you want feedback on SUR then I strongly encourage you to post a
> 10.2alpha snapshot that contains SUR, write an intro/overview that
> explains what functionality you want people to test, point them to the
> SUR documentation, and spread the word through the derby-user list and
> any other avenues you want. We all probably need to be more pro-active
> about encouraging feedback on new features, I'm not sure pushing for a
> release is the correct way to do that.

+1

Same goes for JDBC 4.0, too. It would be good for people outside of
derby-dev to be looking at these features.

andrew

Re: 10.2 release in August?

[Daniel John Debrunner <dj...@apache.org>]

Knut Anders Hatlen wrote:

> Daniel John Debrunner <dj...@apache.org> writes:

>>We could probably do a better job of providing snapshots. Up to this
>>point we have provided them infrequently. Also, looking at the current
>>10.2 snapshot there is no text around it to say why people should pick
>>it up and what they should be testing.
> 
> 
> You make valid points, and I wholeheartedly agree that we should do a
> better job with documenting our snapshots. But, as I'm sure you know,
> alpha quality snapshots cannot be used in production.

Yes, but we want the feedback early so we can fix bugs before people use
the software in production systems.

If you want feedback on SUR then I strongly encourage you to post a
10.2alpha snapshot that contains SUR, write an intro/overview that
explains what functionality you want people to test, point them to the
SUR documentation, and spread the word through the derby-user list and
any other avenues you want. We all probably need to be more pro-active
about encouraging feedback on new features, I'm not sure pushing for a
release is the correct way to do that.

Dan.

Re: 10.2 release in August?

[Knut Anders Hatlen <Kn...@Sun.COM>]

Daniel John Debrunner <dj...@apache.org> writes:

> Knut Anders Hatlen wrote:
>
>>   August 1: Release Apache Derby 10.2.1.0.
>> 
>> Obviously, the dates need to be aligned with the 10.1.3 schedule.
>> 
>> Is this something the community wants and would support? And are the
>> proposed dates for feature freeze and release possible to meet for
>> those of you who plan to have new features for the 10.2 release?
>
> Seems close to the Sept/Oct timeframe proposed for the 10.2 release with
> JDBC 4.0.

Yes, but the Derby community has no control over when the JDBC 4.0
spec is made GA. What if the spec is delayed even more? I guess the
question is whether JDBC 4.0 is important enough to delay the release
of other useful features indefinitely. I was hoping that a 10.2
release would include features such as scrollable updatable result
sets, online backup, grant/revoke, encrypted password and
internationalized client driver, and since these are features that
other databases already have, my guess is that there are far more
users waiting for these features than for JDBC 4.0.

> "Release early, release often" is good, but if we create too many
> branches for Derby it will cause confusion and additional work for
> contributors and committers as patches might need to be ported to
> several branches.

I agree. Having many branches is potentially painful and confusing. A
10.2 branch was planned anyway, so your concern is that we might get a
10.3 branch right after 10.2 is released, right? This is a risk that
has to be weighed agaist the risk of having to wait for a long time
for the JDBC 4.0 spec.

> Another way to look at the "Release early, release often" is to focus on
> the release early part, we can (&do) make snapshots of 10.2 (trunk)
> available for people to test new features. That is a "release" of the
> software though not an "offical release" with stability etc.
>
> We could probably do a better job of providing snapshots. Up to this
> point we have provided them infrequently. Also, looking at the current
> 10.2 snapshot there is no text around it to say why people should pick
> it up and what they should be testing.

You make valid points, and I wholeheartedly agree that we should do a
better job with documenting our snapshots. But, as I'm sure you know,
alpha quality snapshots cannot be used in production.

-- 
Knut Anders

Re: 10.2 release in August?

[Satheesh Bandaram <sa...@Sourcery.Org>]

Øystein Grøvlen wrote:

> Satheesh Bandaram wrote:
>
>> Don't think keeping them undocumented is sufficient.. There are clear
>> specifications posted to JIRA and open source nature of Derby could
>> allow anyone to attempt to use the features. Even otherwise, GRANT
>> and REVOKE statements are well known and don't really need
>> documentation for many users. We would have to remove the underlying
>> code or disable parts of the functionality.
>
>
> I do not understand this.  Why do we need to actively prevent users
> from using undocumented features?

We don't... if the feature is implemented completely. At this point,
table privileges, routine privileges, schema privileges, database owner,
upgrade and metadata changes as described under DERBY-464 have been
implemented. What is not implemented include SQL standard authorization
for views, triggers and constraints, which follow definer authorization
model, rather than invoker. This means all authorization checks for
these three objects need to use the authorizationId of the person who
created them, not the authorizationId of the person using them. (As
specified in the SQL standard)

Now, if we release Derby with incomplete (or incorrect) authorization
model, don't we have to support this model in the future? Isn't this the
primary reason quoted for not releasing JDBC 4.0 at this point, since
the specs are not final and could change in incompatible way?

> In order to be able to release often, implementors of larger features
> need to be prepared for a release from trunk before their feature is
> completed.  One way to do this would be to provide an property for
> turning the functionality off.  What is a large feature in this
> context? I would say anything that takes more than 6 months to develop.

I agree. I did plan on completing all activities under DERBY-464 in time
for 10.2. When 10.2 date sliped to Oct, I planned to complete remaining
work by Oct. Now any change to pull this closer could put remaining work
at risk. It may be possible to remove some underlying code or disable
it, if absolutely required.

Satheesh

> -- 
> Øystein
>
>
>

Re: 10.2 release in August?

[Daniel John Debrunner <dj...@apache.org>]

Øystein Grøvlen wrote:

> Satheesh Bandaram wrote:
> 
>> Don't think keeping them undocumented is sufficient.. There are clear
>> specifications posted to JIRA and open source nature of Derby could
>> allow anyone to attempt to use the features. Even otherwise, GRANT and
>> REVOKE statements are well known and don't really need documentation
>> for many users. We would have to remove the underlying code or disable
>> parts of the functionality.
> 
> 
> I do not understand this.  Why do we need to actively prevent users from
> using undocumented features?

They may not be ready and in most case they can use them without reading
documentation as they are standard features. If someone takes an
existing application with GRANT/REVOKE and uses it on Derby they are
working under a false assumption that G/R works. Maybe they are relying
on it to provide security, but maybe Derby's G/R isn't ready so that it
does not provide the expected security. We could say it's that person's
fault for not looking at the Derby docs, or we could not allow them to
get into that situation by removing the feature. Removing the feature
seems a better approach to me as it reduces the risk of a bad reputation
spreading for Derby when people get upset trying to use half implemented
features.

> In order to be able to release often, implementors of larger features
> need to be prepared for a release from trunk before their feature is
> completed. 

I agree that feature development should be mindful of releases, such
that the trunk can be released. But I also think that releasing from the
trunk at any time is somewhat unrealistic, one has to have some plans in
place so that timing of incremental feature development can be based
upon those plans. We had plans for a Derby release in April/May, those
plans got delayed to a Sept/Oct release. All seemed clear, everyone
agreed and people started working to those dates.

This unexpected new release, that will end up very close to the planned
release is what is causing the issues, not the (incremental) development
of features. I've seen no demand for this new release on the user list,
I've seen no evidence of the people wanting this release making
snapshots of their desired features available to the community so that
early testing can begin. I'm still trying to understand what is driving
the desire to have this release, given we will have a planned release
with more features one to two months later.

Dan.

Re: 10.2 release in August?

[Øystein Grøvlen <Oy...@Sun.COM>]

Satheesh Bandaram wrote:

> Don't think keeping them undocumented is sufficient.. There are clear 
> specifications posted to JIRA and open source nature of Derby could 
> allow anyone to attempt to use the features. Even otherwise, GRANT and 
> REVOKE statements are well known and don't really need documentation for 
> many users. We would have to remove the underlying code or disable parts 
> of the functionality.

I do not understand this.  Why do we need to actively prevent users from 
using undocumented features?

In order to be able to release often, implementors of larger features 
need to be prepared for a release from trunk before their feature is 
completed.  One way to do this would be to provide an property for 
turning the functionality off.  What is a large feature in this context? 
I would say anything that takes more than 6 months to develop.

--
Øystein

Re: 10.2 release in August?

[Knut Anders Hatlen <Kn...@Sun.COM>]

Satheesh Bandaram <sa...@Sourcery.Org> writes:

> Daniel John Debrunner wrote:
>
>     Knut Anders Hatlen wrote:
>
>           August 1: Release Apache Derby 10.2.1.0.
>         
>         Obviously, the dates need to be aligned with the 10.1.3 schedule.
>         
>         Is this something the community wants and would support? And are the
>         proposed dates for feature freeze and release possible to meet for
>         those of you who plan to have new features for the 10.2 release?
>
>     Seems close to the Sept/Oct timeframe proposed for the 10.2 release with
>     JDBC 4.0.
>
> Grant & Revoke proposed under DERBY-464 will not be ready by May 29. Many parts of the spec have
> already been implemented, while authorization model for views, triggers and constraints is not. This
> will leave authorization model incomplete and could force us to support this incomplete model in
> future releases. May need us to add additional properties like derby.database.sqlAuthorization.
> (Yak!)

Thanks for the update, Satheesh. Does this mean that an earlier
release would have to back out or disable parts of your code, or could
we keep them as undocumented features?

-- 
Knut Anders

Re: 10.2 release in August?

[Daniel John Debrunner <dj...@apache.org>]

Knut Anders Hatlen wrote:

>   August 1: Release Apache Derby 10.2.1.0.
> 
> Obviously, the dates need to be aligned with the 10.1.3 schedule.
> 
> Is this something the community wants and would support? And are the
> proposed dates for feature freeze and release possible to meet for
> those of you who plan to have new features for the 10.2 release?

Seems close to the Sept/Oct timeframe proposed for the 10.2 release with
JDBC 4.0.

"Release early, release often" is good, but if we create too many
branches for Derby it will cause confusion and additional work for
contributors and committers as patches might need to be ported to
several branches.

Another way to look at the "Release early, release often" is to focus on
the release early part, we can (&do) make snapshots of 10.2 (trunk)
available for people to test new features. That is a "release" of the
software though not an "offical release" with stability etc.

We could probably do a better job of providing snapshots. Up to this
point we have provided them infrequently. Also, looking at the current
10.2 snapshot there is no text around it to say why people should pick
it up and what they should be testing.

Dan.

Re: 10.2 release in August?

[Andreas Korneliussen <an...@sun.com>]

Jean T. Anderson wrote:
> Andreas Korneliussen wrote:
> ...
> 
>>+1 I would like to support this release, and the proposed schedule seems
>>to be realisitic in terms of getting the SUR features (+related
>>bugfixes) into the release.
> 
> 
> at the risk out sounding totally out of touch .... what's SUR?
> 
Scrollable updatable resultsets.

Andreas

Re: 10.2 release in August?

["Jean T. Anderson" <jt...@bristowhill.com>]

Andreas Korneliussen wrote:
...
> 
> +1 I would like to support this release, and the proposed schedule seems
> to be realisitic in terms of getting the SUR features (+related
> bugfixes) into the release.

at the risk out sounding totally out of touch .... what's SUR?

 -jean

Re: 10.2 release in August?

[Dy...@Sun.COM]

Andreas Korneliussen <An...@Sun.COM> writes:
[snip]
> +1
>
> Yes, I think we do have many new features, which are independent from
> JDBC 4 (i.e SUR), and it would be good to get them released to users.

+1 

I also feel that there are enough new features to warrant a new
feature release fairly soon. It is really too bad that Grant/Revoke is
not ready yet, because that would have been a valuable addition to
such a release.

>
>> This is the schedule I was planning to propose:
>>   May 29: Feature freeze. All new features must have been committed.
>> May 31: Release an alpha version that users can test in order to
>>   find bugs and provide feedback on the new features.
>>   June 23: Release a new alpha (beta?) version with (hopefully) many
>>   bugs fixed since the previous alpha.
>>   July 21: Have a release candidate ready. Start testing and voting.
>>   August 1: Release Apache Derby 10.2.1.0.
>> Obviously, the dates need to be aligned with the 10.1.3 schedule.
>> Is this something the community wants and would support? And are the
>> proposed dates for feature freeze and release possible to meet for
>> those of you who plan to have new features for the 10.2 release?
>> 
>
> +1 I would like to support this release, and the proposed schedule
> seems to be realisitic in terms of getting the SUR features (+related
> bugfixes) into the release.

I also thought this schedule looked reasonable, but the feedback seems
to indicate that others disagree, which is too bad... 

I can understand that this comes close to 10.1.3, but I really think
we need a release from trunk soon. In addition to getting new features
out to non-snapshot users, it could also cut down on the
need to merge so many fixes to the 10.1 branch. It seems like the
difference between 10.1 and trunk is already creating hairy merge issues...

-- 
dt

Re: 10.2 release in August?

[Andreas Korneliussen <An...@Sun.COM>]

Knut Anders Hatlen wrote:
> Hi all,
> 
> I was just about to send out a mail yesterday, proposing a 10.2
> release in August, when I noticed that Kathey and Andrew had published
> the 10.1.3 release schedule on the wiki. Although there might be
> collisions between the two schedules, I will post my proposal, and
> then we can discuss whether this is doable and desirable, and whether
> we need to adjust the schedules.
> 
> The reason why I want a 10.2 release in August, is that we have a lot
> of new features in trunk that should be made available to our
> users. The spirit of open source is "release early, release often",
> and in August it is one year since the previous feature release. A
> bug-fix release on the 10.1 branch is very good for Derby in my
> opinion, but I would also really like to see that we got all the new
> features out to our users.
> 
> Another 10.2 release process was started earlier this year, but it was
> postponed because it could not have JDBC 4.0 support before the JDBC
> 4.0 spec is generally available. I would therefore like to have a 10.2
> release not depending on the JDBC 4.0 schedule (which means that the
> release most likely will be without JDBC 4.0 support). If we choose to
> go for such a release, I am willing to be release manager.
> 

+1

Yes, I think we do have many new features, which are independent from 
JDBC 4 (i.e SUR), and it would be good to get them released to users.

> This is the schedule I was planning to propose:
> 
>   May 29: Feature freeze. All new features must have been committed. 
> 
>   May 31: Release an alpha version that users can test in order to
>   find bugs and provide feedback on the new features.
> 
>   June 23: Release a new alpha (beta?) version with (hopefully) many
>   bugs fixed since the previous alpha.
> 
>   July 21: Have a release candidate ready. Start testing and voting.
> 
>   August 1: Release Apache Derby 10.2.1.0.
> 
> Obviously, the dates need to be aligned with the 10.1.3 schedule.
> 
> Is this something the community wants and would support? And are the
> proposed dates for feature freeze and release possible to meet for
> those of you who plan to have new features for the 10.2 release?
> 

+1 I would like to support this release, and the proposed schedule seems 
to be realisitic in terms of getting the SUR features (+related 
bugfixes) into the release.

-- Andreas

Re: 10.2 release in August?

[Knut Anders Hatlen <Kn...@Sun.COM>]

Andrew McIntyre <mc...@gmail.com> writes:

> On 4/26/06, Knut Anders Hatlen <Kn...@sun.com> wrote:
>> A bug-fix release on the 10.1 branch is very good for Derby in my
>> opinion, but I would also really like to see that we got all the new
>> features out to our users.
>>
>> I would therefore like to have a 10.2
>> release not depending on the JDBC 4.0 schedule (which means that the
>> release most likely will be without JDBC 4.0 support).
>
> So what you're saying is that the release you are proposing is
> definitely going to be without JDBC 4.0? Or are you saying that
> somehow JDBC 4.0 support might be included in your release?

I don't see that there's any possibility for a release with JDBC 4.0
in August.

>> Is this something the community wants and would support?
>
> Rick, are you still planning to have a release with JDBC 4.0 in the
> Sept./Oct. timeframe? And does it really make sense to have two such
> feature releases so close together, within two months of each other?
>
> If Rick is still planning another feature release - which would now be
> 10.3 I suppose - in Sept./Oct., then it's a -1 from me. Personally,
> I'm not much interested just in the churn and the time involved in
> testing two such feature releases so close together right after a
> maintenance release.

Thanks for your feedback. I will take that into consideration.

-- 
Knut Anders

Re: Binding votes for a release (was Re: 10.2 release in August?)

["Jean T. Anderson" <jt...@bristowhill.com>]

Michelle Caisse wrote:
> Jean T. Anderson wrote:
>> Michelle Caisse wrote:

<snip>

>> Probably it's time to discuss clarifying the DB PMC docs with the DB
>> PMC. Since you're on the DB PMC, I'd encourage you to go ahead and
>> initiate that discussion.
>>
> I agree, and I will do that.

And I meant to say "it's time to discuss clarifying the DB site docs
with the DB PMC ...."

 -jean

Re: Binding votes for a release (was Re: 10.2 release in August?)

[Michelle Caisse <Mi...@Sun.COM>]

Jean T. Anderson wrote:

>Michelle Caisse wrote:
>  
>
> ...
>
>>ready to be released".  The Apache guidelines do not cover a vote on a
>>release plan, but the Apache DB site does: "Lazy majority decides each
>>issue in a release plan."  Again, according to
>>    
>>
>
>I think "lazy majority" in this context refers to lazy concensus, which
>is an alternative to voting; see
>http://www.apache.org/foundation/voting.html#LazyConsensus .
>  
>

<>http://db.apache.org/decisions.html distinguishes lazy consensus 
(vetoable) versus lazy majority (majority wins).

>>http://db.apache.org/decisions.html, the binding votes are cast by
>>committers.  Am I missing anything?
>>    
>>
>
>Probably it's time to discuss clarifying the DB PMC docs with the DB
>PMC. Since you're on the DB PMC, I'd encourage you to go ahead and
>initiate that discussion.
>
I agree, and I will do that.

-- Michelle

Re: Binding votes for a release (was Re: 10.2 release in August?)

["Jean T. Anderson" <jt...@bristowhill.com>]

Michelle Caisse wrote:
> I want to clarify that the current discussion is about a release plan,
> not a release, so the issue of PMC binding votes is moot for now.  It's

Yes, that's correct. That's why I changed the subject from "Re: 10.2
release in August?" to "Binding votes for a release". Sometimes
discussion can get off-topic from the original and it's then good to
modify the subject accordingly.

And this one definitely went further then my original intent, which was
to simply clarify that releases can't be vetoed, unlike code changes. At
any rate, asf culture often liberally sprinkles -1 and +1's throughout
discussions even though no vote has been called.

> my understanding that a release vote is a vote "on whether a package is
> ready to be released".  The Apache guidelines do not cover a vote on a
> release plan, but the Apache DB site does: "Lazy majority decides each
> issue in a release plan."  Again, according to

I think "lazy majority" in this context refers to lazy concensus, which
is an alternative to voting; see
http://www.apache.org/foundation/voting.html#LazyConsensus .

> http://db.apache.org/decisions.html, the binding votes are cast by
> committers.  Am I missing anything?

Probably it's time to discuss clarifying the DB PMC docs with the DB
PMC. Since you're on the DB PMC, I'd encourage you to go ahead and
initiate that discussion.

 -jean

<snipped>

Re: Binding votes for a release (was Re: 10.2 release in August?)

[Michelle Caisse <Mi...@Sun.COM>]

I want to clarify that the current discussion is about a release plan, 
not a release, so the issue of PMC binding votes is moot for now.  It's 
my understanding that a release vote is a vote "on whether a package is 
ready to be released".  The Apache guidelines do not cover a vote on a 
release plan, but the Apache DB site does: "Lazy majority decides each 
issue in a release plan."  Again, according to 
http://db.apache.org/decisions.html, the binding votes are cast by 
committers.  Am I missing anything?

-- Michelle

Jean T. Anderson wrote:

>actually, there's a good thread on legal-discuss regarding this topic
>starting at:
>
>http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200511.mbox/%3c7edfeeef0511132111r6dd4838vbee6fbe5319b611a@mail.gmail.com%3e
>
>and for anyone's email client that wraps the previous line:
>
>   http://tinyurl.com/nunu8
>
> -jean
>
>
>Jean T. Anderson wrote:
>  
>
>>Michelle Caisse wrote:
>>
>>    
>>
>>>Jean T. Anderson wrote:
>>>
>>>
>>>      
>>>
>>>>One clarifying procedural note ... voting guidelines for releases are
>>>>here:
>>>>
>>>>http://www.apache.org/foundation/voting.html#ReleaseVotes
>>>>
>>>>A release requires three binding +1 votes -- db pmc votes are binding
>>>>for derby. A -1 expresses an opinion, but can't actually veto a release.
>>>>That much said, the community should consider any -1 votes.
>>>>
>>>>        
>>>>
>>>Can you point me to where it says that pmc votes are binding for Derby? 
>>>I see that http://www.apache.org/foundation/voting.html says "the basic
>>>rule is that only PMC members have binding votes", but according to
>>>http://db.apache.org/decisions.html, only committers have binding
>>>votes.  By my reading, Apache gives precedence to the community rules.
>>>      
>>>
>>PMCs fall under ASF guidelines.  If you've noticed recent derby vote
>>threads, committers and db pmc members are always identified in the
>>final result post.  We haven't have a situation yet where a derby vote
>>had fewer than 3 db pmc votes, so it hasn't been an issue.
>>
>> -jean
>>
>>
>>    
>>
>
>  
>

Binding votes for a release (was Re: 10.2 release in August?)

["Jean T. Anderson" <jt...@bristowhill.com>]

actually, there's a good thread on legal-discuss regarding this topic
starting at:

http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200511.mbox/%3c7edfeeef0511132111r6dd4838vbee6fbe5319b611a@mail.gmail.com%3e

and for anyone's email client that wraps the previous line:

   http://tinyurl.com/nunu8

 -jean


Jean T. Anderson wrote:
> Michelle Caisse wrote:
> 
>>Jean T. Anderson wrote:
>>
>>
>>>One clarifying procedural note ... voting guidelines for releases are
>>>here:
>>>
>>>http://www.apache.org/foundation/voting.html#ReleaseVotes
>>>
>>>A release requires three binding +1 votes -- db pmc votes are binding
>>>for derby. A -1 expresses an opinion, but can't actually veto a release.
>>>That much said, the community should consider any -1 votes.
>>>
>>
>>Can you point me to where it says that pmc votes are binding for Derby? 
>>I see that http://www.apache.org/foundation/voting.html says "the basic
>>rule is that only PMC members have binding votes", but according to
>>http://db.apache.org/decisions.html, only committers have binding
>>votes.  By my reading, Apache gives precedence to the community rules.
> 
> 
> PMCs fall under ASF guidelines.  If you've noticed recent derby vote
> threads, committers and db pmc members are always identified in the
> final result post.  We haven't have a situation yet where a derby vote
> had fewer than 3 db pmc votes, so it hasn't been an issue.
> 
>  -jean
> 
> 

Re: 10.2 release in August?

["Jean T. Anderson" <jt...@bristowhill.com>]

Michelle Caisse wrote:
> Jean T. Anderson wrote:
> 
>> One clarifying procedural note ... voting guidelines for releases are
>> here:
>>
>> http://www.apache.org/foundation/voting.html#ReleaseVotes
>>
>> A release requires three binding +1 votes -- db pmc votes are binding
>> for derby. A -1 expresses an opinion, but can't actually veto a release.
>> That much said, the community should consider any -1 votes.
>>
> Can you point me to where it says that pmc votes are binding for Derby? 
> I see that http://www.apache.org/foundation/voting.html says "the basic
> rule is that only PMC members have binding votes", but according to
> http://db.apache.org/decisions.html, only committers have binding
> votes.  By my reading, Apache gives precedence to the community rules.

PMCs fall under ASF guidelines.  If you've noticed recent derby vote
threads, committers and db pmc members are always identified in the
final result post.  We haven't have a situation yet where a derby vote
had fewer than 3 db pmc votes, so it hasn't been an issue.

 -jean

Re: 10.2 release in August?

[Michelle Caisse <Mi...@Sun.COM>]

Jean T. Anderson wrote:

>One clarifying procedural note ... voting guidelines for releases are here:
>
>http://www.apache.org/foundation/voting.html#ReleaseVotes
>
>A release requires three binding +1 votes -- db pmc votes are binding
>for derby. A -1 expresses an opinion, but can't actually veto a release.
>That much said, the community should consider any -1 votes.
>
>  
>
Can you point me to where it says that pmc votes are binding for Derby?  
I see that http://www.apache.org/foundation/voting.html says "the basic 
rule is that only PMC members have binding votes", but according to 
http://db.apache.org/decisions.html, only committers have binding 
votes.  By my reading, Apache gives precedence to the community rules.

-- Michelle

Re: 10.2 release in August?

["Jean T. Anderson" <jt...@bristowhill.com>]

Andrew McIntyre wrote:
...
> If Rick is still planning another feature release - which would now be
> 10.3 I suppose - in Sept./Oct., then it's a -1 from me. Personally,
> I'm not much interested just in the churn and the time involved in
> testing two such feature releases so close together right after a
> maintenance release.

One clarifying procedural note ... voting guidelines for releases are here:

http://www.apache.org/foundation/voting.html#ReleaseVotes

A release requires three binding +1 votes -- db pmc votes are binding
for derby. A -1 expresses an opinion, but can't actually veto a release.
That much said, the community should consider any -1 votes.

 -jean

Re: 10.2 release in August?

[Daniel John Debrunner <dj...@apache.org>]

Satheesh Bandaram wrote:

> If there is a good chance of Mustang and JDBC4 being ready by Sept/Oct, we
> should avoid another release in August. Rick doesn't seem to foresee a
> Mustang schedule slip and given
> incomplete nature of Grant & Revoke authorization, I vote to keep one
> release in Sep/Oct.

+1

However, I think we need to have the 10.2 release in Sep/Oct regardless
of any Mustang release, we cannot continually delay Derby releases based
upon external factors. I think we should try to match the Mustang
schedule to get JDBC 4.0 in, but if Mustang slips we need to release
10.2. This of course may lead to the same "two quick release" issues
*if* Mustang slips. I think this is less of a problem because the
discussion is just about adding JDBC 4.0, not two releases each with
their own set of new features. If Mustang slips I can see an argument
for shipping 10.2 in Oct and then a 10.2 maintainance release with JDBC
4.0. JDBC 4.0 is more or less just api (new drivers) on top of the
database engine. I think this would cause less issues than 10.2 and 10.3
releases and branches within a short time of each other.

I also think a single 10.2 in Oct release is less of an issue because
that's the current plan. We were planning a release in May/June but it
got slipped to Oct, this caused me to adjust schedules and re-order what
I was doing. I'm sure others did the same. Now with a much earlier
unexpected release I won't have time to finish what I wanted for 10.2
and thus may need code to be backed out to leave the system in a useable
state that provides forward compatibility. Backing out large amounts of
code (e.g. possibly grant/revoke) will cause stability issues and hamper
efforts to port bug fixes between branches.

I think we could use this time between now and October to promote the
upcoming 10.2 release with snapshots and guidelines etc. on which new
features to test. If we can do this promotion successfully we will have
a much better 10.2 release in Oct.

Thanks,
Dan.

Re: 10.2 release in August?

[Satheesh Bandaram <ba...@gmail.com>]

If there is a good chance of Mustang and JDBC4 being ready by Sept/Oct, we
should avoid another release in August. Rick doesn't seem to foresee a
Mustang schedule slip and given
incomplete nature of Grant & Revoke authorization, I vote to keep one
release in Sep/Oct.

Satheesh

On 4/26/06, Rick Hillegas <Ri...@sun.com> wrote:
>
> Hi Andrew,
>
> Yes, I'm still planning to manage a JDBC4-capable Derby release to go GA
> soon after Mustang (jdk1.6) goes GA in September/October. Bryan and Knut
> have expressed some concern that the Mustang schedule may slip. Although
> I do not foresee a Mustang schedule slip, I acknowledge the risk here.
> My plans assume that Mustang will hit its deliverables.
>
> Regards,
> -Rick
>
> Andrew McIntyre wrote:
>
> >On 4/26/06, Knut Anders Hatlen <Kn...@sun.com> wrote:
> >
> >
> >>A bug-fix release on the 10.1 branch is very good for Derby in my
> >>opinion, but I would also really like to see that we got all the new
> >>features out to our users.
> >>
> >>I would therefore like to have a 10.2
> >>release not depending on the JDBC 4.0 schedule (which means that the
> >>release most likely will be without JDBC 4.0 support).
> >>
> >>
> >
> >So what you're saying is that the release you are proposing is
> >definitely going to be without JDBC 4.0? Or are you saying that
> >somehow JDBC 4.0 support might be included in your release?
> >
> >
> >
> >>Is this something the community wants and would support?
> >>
> >>
> >
> >Rick, are you still planning to have a release with JDBC 4.0 in the
> >Sept./Oct. timeframe? And does it really make sense to have two such
> >feature releases so close together, within two months of each other?
> >
> >If Rick is still planning another feature release - which would now be
> >10.3 I suppose - in Sept./Oct., then it's a -1 from me. Personally,
> >I'm not much interested just in the churn and the time involved in
> >testing two such feature releases so close together right after a
> >maintenance release.
> >
> >andrew
> >
> >
>
>

Re: 10.2 release in August?

[Rick Hillegas <Ri...@Sun.COM>]

Hi Andrew,

Yes, I'm still planning to manage a JDBC4-capable Derby release to go GA 
soon after Mustang (jdk1.6) goes GA in September/October. Bryan and Knut 
have expressed some concern that the Mustang schedule may slip. Although 
I do not foresee a Mustang schedule slip, I acknowledge the risk here. 
My plans assume that Mustang will hit its deliverables.

Regards,
-Rick

Andrew McIntyre wrote:

>On 4/26/06, Knut Anders Hatlen <Kn...@sun.com> wrote:
>  
>
>>A bug-fix release on the 10.1 branch is very good for Derby in my
>>opinion, but I would also really like to see that we got all the new
>>features out to our users.
>>
>>I would therefore like to have a 10.2
>>release not depending on the JDBC 4.0 schedule (which means that the
>>release most likely will be without JDBC 4.0 support).
>>    
>>
>
>So what you're saying is that the release you are proposing is
>definitely going to be without JDBC 4.0? Or are you saying that
>somehow JDBC 4.0 support might be included in your release?
>
>  
>
>>Is this something the community wants and would support?
>>    
>>
>
>Rick, are you still planning to have a release with JDBC 4.0 in the
>Sept./Oct. timeframe? And does it really make sense to have two such
>feature releases so close together, within two months of each other?
>
>If Rick is still planning another feature release - which would now be
>10.3 I suppose - in Sept./Oct., then it's a -1 from me. Personally,
>I'm not much interested just in the churn and the time involved in
>testing two such feature releases so close together right after a
>maintenance release.
>
>andrew
>  
>

Re: 10.2 release in August?

[Knut Anders Hatlen <Kn...@Sun.COM>]

Andrew McIntyre <mc...@gmail.com> writes:

> On 4/26/06, Knut Anders Hatlen <Kn...@sun.com> wrote:

>> Is this something the community wants and would support?
>
> Rick, are you still planning to have a release with JDBC 4.0 in the
> Sept./Oct. timeframe? And does it really make sense to have two such
> feature releases so close together, within two months of each other?
>
> If Rick is still planning another feature release - which would now be
> 10.3 I suppose - in Sept./Oct., then it's a -1 from me. Personally,
> I'm not much interested just in the churn and the time involved in
> testing two such feature releases so close together right after a
> maintenance release.

It seems like most of the community feels this way about a feature
release in August, and I therefore withdraw my proposal. Thanks to
everyone who has provided feedback.

-- 
Knut Anders

Re: 10.2 release in August?

[Andrew McIntyre <mc...@gmail.com>]

On 4/26/06, Knut Anders Hatlen <Kn...@sun.com> wrote:
> A bug-fix release on the 10.1 branch is very good for Derby in my
> opinion, but I would also really like to see that we got all the new
> features out to our users.
>
> I would therefore like to have a 10.2
> release not depending on the JDBC 4.0 schedule (which means that the
> release most likely will be without JDBC 4.0 support).

So what you're saying is that the release you are proposing is
definitely going to be without JDBC 4.0? Or are you saying that
somehow JDBC 4.0 support might be included in your release?

> Is this something the community wants and would support?

Rick, are you still planning to have a release with JDBC 4.0 in the
Sept./Oct. timeframe? And does it really make sense to have two such
feature releases so close together, within two months of each other?

If Rick is still planning another feature release - which would now be
10.3 I suppose - in Sept./Oct., then it's a -1 from me. Personally,
I'm not much interested just in the churn and the time involved in
testing two such feature releases so close together right after a
maintenance release.

andrew

Re: 10.2 release in August?

[Knut Anders Hatlen <Kn...@Sun.COM>]

"Jean T. Anderson" <jt...@bristowhill.com> writes:

> What features would you like to see released in August that you don't
> think could wait for an October release?

It is not a single feature, but the set of new features that is
interesting. I have been in contact with users who are very eager to
see a feature release in August, and who think that October is too
late and that the JDBC 4.0 schedule is too vague to be depending
on. They have for instance expressed their enthusiasm for scrollable
updatable result sets, online backup and internationalization.

> Would an August 10.2 release be instead of the 10.1.3 currently under
> way? Or are we talking about a 10.1.3 maintenance (voting starts June
> 9), followed by 10.2 (voting starts August), followed by 10.3 (October?).

I have no intentions of stopping the 10.1.3 release, so voting for
10.1.3 in June and for 10.2 at the end of July sounds reasonable to
me. Whether or not it is followed by 10.3 in October is very hard to
predict as long as we only know that Mustang is planned sometime this
autumn.

> "Release early and often" is good, but needs to be balanced by the
> effort required to do a release: the voting cycle, pmc approval,
> logistics in making it available for download from asf mirrors (plus the
> branch management issues Dan mentioned in his response).
>
> Releasing every two months sounds really aggressive and I'd be concerned
> that we're spending more time on release cycles than code changes....

Good points, but now we haven't spent time on release cycles for a
long time, so there's a lot of fine code that's not available to our
users. And software is all about users, right? There is never a
perfect time to do a release because you can always wait a month or
two for a new fancy feature, but then there's not going to be a
release.

-- 
Knut Anders

Re: 10.2 release in August?

["Jean T. Anderson" <jt...@bristowhill.com>]

What features would you like to see released in August that you don't
think could wait for an October release?

Would an August 10.2 release be instead of the 10.1.3 currently under
way? Or are we talking about a 10.1.3 maintenance (voting starts June
9), followed by 10.2 (voting starts August), followed by 10.3 (October?).

"Release early and often" is good, but needs to be balanced by the
effort required to do a release: the voting cycle, pmc approval,
logistics in making it available for download from asf mirrors (plus the
branch management issues Dan mentioned in his response).

Releasing every two months sounds really aggressive and I'd be concerned
that we're spending more time on release cycles than code changes....

 -jean

Knut Anders Hatlen wrote:
> Hi all,
> 
> I was just about to send out a mail yesterday, proposing a 10.2
> release in August, when I noticed that Kathey and Andrew had published
> the 10.1.3 release schedule on the wiki. Although there might be
> collisions between the two schedules, I will post my proposal, and
> then we can discuss whether this is doable and desirable, and whether
> we need to adjust the schedules.
> 
> The reason why I want a 10.2 release in August, is that we have a lot
> of new features in trunk that should be made available to our
> users. The spirit of open source is "release early, release often",
> and in August it is one year since the previous feature release. A
> bug-fix release on the 10.1 branch is very good for Derby in my
> opinion, but I would also really like to see that we got all the new
> features out to our users.
> 
> Another 10.2 release process was started earlier this year, but it was
> postponed because it could not have JDBC 4.0 support before the JDBC
> 4.0 spec is generally available. I would therefore like to have a 10.2
> release not depending on the JDBC 4.0 schedule (which means that the
> release most likely will be without JDBC 4.0 support). If we choose to
> go for such a release, I am willing to be release manager.
> 
> This is the schedule I was planning to propose:
> 
>   May 29: Feature freeze. All new features must have been committed. 
> 
>   May 31: Release an alpha version that users can test in order to
>   find bugs and provide feedback on the new features.
> 
>   June 23: Release a new alpha (beta?) version with (hopefully) many
>   bugs fixed since the previous alpha.
> 
>   July 21: Have a release candidate ready. Start testing and voting.
> 
>   August 1: Release Apache Derby 10.2.1.0.
> 
> Obviously, the dates need to be aligned with the 10.1.3 schedule.
> 
> Is this something the community wants and would support? And are the
> proposed dates for feature freeze and release possible to meet for
> those of you who plan to have new features for the 10.2 release?
> 
> Thanks,
> Knut Anders