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.
Based on our past experience over the last two releases and a couple of Milestones we all feel the
urgent need to get things fixed. However, as I was clearing out 1.1 there were lots of assigned
issues with relatively low overhead in applying and verifying them but the assignee was busy with
other things. This is fine.
IMHO JIRA's should not be assigned to a version number until there is someone that will be working
on them. That way we'll end up with things people are planning on completing for a release in the
release. We have had "important bugs" in JIRA (some older than two years).
In short, I think we should try it David.
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.
Yes, it will also have people think about what's important for the release.
One are we need to bone up on is making sure that we look at JIRAs when they come in. There are a
number I moved to 1.1.1 and plan on integrating where people did the work and created a patch. It
will help us grow the community a lot if they see we are attentive to their contributions and that
the contributions actually get in. If the patch won't work, then we need to give them feedback on
what will work. I think this is an ethic change for us.
-David
