On Jun 11, 2006, at 6:14 PM, Alan D. Cabrera wrote:
Aaron Mulder wrote:
I'd feel a lot better about tight restrictions on 1.1.1 if we really
made 1.2 a "minor release" and put all the stuff on the plate for 1.2
into 2.0. But so long as 1.2 is a major release, then 1.1.1 needs
more than hot fixes. On a related point, I'm not sure we want
multiple big version releases per year.
I agree with you here. The nice thing about the policy that I
outlined below is that we can safely time box patch releases.
As for what gets scheduled for what release, I think that it's not
realistic to start by stacking a release w/ issues and hope that
people will "show up" to get them done in the scheduled time frame;
this only works if we are making shoes ;). With that said, time
boxing is what would work best with our unique body of developers.
Working within the strict interpretation of releases that I
outlined below, people would schedule themselves in with concrete
commitments.
Bugs would not get scheduled in until someone actually picked it up
and started working on it. At that time, the developer would mark
what releases his changes would fix.
Features would not get scheduled in until someone actually commits
to doing that feature.
I like this approach for most things. There will always be the need
to say "x needs to be fixed to ship this release" even if no one is
signed up to work on it. I just wish we'd vote or come to a
consensus on items like these *before* they get assigned to a
release. IMHO, having to +1 it to be added to the release means
among many things you 1) saw it, 2) know about it, 3) are fully aware
of what is outstanding and not yet being worked on, and 4) you agree
with it.
I'm fine voting on blocks of related issues all at once to speed up
the process.
I think having to agree before hand on what goes in and what's
required for a release will force us to talk about things earlier in
the release cycle rather than later.
-David
