PROPOSAL: experimental work in trunk

[Daniel Quinlan <qu...@pathname.com>]

I propose we keep any change that might break the trunk longer than an
hour in a separate branch as long as necessary.

How do you do that?

  svn copy -m "creating temporary branch for foo project" \
    $repo/trunk \
    $repo/branches/<name>/

where <name> is "exp-projectname" or "exp-username".  And after merging
the project, the project should be svn deleted.

An alternative is to create a bug and get review prior to committing
your large change.

+1 to make this policy.

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

Re: PROPOSAL: experimental work in trunk

[Daniel Quinlan <qu...@pathname.com>]

Theo Van Dinter <fe...@kluge.net> writes:

> Can you better define "might break the trunk"?  Technically any change
> could break trunk, but I think you're specifically talking about "complex"
> changes since you mentioned "large change".  I'd feel better if that
> were quantified, and want to make sure it's clear that not every change
> needs a branch (since every change might break trunk).
> 
> If you are talking about a "complex" change requiring a branch for
> testing/etc before "svn merge", then +1.  :)
> 
> /me has this pet peeve about vagueness in policies

Some examples:

  * rewriting message parsing code at start of 3.0.
  * past configuration code rewrite
  * planned rewrite of 3.1 PerMsgStatus
  * planned plugin-izing of Bayes

Not sure exactly how to phrase it, but it's a judgement/social thing.
Basically, we're saying "branches for experimental stuff are open for
business" and their usage is encouraged.  Remember, someone can always
veto your huge code change if it's not deemed as ready.

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

Re: PROPOSAL: experimental work in trunk

[Theo Van Dinter <fe...@kluge.net>]

On Sat, Jul 23, 2005 at 03:32:08PM -0700, Dan Quinlan wrote:
> I propose we keep any change that might break the trunk longer than an
> hour in a separate branch as long as necessary.
> 
> An alternative is to create a bug and get review prior to committing
> your large change.
> 
> +1 to make this policy.

Can you better define "might break the trunk"?  Technically any change
could break trunk, but I think you're specifically talking about "complex"
changes since you mentioned "large change".  I'd feel better if that
were quantified, and want to make sure it's clear that not every change
needs a branch (since every change might break trunk).

If you are talking about a "complex" change requiring a branch for testing/etc
before "svn merge", then +1.  :)

/me has this pet peeve about vagueness in policies

-- 
Randomly Generated Tagline:
Now, son, you don't want to drink beer.  That's for daddys, and kids with
 fake IDs.
 
 		-- Homer Simpson
 		   The Springfield Files