Post by Dave HallSent: 2009-10-06 08:22:41 CEST
Subject: Re: [phpGroupWare coordinators] Goodbye
Hi all,
My preference at this point would be to shut down the project. It seems
like the codebase is just too outdated. Maybe at somepoint it would be
worth picking up and starting from scratch with all thats been learned
both in phpGW and across all the various projects in the open source
community these last 9+ years.
Anyways, if a clear vision can be had and a developer to continue it is
around, then please contact me... otherwise a leaderless project is a
dead one.
Dan
Hi all,
I have plans for it and want to keep it alive.
I think the best approach will be to focus on the system as a general application development framework - starting with the API and some core modules (admin, setup, preferences).
Every single framework does that... and many better than we do : Zend
first of them but also Symfony, drupal, eZ...
If we plan to gon on their scope we are dead...
Post by Dave HallI also think the majority of the existing applications without a minimum level of maintenance has to be put in a historical archive for future reference and a possible source of inspiration only.
That makes sense but the svn system as i re-organized it just need to
change the list of externals to let these module aside
Yes and there we'll need to put hard work
And part of this work will involve thinking about template system :
coders are often very poor interface designers
And good interface designers have often very poor php and xml skills.
Dreamweaver (sorry guys for the ugly word) and css and htmls are their
worlds.
Relying on current xsltemplate even if it's sexy on the paper will
ensure that zero descent web designer will be able to get in and help
us make nice looking user interfaces.
As far as web design is concerned the previous phplib based template
system was loads better.
Post by Dave Hall* integration capabilities (xmlrpc/soap/ldap...)
Agreed
Post by Dave Hall* building blocks for ui as super-objects prepared to utilize common elements (as tables, lists, calendars)
Not agreed
Post by Dave Hall* mechanism for internal integration across modules
Agreed a million times
Post by Dave HallI will fix the API (and core) to a usable state (running php 5.3) - and update to the latest 3-party libraries.
Ok on the goal but if we go on we'll have to discuss the method : i
don't wand to see a giant commit changing things everywhere whitout more
thant "Merge from my working company tree"
Suvbersion is all about keeping track of changes and helping bug hunting
by the means of changelog and commit date analysis
A million times okay for code fixing... but a million times not okay for
giant commits impossible to check
You probably did not even consider such commit... in this case please
accept my apologies for this part of my mail :)
Post by Dave HallI think that once the system is in a shape that makes is possible to install and operate - it will attract developers and users.
Regards
Sigurd
indeed having something that installs and works would be a nice idea :)
but if you want to attract devs ans users that will not be enough
we'll need documentation (people willing to write it) and user + dev
support (people willing to help people getting in... explaining things
again and again)
And till we have enough manpower to make separate teams for support and
developpement and doc writing and betatesting the remaining people will
have to be everywhere