move to sourceforge.net?

move to sourceforge.net?

[Adam Spiers]

Hi all,

I've just registered a new account at sourceforge.net and had a peek
around.  It all looks very tasty, and seems to me to be the ideal
place to relocate the CVS repository.  Since I'm totally out of sync
with patches at the moment, but have a bit of free time for once, I'd
like to help get this going quickly.  Are there any objections to this
move, and if not, would I be helping or just getting in the way by
registering zsh as a project on sourceforge?

Adam

Re: move to sourceforge.net?

[Adam Spiers]

Forgot to say, the sourceforge CompileFarm is now available for
general use, so if we did move to sourceforge, we'd get automated
build tests for several Linux- and BSD-based distributions.

http://www.newsalert.com/bin/story?StoryId=Comsm0bKbytaWodG

The Patch Manager and Support Manager also mentioned in that URL sound
quite promising.

Adam

Re: move to sourceforge.net?

[Oliver Kiddle]

Adam Spiers wrote:

> I've just registered a new account at sourceforge.net and had a peek
> around.  It all looks very tasty, and seems to me to be the ideal
> place to relocate the CVS repository.  Since I'm totally out of sync
> with patches at the moment, but have a bit of free time for once, I'd
> like to help get this going quickly.  Are there any objections to this
> move, and if not, would I be helping or just getting in the way by
> registering zsh as a project on sourceforge?

I'd vote in favour of going ahead with this. Sourceforge probably has a
better chance of remaining around compared to any of our own machines we
might run a public CVS on. I had a look around their site earlier this
week and also concluded that it seems quite good. We could also look
into using their bug-tracking system.

Who is currently in charge of maintaining the web pages? They don't seem
to have been updated since last summer and the news page doesn't even
mention the 3.0.7 release. I'd be happy to take over doing the web pages
if everyone's happy with that and if they aren't being done by anyone
else.

Oliver Kiddle

Re: move to sourceforge.net?

[Bart Schaefer]

On Mar 10,  4:32pm, Adam Spiers wrote:
} Subject: move to sourceforge.net?
}
} Are there any objections to this move, and if not, would I be helping
} or just getting in the way by registering zsh as a project on
} sourceforge?

You can answer some questions about sourceforge that I haven't had a
chance to investigate yet: 

Can the repository be made read-only except by some limited group of
administrators?

Can we copy over Tanaka's existing repository in its entirety, without
losing any of the change history?  (I hope it's still available with
cvsupd or whatever that's called; but I don't know what that's capable
of exporting nor what sourceforge is capable of importing.)

Can we set up any of our own patch management tools, e.g. Tanaka's
scripts for applying patches from the mailing list and then running
"cvs import"?

If not, do they have an equivalent?  (Patch Manager doesn't sound like
it has that as a function, from a quick look at that press release.)

If there is nothing of the kind, what do the administrators have to do?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: move to sourceforge.net?

[Adam Spiers]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> You can answer some questions about sourceforge that I haven't had a
> chance to investigate yet: 
> 
> Can the repository be made read-only except by some limited group of
> administrators?

Yes.  The CVS tree is available read-only to anyone, but project
administrators can designate certain users as developers, which gives
them write access.

http://sfdocs.sourceforge.net/sfdocs/site/project-adminusers.php says:

--------- 8< --------- 8< --------- 8< --------- 8< --------- 8< ---------
Site Documentation - Administering Developers for Your Project 

One of the most important and powerful features of the SourceForge
Team Development Environment is web-based user administration.
As a project admin, you have complete control over developer
permissions in the bug tracker, message forums, and task manager. 

At this time, all developers have write access to the CVS Repository
and to your group directory (web site). There are plans to make
these permissions optional as well.
--------- 8< --------- 8< --------- 8< --------- 8< --------- 8< ---------


> Can we copy over Tanaka's existing repository in its entirety, without
> losing any of the change history?  (I hope it's still available with
> cvsupd or whatever that's called; but I don't know what that's capable
> of exporting nor what sourceforge is capable of importing.)

Yep.  From the FAQ:
(https://sourceforge.net/docs/site/faq.php#whyhost-cvs)

--------- 8< --------- 8< --------- 8< --------- 8< --------- 8< ---------
I already have a cvs tree. Can you import it?

Yes. Register a new project normally and let us know you need to
import a CVS tree. We'll need a tar/gzip of your entire document root,
including CVSROOT directory. This will preserve your revision history.
--------- 8< --------- 8< --------- 8< --------- 8< --------- 8< ---------

Daily snapshots of the tree automatically become available
(http://sfdocs.sourceforge.net/sfdocs/site/cvs.php)


> Can we set up any of our own patch management tools, e.g. Tanaka's
> scripts for applying patches from the mailing list and then running
> "cvs import"?

Hmm.  I suspect that I don't entirely understand everything that's
involved in Tanaka's scripts.  cvs write access operates in the normal
way, with CVS_RSH=ssh, so I can't see anything stopping a developer
from using whichever patch management tools he wants on his machine
for grabbing patches from the list prior to committing them to the
tree on sourceforge.  However, if we're talking about a situation
where there are two repositories -- the one on sourceforge and the one
on the patch coordinator's machine -- then it looks like he wouldn't
be able to do regular cvs imports into the sourceforge tree, since the
FAQ snippet above suggests that cvs imports can only be done from
tarballs.  Was that what you had in mind?

If the mailing lists were to be moved to sourceforge too then maybe
the patch incorporation process could be made pretty slick.
Developers also have full shell access via ssh to the project account,
so I guess that integrating sourceforge's Patch Manager (which looks
pretty nice incidentally) with Tanaka's tools would be possible too.

Adam

Re: move to sourceforge.net?

[Brian Boonstra]

Sorry for hopping into this a little late, but I noticed...

Adam wrote:
> it looks like he wouldn't
> be able to do regular cvs imports into the sourceforge tree, since the
> FAQ snippet above suggests that cvs imports can only be done from
> tarballs


I use SourceForge for maintaining documentation on the Linux Router Project.  
 CVS imports can be done the usual way...I believe the tarball offer is  
necessary only for purposes of

     - convenience to newcomers
     - preserving revision history


          - Brian
	  brianboonstra@sourceforge.net

Re: move to sourceforge.net?

[Bruce Stephens]

"Bart Schaefer" <schaefer@candle.brasslantern.com> writes:

> You can answer some questions about sourceforge that I haven't had a
> chance to investigate yet: 
> 
> Can the repository be made read-only except by some limited group of
> administrators?

Yes.

> Can we copy over Tanaka's existing repository in its entirety, without
> losing any of the change history?  (I hope it's still available with
> cvsupd or whatever that's called; but I don't know what that's capable
> of exporting nor what sourceforge is capable of importing.)

Yes.  What we need is a copy of the repository (complete with
CVSROOT).  cvsup can export that.

> Can we set up any of our own patch management tools, e.g. Tanaka's
> scripts for applying patches from the mailing list and then running
> "cvs import"?

Probably negotiable.  If I've got CVS read access to the repository,
then I'd rather people checked patches directly to it (that way
they're more likely to provide meaningful RCS logs, which I'd guess
Tanaka's scripts can't?).

Then the issue is whether the core developers can use CVS over ssh,
and what to do with random people who have patches (even I provided a
tiny one, once, though it's gone long ago).  I'd guess the former is
not a problem, and that the latter can be dealt with using the patch
manager.  

I could be quite wrong, though.  I have the impression that special
things like this can be negotiated; perhaps someone could ask if this
really is desirable.