Hi Mike, On 20/05/2008, Mike Klaas <[EMAIL PROTECTED]> 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/
