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 [EMAIL PROTECTED] (which i bring up only because Doug's comments there reflect my own opinions about ...
http://www.nabble.com/-RT--working-with-patches-vs.-branches--tf2650655.html#a7396998 http://www.nabble.com/branches-and-flexible-indexing-tf2805284.html#a7837263 "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 : committed. 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 commit. : 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 subversion tree? : 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 easily. -Hoss
