On Mon, Sep 22, 2008 at 7:04 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:
> Hey Solr Devs, > > So, 1.3.0 is out. Whew! I think I survived. I hope y'all did too. At > any rate, I promised Lars I would follow up on his comment: > http://lucene.markmail.org/message/ynsnkigymbv7kfqn?q=%5BVOTE%5D+Solr+1%2E3, > so here goes. > Thanks for taking the initiative here, Grant. > > So, what are the lessons learned? What can we do to improve Solr's > process, if any? > > I saw a few pain points that I think are easily addressed: > > 1. IMO, way too long between release of 1.2 and 1.3 (1 year, 3 months). > Yes, releases cause everyone to pause and take stock, but they are > worthwhile, and not just technically. Many users only use releases. Many > people don't notice a project except when they see it via some PR. > Releasing more often can help attract more contributors/users which should > lead to a better Solr. Additionally, I imagine some people upgrading from > 1.2 to 1.3 are trying to swallow a pretty big pill of features. Granted, > things should be back-compat, but even that is hard to track when something > is a 1+ year ago. I'd suggest we shoot for every 6 mos. or so, and maybe > even some bug fix releases more often. > I'd love to see more frequent releases and I'm more than happy to work towards that. I'd prefer if we put an upper bound to releases rather than a strict interval. As Jason suggested, we should plan releases according to features. Consider replication (SOLR-561), it is getting near to a fully baked patch and it'd be nice to make it available to users much before six months. 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). The above strategy will ensure that we stay nimble and do frequent releases without putting a lot of pressure on committers or the release manager. Stable trunk features will not starve and large features will not delay releases indefinitely. We will have an upper bound on release dates as well as the flexibility to release when the community feels confident. Let us mark large features and core changes appropriately, creating additional versions in Jira as and when applicable. We always have the flexibility to promote features to earlier release versions if we feel it is getting matured enough. Thoughts? > > 2. Last minute changes. The mutlicore changes 1 week before release were > pretty tough to swallow. Great job to those involved who took it on, but > still, let's not do that again, eh? One _suggestion_ is that we try to > front-load big features. Hard to do, but maybe the other approach is that > if we are about to take on a big new feature, we consider what other big new > features are already in Solr and then maybe consider publishing them first > and holding off for the next version the new feature. Another possibility > on this is a slight relaxation in back-compatibility "policy" in that for > big features, we reserve the right to alter them in a build version release. > The main thing that this addresses is a lot of people feel uncomfortable on > trunk, so maybe it's a way of getting more eyeballs. Of course, we do this > already to some extent when we mark things as experimental, so maybe nothing > to change here. Just thinking out loud. +1 to avoid last minute changes. At one point, it seemed like we'll never release 1.3 > > > 3. We need to keep better track of NOTICEs, headers and library stuff. > Yonik and others did a lot to get these up to date again. I know I'm > especially guilty of forgetting to put headers on. You can now run ant > rat-sources for help in identifying offending files. > I too am guilty on this front going as far as suggesting to release with the stax libs unchanged. I promise to pay closer attention to these aspects. -- Regards, Shalin Shekhar Mangar.
