Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 30 Apr 2008 11:29:45 -0400
From: Kim Haase <Camilla.Haase@Sun.COM>
Subject: Re: 10.3.3 release
In-reply-to: <wjo8prs7wvct.fsf@khepri41.norway.sun.com>
Sender: Camilla.Haase@Sun.COM
To: derby-dev@db.apache.org
Reply-to: Camilla.Haase@Sun.COM
Message-id: <48189069.10501@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <54ac72d70804290004h7e58b9daw4bd45702f2334375@mail.gmail.com>
 <x1o3k5ih57en.fsf@sun.com>
 <54ac72d70804291736l6e6ec28cj72ac77ca63269fe@mail.gmail.com>
 <wjo8tzhjx2l2.fsf@khepri41.norway.sun.com>
 <54ac72d70804300012g7c420178o32d1ba040c9d9880@mail.gmail.com>
 <wjo8prs7wvct.fsf@khepri41.norway.sun.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20070802)

Thanks for doing this, Andrew. I did a spot check of the docs and 
they're the right ones (10.3).

Should the copyright files in each doc be updated to say "2004-2008" 
instead of 2007?

Kim Haase

Knut Anders Hatlen wrote:
> Andrew McIntyre <mcintyre.a@gmail.com> writes:
> 
>> On Tue, Apr 29, 2008 at 11:46 PM, Knut Anders Hatlen
>> <Knut.Hatlen@sun.com> wrote:
>>> Andrew McIntyre <mcintyre.a@gmail.com> writes:
>>>
>>>  > OK, my 'test candidate' is up at:
>>>  >
>>>  > http://people.apache.org/~fuzzylogic/10.3.3.0/
>>>
>>>  Wow, that was quick! :)
>>>
>>>  I'm afraid I'm not able to access the files. Perhaps you forgot to make
>>>  them world readable?
>> I thought I checked this, but maybe I had no problem accessing them
>> via the web because it's my account. Chmod'ed the files all public
>> just to be sure. Note no signatures, version number is wrong, etc. I
>> was just trying to make sure I didn't miss something generating the
>> files. The candidate I post a vote for will be a real candidate.
> 
> Thanks! Some small nits after looking at CHANGES.html:
> 
> The first issue mentioned (DERBY-3641) has resolution "duplicate". I
> removed the fix version in that issue so that it won't appear in your
> next search. It's probably a good idea to update the filter so that it
> only shows fixed issues.
> 
> What about issues that were reported against 10.3.2.2 and fixed in
> 10.3.2.2? Should we remove them from the list? For instance, DERBY-3560
> fixed a build failure that was introduced on the 10.3 branch after the
> previous release. Since this bug never was present in an official
> release, it's probably not that interesting to the users.
> 
>>>  The only problem I see with a 72-hour vote, is that the bylaws of the DB
>>>  PMC[1] require at least 7 days, unless a majority of the PMC members
>>>  have voted +1 (or -1) before that:
>>>
>>>   The minimum and default requirement for a passing vote is simple
>>>   majority of PMC members casting ballots. The default voting period is
>>>   10 days and the minimum is 7 days unless the success or failure is
>>>   arithmetically known.
>>>
>>>  [1] http://db.apache.org/management.html
>> Yes, that is the policy, isn't it. :-)
> 
> I'm afraid so. But the Apache guidelines only say that "[votes] should
> generally be permitted to run for at least 72 hours to provide an
> opportunity for all concerned persons to participate regardless of their
> geographic locations." (http://www.apache.org/foundation/voting.html) So
> there's nothing preventing the DB PMC from allowing a voting period
> shorter than 7 days. I think this has been brought up in the PMC before,
> but no decision was made as far as I remember.
> 
>> I have no problem calling for a vote Friday, May 2, or thereabouts,
>> and ending it and announcing it on the Monday ten days later, May 12
>> if there are no issues that come up and everyone is ok with the
>> release. I'm hoping to get consensus earlier rather than later, and to
>> avoid publishing an announcement near a weekend.
> 
> Sounds like a good plan. I didn't want to push you to having a voting
> period longer than the minimum, but I see your point about not
> announcing the release near a weekend.
>