I'll take the contrib/ issue if nobody else does. I would want to see that one in 1.3, so we can get DataImportHandler in.
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Shalin Shekhar Mangar <[EMAIL PROTECTED]> > To: solr-dev@lucene.apache.org > Sent: Tuesday, May 20, 2008 3:32:21 PM > Subject: Re: Release of SOLR 1.3 > > +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 wrote: > > > > > On 20-May-08, at 1:53 AM, Andrew Savory wrote: > > > >> 2008/5/19 Chris Hostetter : > >> > >> 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.
