Re: [phpGroupWare-developers] Organising apps in svn

[Maât]

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

( 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
         |
        + doc
         |
        + help
         |
        + inc
         |
        + setup
         |
        + templates
         |
        + index.php

for testing purposes we could make nightly generated tarballs including
various applications :

Here are a few examples :
---------------------------------

-- basic flavour : phpGroupWare (as defined above) + email + calendar +
addressbook + notes + messenger

-- project management flavour : phpGroupWare + email + calendar +
addressbook + notes + todo + wiki + bugtracker + ged

-- facilities management flavour : phpGroupWare + property + .... (see
Sigurd for advice)

-- we can imagine other flavours dont limit yourself ;)

and that could be provided with 2 levels :

-- all taken from trunk (with warning)

-- all taken from defined branches (more stable)

these tarball should not be cleaned of svn info (anonymous checkouts) so
that people can use svn checkout.

(We could prevent .svn web accesses with a default .htaccess)

I'll stop there.. that's heavy enough for a single mail :)

greetings,

Maât