esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
Subject Re: [VOTE] Approve the release of apache-esme-incubating-1.0 - (Yes Again :->)
Date Sun, 21 Feb 2010 16:08:44 GMT

I've tagged a new Release Candidate:

This means that we have to vote again (sigh!) -.

This time I suggest we test the tagged RC before we do a vote.


On Sun, Feb 21, 2010 at 12:49 AM, Ethan Jewett <> wrote:
> Hi all,
> For the original issue, where doing nothing simply results in a loss
> of functionality, I would agree. However, I think this is a major
> security hole that requires that the person deploying the software to
> take a specific action. If they don't take this action, then their
> deployment is vulnerable. I'm not comfortable putting the ESME stamp
> on a release that we know has this kind of issue. I think it's worth
> spending the extra time to address this issue and set the precedent
> that we don't release software with known security holes.
> I'm sticking with my -1 at this point. I'm not trying to veto (I don't
> even know if I can :-), so if a majority have voted for release after
> 72 hours (which I think is the case), then feel free to go ahead.
> Ethan
> On Sat, Feb 20, 2010 at 3:46 PM, Richard Hirsch <> wrote:
>> I agree with Bertrand.
>> I'd like to get this release out and then do a another release soon to
>> fix the errors.
>> Right now, there are the two issues that have to be changed and Ethan
>> has already changed them in SVN.
>>>I believe that this will happen on any system and I think the fact that search
and the API2 doesn't work out of the box will really
>>>confuse people.
>> The fact that search doesn't work is IMHO the lesser of the two
>> errors. Does the API2 not work at all or is the problem more the
>> security one associated with the "role.api_test=integration-admin"
>> setting?
>> I'm reluctant to cut a new release , because then we'd have to start
>> over again. Like I've said, I see this first release as a learning
>> experience. No release will be perfect and will always include a few
>> bugs. I'd rather get this release out and then do another release in 2
>> weeks time with the bug fixes.  Now that we know how to do create
>> releases it will be easier the next time.  We should get used to
>> I'd rather describe the two changes that have to made in the resource
>> files in a blog post or on the wiki and then push for a new release.
>> Anyone else have thoughts on this
>> D.
>> On Sat, Feb 20, 2010 at 10:10 PM, Bertrand Delacretaz
>> <> wrote:
>>> On Sat, Feb 20, 2010 at 9:03 PM, Ethan Jewett <> wrote:
>>>> ...Maybe making this two-line change to one file is small enough that we
>>>> don't have to revote. I'm not sure. Maybe the mentors can weigh in....
>>> Anything that changes the release artifacts needs a new vote.
>>> On the other hand, if there's a workaround (IIUC people can change
>>> something manually to get things to work?) I suggest releasing as is.
>>> Nothing prevents you from making another release soon, if needed.
>>> Getting used to releasing is good progress towards graduation ;-)
>>> -Bertrand

View raw message