Aidan Skinner wrote:
On Fri, Jun 13, 2008 at 4:00 PM, Carl Trieloff <[EMAIL PROTECTED]> wrote:
I have updated with what we have done so far, and a good part is completed.
Can we hash out on this thread and
get M3 more concrete. i.e. are we going to wait for Ruby to support 0-10
before we cut M3, or will we be willing
to cut it with Java, JMS, C++ and .NET clients?
We've previously agreed to do time-boxed releases, which I think is
pretty crucial. We've kind of let it slip recently, but I think
getting an M3 out at an agreed point in time, with clearly defined
feature, bug fix and hard freezes is a better tack to take than trying
to define M3 by features.
Having said that, by the previous timelines agreed we'd be entering
feature freeze right about now, and releasing in a little over a month
by my reckoning, which is clearly not going to happen.
Time box is good/better. The trunk is quite good currently. If we take
this route
do we want to declare trunk open for say 4 more weeks, than we call that
the freeze
date for M3? 4 weeks being a random number I pulled from the air.
Thoughts.
Well, lets just say it needs some clean-up. I can identify a bunch of stuff
that has been done but is not closed etc. We should
maybe setup a call, or tag team the list of items and make sure we have what
we want in the list for M3, and close out the
crud.
Cleaning up Jira is definately something we need to do, it's the
proverbial den of scum and villany atm. As I said above though, I'm
resistant to defining M3 as a feature list. There's some stuff which
is currently targetted for it which is just unrealistic, but I'd
rather do something like:
1. agree dates and designate a release manager
2. move stuff which is just not going to make it out of M3
3. hack
------ Feature freeze ---- (Release - 6 weeks?)
4. move features which haven't made it into the future
5. fix bugs
---- Fix freeze ---- (Release - 2 weeks?)
6. move non-critical fixes into the future
7. fix the critical things
--- Release --- (Release)
Sounds good. I would however like to clean JIRA up a bit regardless to
make it easier for
those new on the project.
Carl.
