Hi, Half-baked things getting into trunk probably won't happen. Lots of people use Solr nightlies (cause they are often stable enough). If we were a bunch paid to work on Solr, then we'd be more organized/structured and have more regular release cycles. Solr is also not likely to have a very short lifetime -- too many people use it, develop for it, and depend on it.
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Andrew Savory <[EMAIL PROTECTED]> > To: solr-dev@lucene.apache.org > Sent: Tuesday, May 20, 2008 3:51:50 PM > Subject: Re: Release of SOLR 1.3 > > Hi Mike, > > On 20/05/2008, Mike Klaas wrote: > > > 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. > > Cool, thanks for that. Indeed, assigning issues to releases should > only be possible by committers. > > > > 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" :) > > Heh. Thankfully many of the patches look well-tested and extremely > well discussed already, so I'd hope they wouldn't require too many > followup issues! > > > > 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. > > I'd tend to disagree: committing the patches to trunk allows > widespread testing and the chance for wider review of the code to see > if it does what it should. Only when the code is part of a release is > there any obligation to a proper lifecycle (ongoing support, > deprecation, then finally removal). > > Of course, being concerned for the state of trunk is a good thing > overall, but it seems from my casual observation that some > contributions that are far from half-baked are not making it into > trunk: this is even worse as it might lead to an unnaturally short > lifetime for Solr. > > > (incidentally, this is the same philosophy we apply at my company, except > > that development is usually done in branches rather than patches.) > > Sure, I'm currently working in a branch-per-feature environment, and > it has some advantages for a corporate environment with no community > concerns. But here we're talking about consensus-driven open > development, for which a more open approach may be appropriate. True, > it may seem chaotic and perhaps a bit risky - but with enough eyes on > the code we can mitigate that risk. > > And hey, if some contributions are really controversial, there's > always the option to do more branches (or even set up a scratchpad). > > Just my €0.02! > > > Andrew. > -- > [EMAIL PROTECTED] / [EMAIL PROTECTED] > http://www.andrewsavory.com/
