Well, from past experience, I know it can be hard to keep up when a bunch of Jira's are being changed. I know I had a few M5 surprises. I also think we should be a bit stricter for a 1.0 release vs a milestone release -- both from a content basis and from a scheduling perspective. So, we should make sure it's as easy as possible to review the jiras.

On the flip-side, Jira is the perfect way of listing/viewing the details of the problems. Is it possible to define a temporary "Not for 1.0" release in Jira? That way we could easily view the 1.0 candidate jiras, the "not for 1.0" jiras, and the current 1.1 jiras. After consensus is reached, the "not for 1.0 jiras" could be moved to 1.1.

--kevan

On 10/26/05, Matt Hogstrom <[EMAIL PROTECTED] > wrote:
Sounds good to me...others?

Geir Magnusson Jr. wrote:
>
> On Oct 26, 2005, at 11:38 AM, Matt Hogstrom wrote:
>
>> All,
>>
>> I'm going through the open JIRAs to see what is a 1.0 requirement  and
>> what is a future feature.  For example, the likelyhood of  getting the
>> TriFork ORB done before 1.0 is probably not likely (but  would be nice).
>>
>> Anyone have suggestions on how to communicate this?  I was going to
>> send out a list of the JIRAs and my take on what we need to get  done
>> for 1.0 in a note to the Dev List before changing anything in  JIRA.
>> Does that sound like a good way to start ?
>
>
> Yes, but I worry that its a lot of work for you.  An alternative (for
> which I suggest we get feedback) is change what you think should be
> post 1.0 and since we get the JIRA change stream here, we can watch  and
> complain^H^H^H^H^H^H discuss the specific ones for which we  disagree...
>
> geir
>


Reply via email to