Second the motion!
You did a great job last time around, and unless someone else has a
burning desire to leap over the cliff with a hankie for a parachute,
you're it.
Craig
On Jul 9, 2007, at 10:13 AM, Marc Prud'hommeaux wrote:
>
>
>> We also need a release manager (a person who will do what Marc and
>> Mike did for 0.9.6 and 0.9.7).
>
> Unless anyone else has a desire to do the 1.0.0 release, I'll
> nominate myself, since I think I have a good idea about the things
> that need to be changed in the build process to accommodate our TLP
> status.
>
>
>
> On Jul 9, 2007, at 10:04 AM, Craig L Russell wrote:
>
>> I think we need to first go through the list of JIRA issues for
>> 0.9.8 and 1.0.0 and really think hard about whether they should be
>> fixed or not.
>>
>> We also need a release manager (a person who will do what Marc and
>> Mike did for 0.9.6 and 0.9.7).
>>
>> Maybe we should post the list of proposed deferred JIRA issues for
>> discussion and then move them. I like the idea of defining both a
>> 1.0.1 and 1.1.0 release target to which to defer issues.
>>
>> I think once there is consensus on the non-deferred issues and an
>> identified JIRA owner for them, the release manager can propose
>> when to make a branch. Once the branch is cut, fixes would have to
>> be made in both branch and trunk, so it's not a trivial decision.
>>
>> Maybe a wiki with a table of JIRA issues and proposed target
>> release and some justification (with author's name) would be
>> useful. It's not too hard to set up but still might not be worth
>> the effort.
>>
>> Craig
>>
>> On Jul 9, 2007, at 9:50 AM, Kevin Sutter wrote:
>>
>>>>
>>>> What is remaining to get to a 1.0 release? Are there any
things in
>>>> particular that people think are important to work on? Maybe
it's
>>>> about time for us to create a branch for 1.0 finalization and
>>>> hardening.
>>>
>>>
>>> This probably depends on what our goal is for a 1.0 release. If
>>> it's just
>>> to have a 1.0 release since we graduated to a TLP, then we're
>>> probably close
>>> to starting that process. But, if we are looking for a certain
>>> level and
>>> hardness of function, then we still may have a fews things to
>>> clean up. I'm
>>> okay with going for a 1.0 release just to have one, but I would
>>> then like to
>>> start working on defining the follow-on release (1.0.1 or 1.1).
>>>
>>> No matter what type of 1.0 release we decide to go for, maybe we
>>> should
>>> incorporate the voting mechanism within JIRA to help determine
>>> what Issues
>>> are important? I am not totally familiar with this process, but
>>> it allows
>>> users to vote on the Issues that are most important to them.
>>> Each user is
>>> allowed a certain number of votes (to keep them from voting for
>>> "all"
>>> Issues). We can use that as input to our selection criteria.
>>>
>>> But, before we open up for a vote, do we need some time to review
>>> all of the
>>> open Issues and assert 1.0 vs post-1.0? Something along the
>>> lines of what
>>> Patrick did for the previous release? I just find it kind of
>>> difficult to
>>> be working on various problems and then "ding", the timer goes
>>> off and we've
>>> cut off development for a given release. It's probably time to
>>> start
>>> working out a candidate release cycle and content.
>>>
>>> Kevin
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/
products/
>> jdo
>> 408 276-5638 mailto:[EMAIL PROTECTED]
>> P.S. A good JDO? O, Gasp!
>>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/
jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
