phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [phpGroupWare-developers] Organising apps in svn


From: Dave Hall
Subject: Re: [phpGroupWare-developers] Organising apps in svn
Date: Mon, 19 May 2008 22:13:39 +1000

On Mon, 2008-05-19 at 13:17 +0200, Maât wrote:
> Dave Hall a écrit :
> >> 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.
> >   
> Developper tool should be part of core system as it is not really an 
> application but a real part of the framework allowing developers to 
> create applications ( inthe same way special things in setup allow to 
> create tables descriptions

But it is for developers, not people who just want to install and use
phpgw as is.  developer_tools should be a standalone module, it is not
broadly useful.  Also in its current state it isn't useful at all as it
is broken.

> 
> 
> > 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.
> >   
> That's why i insisted on the difference between repos organization and 
> applications statuses... wether an app gets supported or not should not  
> involve  modifications of repositories : history will be painful to 
> follow and big moves in repositories are not recommended

svn log shows histories when svn mv is used.  svn
mv /supported/<module> /orphaned/ is very easy to do.


> Statuses ( core maintained supported and whatever ) should only impact 
> integration in tar.gz flavour packages and be reported on website and 
> download page
> 
> Reflecting global app statuses in svn organization is something i would 
> never recommend.

I think it makes it very clear to people the state of a module before
checking it out.  It also makes it clear to new contributors where to
focus their energies.

Cheers

Dave





reply via email to

[Prev in Thread] Current Thread [Next in Thread]