[Savannah-dev] Re: phpGroupWare is leaving SourceForge

[Loic Dachary]

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

        An alternative would be to develop or adapt the web interface
to GNATS. Having a mail based bug report system with an added (but not
mandatory) web interface would be good (at least to me ;-). However
this requires a fair amount of work. GNATS is currently migrating from
sourceware.redhat.com to savannah.gnu.org, that may be an oportunity
to engage the dialog with them on this subject.

        Which solution we chose highly depend on how much time/talent
people have to devote to it. If noone is willing to spend a few weeks
on it, I guess using an existing phpGroupWare based bug tracking
system is the solution. We may not have all the functionalities we
dream of (or are used to, which is not the same thing ;-) but it would
be maintained and updated on a regular basis.

        The only necessary adaptation will be to arrange for it to work
in a project oriented way. It basically means that it can be used in
a "narrow" mode, only showing entries belonging to a group (in the
phpGroupWare sense). Since each Savannah project will be identified
by a group, that will allow a user to navigate in the bugs attached to
a project. That also means that all entries created when in "narrow" 
mode should belong to (have a field containing the) matching group.

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

> 2: CVS security - Currently there is very little security of our CVS
> tree. Once granted developer access, a developer can commit changes to
> any file in the entire tree, including the API. Of course we monitor
> changes to the API and all the core apps, but we are human and may
> overlook something that we wouldn't want. With Savannah we will have
> more control over our CVS tree and will be able to have a limited number
> of users be allowed to commit changes to the API and core applications.
> How robust and flexible we will be able to do with better CVS security
> is yet unknown, but even just that one start will be very important. Its
> my hopes that we will be able to have subgroups for each application, so
> that the maintainer of each app will be able to control which of the
> developers has rights to commit changes to his project. Thats the
> ultimate goal, but at this point we are not sure it will be possible
> anytime soon.

        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.

        B) An instance of phpGroupWare tailored to run a Savannah style
           site is installed for phpGroupWare. It's focus will only be to
           host phpGroupWare and phpGroupWare applications. 

           Although I honestly think that's, by far, the most reasonable 
           thing to do, we are not ready technically speaking. Once 
           Savannah runs on the phpGroupWare codebase and uses a 
           format to export/import projects, the migration to this 
           setup will certainly be possible and desirable.

        C) We keep the old way of doing things for now in order to avoid
           the "we want to solve all problems at once" syndrom ;-)

        Cheers,

-- 
Loic   Dachary         http://www.dachary.org/  address@hidden
24 av Secretan         http://www.senga.org/      address@hidden
75019    Paris         T: 33 1 42 45 09 16          address@hidden
        GPG Public Key: http://www.dachary.org/loic/gpg.txt