Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Date: Fri, 17 Nov 2006 10:27:26 -0800 (PST)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: solr-dev@lucene.apache.org
Subject: Re: [RT] working with patches vs. branches?
In-Reply-To: <f767f0600611170223s1fe5acean5b8ca53e6bfc7f01@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0611171000260.30605@hal.rescomp.berkeley.edu>
References: <f767f0600611170223s1fe5acean5b8ca53e6bfc7f01@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


: IIUC the agreed way of working is to do all important changes as
: patches in Jira, discuss them and only commit once we agree on them?

I would rephrase as: "attach to jira, see if any one has
comments/objections and commit once they've had a little time to soak."

: If this is the case (and I agree with the idea of having a stable
: trunk at all times), I'd like to suggest working with SVN branches
: instead - or in addition to this.

1) I don't think the trunk needs to be "stable" at all times -- it should
be the primary dev branch, but "contentious" changes certinaly shouldn't
be commited there.

2) I have no strong opinion about working with branches instead of
patches... my familiarity with branches is solely with CVS, where they are
both costly, and inconvinient -- i'm told both of those issues are
vastly reduced with Subversion.

Some comments/questions/concerns that we might want to consider though...

a) the Lucene community (or from what i've seen personaly: the Lucene Java
community) seems to work mostly with patches instead of branches ...
should that be a factor in a policy decision like this (assuming a goal of
being a "sub community" of Lucene Java) ?

b) ...

: IMHO, the problem with patches is that they tend to be one-man shows:
: patching someone's patch is not convenient, so others tend to just
: comment on them.

I've never really thought of it that way ... patching a patch that is ...
i think people who are actively interested in a patch
and wnat to improve on it would apply it, make their changes, and then
resubmit it (wether the orriginal patch was theirs or not) ... while other
people who are only peripherally interested or don't have the time to
make/text specific changes might only add comments

c) ...

: With SVN branches, several people can go wild in a branch, fixing or
: improving other's stuff at will while it's being worked on. This
: includes non-committers, who can provide patches against the branches
: and get involved on experimental stuff as well. And if a branch takes

While i'm sure the "cross committer" feedback would work well, i'm
a little worried that getting feedback from non-committers would be
harder.  yes they can submit patches against the branch with suggested
improvements, but if they want to try out a "patch" they see in Jira,
there is no trivial way to get the "patch" from Jira ... they would need
to checkout the branch -- and they may not even use Subversion, they might
be someone who just downloads the source builds (or nightlies) that just
wants to try out a change against the code they've already got.

I also think there might be a mental block even for committers to go
commiting to "Joe's branch" ... even if it's not really Joe's branch, it's
the branch for issue#98765 but if Joe is hte guy whose been working like a
dog on it, I dont' know that i'd feel comfortable commiting a bunch of
stuff directly into that branch.

d) ...

: I don't mean to avoid the use of Jira, quite the contrary: branches
: could be named after the Jira issues that they refer to, I think it's
: very important to keep the history of decisions and discussions in
: Jira. But collaborating on *code* in Jira is suboptimal, IMHO.

The Jira/Subversion integration -- while admirable -- tends to be a bit
flaky.  i frequenly notice that the option to see commits related to an
issue disapears from the Jira, making it hard to see what commits have
acctually taken place and when -- not to mention that there is a slight
delay even when it is working perfectly -- this could make discussions
about changes comfusing ... with patches attached ot Jira issues it's
allways clear what's going on and what order things happen in.  with
branches comments would need to specify what subversion r# they are
refering to -- and since revision numbers are global and different r#s
frequently refer to equivilent code images, might still be confusing


...anyway, those are just some of the concerns i'd have about trying an
approach like this ... but as i said, that doesn't mean i'm opposed to it
... just curious as to how it might work out ... do any of you guys who
tend to work on other Apache projects have any insight into wether these
issues actually prove to be a problem in projects that work like this?


-Hoss