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
