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: Sheldon Gill
Subject: Re: Repository change to SVN, Jan 28th
Date: Mon, 23 Jan 2006 22:26:11 +0800
User-agent: Thunderbird 1.5 (Windows/20051201)

David Ayers wrote:
Sheldon Gill schrieb:
David Ayers wrote:

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?

Main releases are obvious. I'm wondering about branch snapshots.

Not sure why you'd want a snapshot of a branch unless your releasing
from branch (as in dedicated release branches with bugfix releases à la
GCC).

I was thinking of two things here:
One is branch releases where a branch is somewhat experimental. This would help with testing and review.
The other is bugfix releases, ala GCC.

  - 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.

I'm not sure we need a separate repository. Wouldn't a vendor directory
tree would make the boundary equally clear?
Other than that, I'm in agreement with this.


IMO the copyright assignment boundary should be pretty clear especially
if we have all projects at top level as was originally proposed, IIRC.
I'm still in favor of a separate repository, but that's just my opinion.

Same or separate, as long as the boundary and use is clear. I wasn't thinking of having vendor items mixed in at the top level with the rest of GNUstep items. Rather a separate directory, so it's apparent they are in the Vendor tree. (Or whatever we choose to call it)


Regards,
Sheldon





reply via email to

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