Hi, I mostly agree with Hoss and Yonik. Use patches, it's easy, trunk doesn't have to be stable, retain the Review Then Commit (RTC) style of development. Keep development fluid, don't gate it with more process than necessary (e.g. major branch merging).
Branches are significantly easier with SVN than they were with CVS, for sure. Even so, I only think they're worth the maintenance and merging hassle for really major things. Of course "really major" is subjectives, so here are some examples. In Tomcat we traditionally made a branch only for major versions of the server (3.x, 4.x, 5.x, 6.x) that implement new versions of the Servlet and JSP specifications. Work is done only on the trunk for many months at a time. In log4j we've never really had concurrent development on multiple branches, work is done in the trunk, just like Lucene. The other incubating projects I'm currently involved with (OFBiz, lokahi, XAP) are the same way as Hoss and Yonik described for Solr. That said, if a developer has a major piece of work he/she wants to work on, and feels uneasy about doing it on trunk, he/she is more than welcome to create and maintain a branch for this purpose. The onus is on him/her to properly merge the work back once there's consensus the branch work should be included in the trunk. So we don't need to be zealous about branches / no branches (and I don't think anyone here is). Yoav On 11/17/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 11/17/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : 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." For changes that a committer feels are obvious or non-contentious (and not likely to be improved by review), I think they should just commit them. We have a review-after-commit policy too. For example, Mike's recent fix of field boosts was an important fix, but simply committing it w/o a JIRA issue was fine IMO. Changes of any nature that are copyrightable (have originality, etc) and come from non-committers should go through JIRA I think (for IP documentation purposes). People should be able to count on the fact that commits without JIRA issues originate from committers only. As far as branches go, I've not used them (because Lucene really hasn't), so I don't have much to go by. I would be concerned about the ability to easily "see" what a patch consists of from a simple link in the JIRA bug though. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server
