Re: [Phpgroupware-developers] Re: phpGroupWare is leaving SourceForge

[Joseph Engo]

Wheew ... its nice to be able to hit reply and have it go directly to the
list again :)

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

This is more or less what I have been doing.  I am tring to match of TTS app
to SFs as much as possiable, and adding new features to it.

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

I will take a look at it.

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

Sure, for the mean time we could.  But, I am not sure it would actually work
for what we want to do.  Its not currently built for multi-group access. 
This is why I have been working on it recently.  That and I want to make it
work with the client side app, which is work in progress.

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

There should be a system wide feature to only show records belonging to your
group, or the group you are viewing.  Of course, ACL defining what you can
and can't do.

BTW, is Savannah using MySQL or PostgreSQL ?

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

If it gets over 256 applications .... we have a problem :)  Seriously, I
doubt this will happen within the next few years.

>       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 ;-)

I am not sure which method to use currently.  Anyone else ?

Joseph Engo