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 _______________________________________________ phpGroupWare-developers mailing list phpGroupWare-developers@gnu.org http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
