+1 for your suggestions Mike. I'd like to see a few of the smaller issues get committed in 1.3 such as SOLR-256 (JMX), SOLR-536 (binding for SolrJ), SOLR-430 (SpellChecker support in SolrJ) etc. Also, SOLR-561 (replication by Solr) would be really cool to have in the next release. Noble and I are working on it and plan to give a patch soon.
Mike -- you removed SOLR-563 (Contrib area for Solr) from 1.3 but it is a dependency for SOLR-469 (DataImportHandler) as it was decided to have DataImportHandler as a contrib project. It would also be good to have a rough release roadmaps to work against. Can fixed release cycle (say every 6 months) work for Solr? On Wed, May 21, 2008 at 12:45 AM, Mike Klaas <[EMAIL PROTECTED]> wrote: > > On 20-May-08, at 1:53 AM, Andrew Savory wrote: > >> 2008/5/19 Chris Hostetter <[EMAIL PROTECTED]>: >> >> If people are particularly eager to see a 1.3 release, the best thing to >>> do is subscribe to solr-dev and start a dialog there about what issues >>> people thing are "show stopers" for 1.3 and what assistance the various >>> people working on those issues can use. >>> >> >> So, what are the show stoppers, how can we help, what can we reassign >> to a future release? >> > > I've gone and reassigned a bunch of issues that were labeled "1.3" by the > original submitter, if the submitter is not a committer (perhaps this field > shouldn't be editable by everyone). That still leaves many issues, several > of which I don't think are critical for 1.3. > > I propose that we follow an "ownership" process for getting this release > out the door: we give committers a week to fill in the "assigned to" field > in JIRA for the 1.3 issues. Any issue that isn't assigned after one week > gets moved to a future release. Then we can each evaluate the issues we are > responsible for. > > Any non-1.3-marked issues should be added at this time too. > > Taking a look through the list there's quite a few issues with patches >> attached that aren't applied yet. Clearing these out would cut the >> open bug count by almost half: >> > > But then we'd have to open bug reports for each one that says "make sure > this actually works and that it is the correct direction for Solr" :) > > It's a little weird to see patch 'development' going on in JIRA >> (sometimes for over a year), rather than getting the patches into svn >> and then working there... I'd worry that some valuable code history is >> getting lost along the way? Yes, it's a tough call between adding >> 'bad' code and waiting for the perfect patch, but bad code creates >> healthy communities and is better than no code :-) >> > > Committing the code to trunk creates a path dependence and responsibility > for maintaining the code. There would also be a high probability of trunk > never being in a releasable state, given the chance of there being a > half-baked idea in trunk that we don't want to be bound to for the rest of > Solr's lifetime. > > (incidentally, this is the same philosophy we apply at my company, except > that development is usually done in branches rather than patches.) > > -Mike > -- Regards, Shalin Shekhar Mangar.
