I guess I went a bit overboard with the plan :-) Yes, I agree about the point on hard deadlines. However, I do feel that marking an issue to the next immediate release should represent a priority to the issue from us. The core of my suggestion is continuous release planning to ensure releasing early and releasing often. It is also an incentive to scope issues appropriately.
On Tue, Sep 23, 2008 at 12:08 AM, Otis Gospodnetic < [EMAIL PROTECTED]> wrote: > I agree with Mike. The simpler you make it the higher the chances of the > plan being followed. I had to re-read the part about un-released versions. > Moreover, rigid rules work great when people doing the work can really > spend quality time on the project. This means that people working on Solr > through/for their work are really the people who could stick to the plan and > everyone else will do whatever is possible for that individual at a time. > Hadoop is a good example, and with a couple of people working on Solr > full-time now, more structured approach might be possible. That said, I'd > be careful of not making things too "work-like" (deadlines, committments, > etc.) or else you risk losing people who have enough deadlines and other > pressures already. > > I'm not sure about that experimental vs. stable release suggestion - I > think it can be as simple as "treat the trunk as experimental/in > development" (which it is!) and only releases are stable. In other words, > no need to change anything there IMHO. > > Otis > > > > > ----- Original Message ---- > > From: Mike Klaas <[EMAIL PROTECTED]> > > To: solr-dev@lucene.apache.org > > Sent: Monday, September 22, 2008 1:40:59 PM > > Subject: Re: Solr 1.3.0 Release Lessons Learned > > > > > > On 22-Sep-08, at 10:34 AM, Shalin Shekhar Mangar wrote: > > > > > > I'd like to propose a more pro-active approach to release planning > > > by the > > > community. At any given time, let's have two versions in JIRA. Only > > > those > > > issues which a committer has assigned to himself should be in the > > > first > > > un-released version. All unassigned issues must be kept in the second > > > un-released version. If a committer assigns and promotes an issue to > > > the > > > first un-released version, he should feel confident enough to > > > resolve the > > > issue one way or another within 3 months of the last release else he > > > should > > > mark it for the second version. At any given time, anybody can call > > > a vote > > > on releasing with the trunk features. If we feel confident enough > > > and the > > > list of resolved issues substantial enough, we can work according to > > > our > > > current way of release planning (deferring open issues, creating a > > > branch, > > > prioritizing bugs, putting up an RC and then release). > > > > I think that this is the right approach, but I don't think that it > > needs to be that complicated. For issues without the "expectation of > > completion" that you mention, it is fine to just not assign a version > > to the issue. It _would_ be useful, OTOH, to have a 2.0 version in > > JIRA for issues we know won't be resolved back-compatibly. > > > > -Mike > > -- Regards, Shalin Shekhar Mangar.
