lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: Patches in jira
Date Wed, 20 Dec 2006 23:17:11 GMT

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
...

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


Mime
View raw message