Great work folks, interesting process to follow I must say! And sorry for messing up, keep in mind for next time I'm really good at stumbling over bugs, i.e. mess up, so set me to test work early =)
Sig On 21 February 2010 17:55, Ethan Jewett <[email protected]> wrote: > Hi, > > Thanks for humoring my concerns, and again for all the work you're doing Dick. > > I've checked out the new tag and tested it. It passes all unit tests, > search is working out of the box, and the security hole is closed. > From my point of view, we're ready for a vote. > > Thanks, > Ethan > > On Sun, Feb 21, 2010 at 10:08 AM, Richard Hirsch <[email protected]> > wrote: >> OK. >> >> I've tagged a new Release Candidate: >> https://svn.apache.org/repos/asf/incubator/esme/tags/apache-esme-1.0-incubating/ >> >> This means that we have to vote again (sigh!) -. >> >> This time I suggest we test the tagged RC before we do a vote. >> >> D. >> >> On Sun, Feb 21, 2010 at 12:49 AM, Ethan Jewett <[email protected]> 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 <[email protected]> >>> 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 >>>> <[email protected]> wrote: >>>>> On Sat, Feb 20, 2010 at 9:03 PM, Ethan Jewett <[email protected]> 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 >>>>> >>>> >>> >> >
