gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Repository change to SVN, Jan 28th


From: David Ayers
Subject: Re: Repository change to SVN, Jan 28th
Date: Sun, 22 Jan 2006 19:04:16 +0100
User-agent: Mozilla Thunderbird 1.0.2 (X11/20051002)

Sheldon Gill schrieb:
> Fred Kiefer wrote:
> 
>> I also think that with the new possibilities of SVN there come a few
>> more rules that we need to set up and follow. We expect that SVN will
>> make it easier to have multiple branches with actual development going
>> on. Now what will be the rules for merging this branches back into the
>> main trunk? At work we are using ClearCase and have rather complicated
>> procedures that have to be followed to make this step save. Something
>> simpler might be enough for GNUstep. At least all changes from the trunk
>> need to be merged down first, conficts resolved and the code tested.
>> Then a review could happen, before the changes get actually merged.
> 
> 
> Actually, I think Fred has raised a good point here. We do, I think,
> need some clarification about branches and merging back to trunk. A few
> additional rules and guidelines may be useful. I've some questions:
> 
>   - are we going to stick with the SVN recommended 'trunk', 'branch' and
> 'tag'

I would like to see this.

>   - how are branches to be named? What about sub-branches?

I believe there were some suggestions before.  I had no objections but
also no strong feelings.

>   - how are developers going to communicate about branches and what's
> going on in them?

I would suggest the Wiki.

>   - what goes into tag? When?

You mean other than releases?  Well since we have defined repository
states through revision numbers, I can't think of any necessity for more
tags.  It's not like gnustep is seeing the kind of development activity
like, say, GCC.  But maybe you have something specific in mind?

>   - Are we going to import more vendor trees? (like ffcall, portaudio etc)

I think we should keep anything not FSF assigned in a separate
repository so we have clear boundaries from where we can blindly
copy-and-paste code.  Other than that I think there should be a
dedicated maintainer(s) for any external vendor tree who will keep them
up to date.

Cheers,
David




reply via email to

[Prev in Thread] Current Thread [Next in Thread]