David Blevins wrote:
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.
We are a group of individuals who work on a voluntary basis. Assigning
issues to a release amounts to wishful thinking; just look at the
version ping pong that Matt and Aaron play for our releases.
IMO, voting can easily be accomplished w/ Jira voting.
I'm fine voting on blocks of related issues all at once to speed up
the process.
Not sure that's necessary if we use Jira voting.
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.
So would lobbying for votes for your favorite issues.
Regards,
Alan
