[Savannah-dev] Re: [phpGroupWare-developers] THIS LIST HAS MOVED. Visit http://savannah.gnu.org/mail/?group_id=509Re: phpGroupWare is leaving SourceForge

[Dan Kuykendall (Seek3r)]

Loic Dachary wrote:
> 
> [Followup to 
> http://mail.gnu.org/pipermail/phpgroupware-developers/2001-November/000002.html]
> 
> > Phase 3: Bug tracking/Patch Manager
> >    This is a big one. We are able to export the data from SourceForge,
> > but don't yet have the ability to import this into our Savannah project.
> > I will be working with Loic (the Savannah adman) on this issue. Once we
> > are able to import our data we will make the migration
> 
>         This is going to be some work, yes. The ideal situation would
> be to use a good bug tracking system ported to phpGroupWare. One could
> dream that the SF tracker would be ported to phpGroupWare but, as always,
> the porter would be a little worried by the fact that there is no planned
> releases at the horizon.

Maybe DCL can fit in here. there is a version of DCL which uses the
phpgwAPI, and DCL is a very nice bug tracking program. We could also use
our existing trouble ticket system which jengo has recently re-written.
The benfit of using the phpgw TTS is that jengo has already started work
on the xml-rpc client for it. This means that a user can use a
non-webbased interface for dealing with the bug trackingt system. I know
I for one would love to be able to use a normal client app from time to
time, instead of always being forced to use my browser.

> > Phase 4: CVS
> >    Another big task. Actually the technical side it quite easy. We
> > simply grab our cvs repository from SourceForge and drop it onto the
> > Savannah cvs server. The real problem is that this will mean that
> > everyone will either need to do a fresh checkout, or we need to figure
> > out how to edit the files in the CVS folders so that we can point it to
> > the new location. So this is not a technical problem, just a hassle for
> > the users and developers who checkout from CVS.
> 
>         A simple perl script to replace strings in the CVS/Repository
> and CVS/Root files is enough. There is no need to do a fresh checkout.

I figured as much, but wasnt sure.

> > 2: CVS security - 
>
>         There are a few solutions to this problem.
> 
>         A) We could define phpGroupWare as a "meta project" in the same
>            sense as http://savannah.gnu.org/projects/www/ is a "meta project".
> 
>            Other applications are just regular projects but their names all
>            start with phpgw-<application>
> 
>            In this special case the backend will grant them a subdirectory
>            of the phpGroupWare CVS tree instead of a brand new one.
> 
>            All members of the phpGroupWare project will have
>            read/write access to the CVS tree of the applications but
>            members of the application projects will only have write
>            access to their CVS tree.
> 
>            That system works fairly well although it tends to grow the
>            number of groups someone belongs to and breaks system limits.
>            As long as the number of phpgw applications is reasonable
>            (< 256) that won't be an issue.

I like option A for this. I think it will work out pretty well.

Seek3r