Re: The 0.18.0 release and Repository Rules

What do people think about a process like this:

1) Simple, one or two file bug fixes / optimizations go on the main 
branch. This would allow us to make bug fix releases quite rapidly. It 
would also allow feature developers to get the newest bug fixes into 
their branches fairly easily. Developers send me patches for these 
sorts of things for review prior to commit (or just explain the fix to 
me over email).

2) Developers themselves can choose what path to follow for larger bug 
fixes or small features. They can either
	a) Create a branch (or have a branch created for them) and do the bug 
fix / feature enhancement on that branch
	b) Send me patch files for approval then commit directly to main. 
After seeing how effortless the merge from the inline declaration 
branch was I am actually a bigger fan of dealing with branches. But I 
also understand many developers may be uncomfortable with the process 
so I want to leave patch files available as an option.

3) For larger features all work occurs on a branch.

One of the problems I see with lots of work going on on different 
branches is that it means people need to maintain different work areas 
(cvs checkouts of different branches) if they are working on different 
features at once. Often times accidents can happen in situations like 
these (files can be cvs removed from the wrong branch etc...) . At very 
least it is time consuming in terms of what's involved in checking out 
a whole new version of the repository when a second branch must be 
checked out.

Dave

BTW: Does anyone know if its possible to restrict who is allowed to 
commit to a branch in CVS ?

On Friday, January 31, 2003, at 07:21  AM, Stefano Corsi wrote:

>> 1) When and how we should create and distribute patch files
>> 2) Under what circumstances we should create branches in the 
>> repository
>> for in progress features
>> 3) Whether or not bug fix releases should be done on a branch and when
>> that branch should be made
>
> I feel unconfortable with patches because I make a lot of confusion 
> with them,
> and every time the repository changes you have to adjust patches 
> because, as
> far as I know, patches are much less forgiving that CVS merge if there 
> are
> big code changes.
>
> I was thinking of a simple CVS process like this:
>
> 1) The main CVS trunk contains only the latest stable release (let's 
> say as
> for now 0_17_0).
>
> 2) As soon as a new release is released a new bugfix branch is created 
> (ex
> moto_0_18_0_fix) and a new devel branch is created (ex 
> moto_0_19_0_dev).
> Small bug fixes and optimizations go to moto_0_18_0_fix  while new 
> features
> go to moto_0_19_0_dev.
>
> 3) When new features and bug fixing come to a close, we
> 	- FREEZE
> 	- branch tag MAIN with "cvs tag -b moto_0_19_0_pre" and we try merging
> moto_0_19_0_pre with moto_0_18_0_fix  and with moto_0_19_0_dev.
>
> 4) If everything goes well and testing is ok, we merge MAIN with with
> moto_0_18_0_fix  and with moto_0_19_0_dev.
>
> This way we have several advantages:
>
> 1) We keep bug fixing and new features separate.
> 2) We always have a working and stable copy ready to be branched.
> 3) We have two branches (fix and dev) ready for testing before they are
> released.
> 4) We have a "pre" branch ready for testing too, with bugfixes and
> new_features inside.
> 5) We give visitors from outer worlds the impression that there are 
> thousands
> of us out there.
>
> Of course developers could keep a branch for themselves if they are 
> working on
> something that can mess up things for others and merge it back just 
> when they
> are ready to. Then, these private branches could be deleted after 
> merge.
>
> Stefano
>
>
>
>
>
>
>