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
