Re: Identifying apps stati - Was: Re: [phpGroupWare-developers] Status of the Debian packaging of phpGroupware

[Dave Hall]

On Fri, 2008-02-22 at 09:52 +0100, Olivier Berger wrote:
> Le jeudi 21 février 2008 à 12:35 -0600, Chris Weiss a écrit :
> > On Thu, Feb 21, 2008 at 2:11 PM, Sigurd Nes <address@hidden> wrote:
> > > Olivier Berger wrote:
> > >  > Of course, in Core, I would see phpgwapi, setup, admin and preferences.
> > >  >
> > >  > For Maintained, the fewer we have, the better (Debian
> > >  > packaging-wise ;) ?
> > >  >
> > >
> > >  For 0.9.18 I would really appreciate to have at least 'addressbook', 
> > > 'calendar', 'ged', 'hrm', 'manual', 'projects', 'property' and 'sms' in 
> > > Maintained.
> > >
> > >  'syncml' might go in core ?
> > >
> > >  'email' / 'felamimail' ?
> > 
> > historically, addressbook, calendar, notes, and email are core.  the
> > reason is that without them it's not much of a "groupware"
> > 
> 
> OK, then I'd like to propose the following packaging for Debian :
> 
> phpgroupware = phpgroupware-core + addressbook, calendar, notes, and email
> where :
> phpgroupware-core = phpgwapi, setup, admin and preferences
> 

I think the debian packaging should reflect the upstream packaging,
which is changing for 0.9.18

We will have phpgroupware-core:

* phpgwapi
* setup
* admin
* preferences
* manual - most likely
* addressbook
* calendar
* 1 email module - TBA which one
* filemanager
* notes
* todo

Then there will individual tarballs for each of the maintained and
supported modules.  These would be released on a different release cycle
to the core.

The plan for 0.9.18 goes something like this

The core is released, with bug and security fixes as needed.

The non core modules will have a regular release window to release as
part of a proper release push from the project.  So for example. there
are some bugs in a module the developer can push a . release.  Or if
they have a stack of new features, push a new major revision, without
having to wait for a new core release.

> Then there would be the option of installing only the 'application
> server', i.e. only an empty placefolder to add custom applications, by
> installing phpgroupware-core.

For 0.9.18 to really be functional you will need phpgroupware-core as
outlined above.

> But one could for instance also install 'phpgroupware', which would
> install the basic groupware apps.
> 
> phpgroupware-core would recommend phpgroupware, but without making it
> mandatory.
> 
> This should help have something more manageable for the packager, in
> case of security issues on the API+stuff without caring for maintenance
> of the rest of the individual apps, IMHO.

As it is all being packaged anyway, I don't think it makes much difference.

> One consequence is that we may base the packaging on two different set
> of source packages, : phpgroupware-core and phpgroupware-groupware-apps
> (or any other name meaning : addressbook, calendar, notes, and email)
> maybe, in which we woud have splitted your sources. This would help
> manage the security fix releases on one of each packages independently,
> maybe.

I would need to check the debian packaging guidelines, but AFAIK, if
packages are all derived from the same upstream source (such as the
official core tar/bz/zip ball) they would all be built from the same
source in debian, so it wouldn't really change things in terms of
security released for debian.  Look at X Windows, one typo change in the
source debian/ the whole package needs to be rebuilt. :)

Cheers

Dave