Re: [phpGroupWare-developers] Organising apps in svn

[Dave Hall]

On Mon, 2008-05-05 at 12:04 +0200, Maât wrote:
> Olivier Berger a écrit :
> > Le vendredi 02 mai 2008 à 15:51 +0200, Sigurd Nes a écrit :
> >   
> >
> >   
> >> There has been som mention of grouping apps into something as:
> >> * Core - the core modules which should be installed for all installs
> >> * Maintained - actively maintained and developed modules
> >> * supported - gets security and critical bug fixes
> >> * Orphaned - use at own risk
> >>
> >> I think this is a good structure - and if others also others agree on this 
> >> one - we should decide upon which apps falls into which group.
> >>
> >> trunk and future versions
> >>
> >> Regards
> >>
> >> Sigurd
> >>     
> >
> > Just a quick comment (from a third party ;).
> >
> > I seem to recall that "core" was mentioned previously as being the set
> > of "core groupware applications" that make phpgroupware a groupware
> > solution.
> >
> > So maybe it does mean email + calendar + addressbook, etc., and not just
> > the api + complementary libs that other modules need for running/
> >
> > In what you describe, I believe the categorization is drawn more with
> > respect to QA (maintainability status), rather than features... but I'm
> > not sure I got it right.
> >
> > Is this what you were thinking of ?
> >
> > Best regards,
> >   
> Hi,
> 
> I think we want to consider these things are different (but connected) :
> 
> -- svn organization
> -- applications statuses
> 
> svn organization should help make coding and versions management clean
> and as easy as possible
> 
> applications statuses (wether core or standard or maintained or third
> party and unmaintained) should be used to define what we put in
> phpGroupWare tarball (light, complete and perhaps various flavours (
> like project management, community communications... )
> 
> The first idea was to have a minimal phpGroupWare ready to run with only
> one checkout instead of many :
> 
> phpgroupware then inside it :
> -- admin
> -- developer_tools
> -- phpgwapi
> -- preferences
> -- setup
> -- and perhaps other low level things ( to check : syncml xmlrpc soap
> and things like that)
> 
> with just one svn checkout we should be able to have a ready to run
> phpgroupware... the user must be able to install it and log in it
> without the slightest problem.
> 
> for applications (even core ones) there is something we need to think :
> phpGroupWare has been thought to host various versions of applications
> (even calendar, addressbook and email) so i think the logical cut is there :
> 
> in savannah phpgroupware svn "root" ( for example
> http://svn.savannah.gnu.org/viewvc/trunk/?root=phpgroupware but tha
> would be more clean to see it right at  the upper level )
> 
> i would see a phpgroupware directory with :
> 
> phpgroupware
>   |
>  +-- branches
>   |
>  +-- tags
>   |
>  +-- trunk
>          |
>         + admin
>          |
>         + developer_tools
>          |
>         + doc
>          |
>         + phpgwapi
>          |
>         + preferences
>          |
>         + setup
>          |
>         + README.NOW-IMPORTANT
>          |
>         + about.php
>          |
>         + ...
>          |
>         + xmlrpc.php


Developer tools doesn't really belong here.  Also the core modules will
need to go here.

> ( I would also recommand to move all docs concerning all this into doc
> root dir here above)
> 
> then for each application i'd rather se it appear aside phpgroupware dir
> with the following structure :
> 
> application
>   |
>  +-- branches
>   |
>  +-- tags
>   |
>  +-- trunk

There should also be a higher level, 

 * core (which is what is outlined above)
 * maintained (actively maintained modules - nothing at this stage),   
 * supported (security support only - all modules atm)
 * orphaned (everything currenyly under old)

Modules can be moved from supported to maintained once they are audited
and meet agreed release/security criteria.

Cheers

Dave