I noticed many issues in the jira that are patches but never got
There are some problems in keeping patches for longer time in the issue
- diff not valid against trunk anymore
- patch grow multiple version and packages which makes it harder to
- person who submitted the patch is not around anymore and cannot give
feedback about her submission
- duplicating issues by other patches doing similar things
- emerging merging problems between this duplicating issues
I noticed that we do not have a sandbox (or incubator) directory for new
components that need:
- more documentation
- more testing/feedback
- more community support
- more ...
Maybe it would be a good idea to add new stuff in our own internal
incubator and as soon we think it is ready to add it to the core.
The benefit over jira is that other people (besides the original author)
can easily submit patches (based on the work of the original patch
author) against our incubator svn.
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Thorsten: you may want to review some recent discussion about this issue
on both solr-dev (specificly the merrits of making branchs vs keeping
patches in Jira) and a related discussion on java-dev@lucene (which i
bring up only because Doug's comments there reflect my own opinions about
"So I'd vote to wait until patch-based development of this becomes
awkward before branching. If several committers want to contribute to
this patch, and their changes are difficult to integrate, then we
should consider a branch."
--Doug in the flexible indexing thread.
In a nut shell: we haven't really run into any problems or frustrations
using Jira and patches, so there's not really a strong motivation to
migrate to a different development approach
Regarding some of your specific comments...
: I noticed many issues in the jira that are patches but never got
In some cases this is just because of time constraints, in others it may
because none of hte committers feel confident enough in the patch to take
responsibility for it (see the Java Lucene FAQ for a nice comment on
this). In other cases (SOLR-53 and SOLR-14 for example) the patch as
currently available doesn't work in all cases and would need a motivated
community member to do further work on it before it would be safe to
: I noticed that we do not have a sandbox (or incubator) directory for new
: components that need:
: - more documentation
: - more testing/feedback
: - more community support
: - more ...
: Maybe it would be a good idea to add new stuff in our own internal
: incubator and as soon we think it is ready to add it to the core.
I'm not understanding this idea ... how would you commit a patch that may
need to modify a core piece of code into a "contrib" area of our
: The benefit over jira is that other people (besides the original author)
: can easily submit patches (based on the work of the original patch
: author) against our incubator svn.
I don't really understand how that might be better (or easier) then having
people apply a patch from Jira, making their modifications, and submitting
the modified patch back to Jira.
Not to mention: we can't competley open Subversion up so that anyone can
commit to it -- so we will always need patches in Jira as a way for
community members to submit proposed changes. if we tried to commit
*every* patch into a a branch, or contrib area of the subversion
repository I suspect the committers could find themselves bogged down very