Aaron Mulder wrote:
On 8/8/06, Joe Bohn <[EMAIL PROTECTED]> wrote:
I'm not familiar with the issue and I'm not arguing that we don't need
to fix it. But this problem indicates that it was present in 1.1 and
somehow it didn't make it to the top of the list for 1.1.1 earlier.
Does it need to hold up the release or could it be delivered in 1.1.2?
Anything is possible. It seems like we're still not too clear on our
release process. My thinking is that we should work hard to put
together a good candidate, have people try the candidate, identify and
fix any serious issues with the candidate, release another candidate,
and when we run out of showstopper issues, make that the release.
Therefore, I believe we should work hard to have high-quality
releases, and I believe all the listed issues impact the quality of
the release, as well as in several cases, the compliance.
Now, someone can take the position that we should just crank releases
out the door and keep cranking. In that case, we should forget about
release candidates and just post the builds as releases more or less
as soon as they pass the TCK and idenitfy any issues for the next
release and move on as quickly as possible.
I don't agree with the above statement. Was that posted somewhere ? We've talked about turning
things around faster but I don't think that infers poor quality releases.
I was going to spin up an rc1 this afternoon and look for feedback. The whole goal of this process
is to shake out issues. If there is an issue that we need to address (the server doesn't function
correctly) then we'll fix it. I think what your referring to is assessing what are the issues that
stop a release and we probably have different perspectives on where that line is drawn.
Maybe we should take one approach for dot releases and another
approach for dot-dot releases.
I think the process is the same for 2-digit releases as well as dot releases. We work together to
define the content, spin out a release, certify it, create an rc, gather community feedback and vote
to release it.
In any case, we're going to end the 1.1.1 process with a vote on the
release, and as is, I'm going to vote against it, but it's just a vote
-- neither a binding vote nor a veto.
The binding vote is probably another discussion :) Its clear your concerned about the quality of
the release and the code we make available to users. It would be nice to have you with a binding vote.
IIRC the plurality of the PMC
votes will decide whether it becomes the release or not. I'm not
going to have hard feelings either way, it's just my opinion that we
shouldn't ship given the issues we've identified and so far it seems
like you and Kevan think we should and that's fine.
Its not me and Kevan. We've been nuturing the release along and lots have people have helped get
the 45 + JIRAs in there. The community will make the decision and not two people. I apologize if
I've put anything in e-mail or other form that would lead you to believe differently.
Thanks,
Aaron
Kevan Miller wrote:
>
> On Aug 8, 2006, at 10:14 AM, Matt Hogstrom wrote:
>
>> 1.1.1 is in a form that we can get ready to release it. I was
>> talking with Aaron and he mentioned that there were some security
>> issues he was concerned about. I would like to use this thread to
>> identify any issues that should be considered show stoppers and make
>> the decision on how to move forward.
>>
>> Please use this thread to provide that information. What I think
>> we'll need to make an appropriate assessement is:
>>
>> Issue Description
>> How long have we had it? (has it existed in earlier releases and we
>> knew it)
>> Exposure
>> JIRA issue number tracking the issue.
>>
>> Please provide your input as quickly as possible so we can assess how
>> to proceed with 1.1.1.
>
>
> I don't have any background information -- other than what's in the
> jira database for 1.1.1. I see GERONIMO-2295 -- http://
> issues.apache.org/jira/browse/GERONIMO-2295
>
> I haven't verified the problem. However, given the description, I'd
say
> it's definitely something that needs to be fixed.
>
> It's currently assigned to Alan. Alan, are you working on this?
>
> --kevan
>
>
>
