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!
