Discussion:
[Phpgroupware-cvs] [18946] drop externals - core is a module in its own right
Maât
2008-09-28 12:13:15 UTC
Permalink
Revision: 18946
http://svn.sv.gnu.org/viewvc/?view=rev&root=phpgroupware&revision=18946
Author: skwashd
Date: 2008-09-28 11:55:32 +0000 (Sun, 28 Sep 2008)
-----------
drop externals - core is a module in its own right
----------------
core/trunk/
Property changes on: core/trunk
___________________________________________________________________
Name: svn:externals
- addressbook http://svn.savannah.gnu.org/svn/phpgroupware/modules/addressbook/trunk
admin http://svn.savannah.gnu.org/svn/phpgroupware/modules/admin/trunk
calendar http://svn.savannah.gnu.org/svn/phpgroupware/modules/calendar/trunk
developer_tools http://svn.savannah.gnu.org/svn/phpgroupware/modules/developer_tools/trunk
ged http://svn.savannah.gnu.org/svn/phpgroupware/modules/ged/trunk
hrm http://svn.savannah.gnu.org/svn/phpgroupware/modules/hrm/trunk
manual http://svn.savannah.gnu.org/svn/phpgroupware/modules/manual/trunk
news_admin http://svn.savannah.gnu.org/svn/phpgroupware/modules/news_admin/trunk
notes http://svn.savannah.gnu.org/svn/phpgroupware/modules/notes/trunk
phpgwapi http://svn.savannah.gnu.org/svn/phpgroupware/modules/phpgwapi/trunk
preferences http://svn.savannah.gnu.org/svn/phpgroupware/modules/preferences/trunk
property http://svn.savannah.gnu.org/svn/phpgroupware/modules/property/trunk
setup http://svn.savannah.gnu.org/svn/phpgroupware/modules/setup/trunk
syncml http://svn.savannah.gnu.org/svn/phpgroupware/modules/syncml/trunk
syncml-server http://svn.savannah.gnu.org/svn/phpgroupware/modules/syncml-server/trunk
todo http://svn.savannah.gnu.org/svn/phpgroupware/modules/todo/trunk
wiki http://svn.savannah.gnu.org/svn/phpgroupware/modules/wiki/trunk
+
rhaaaa !

dave ! stop this and learn how to use subversion before doing more harm !

Each module here has it's own version ! that's how phpgroupware
architecture is thought from the beginning

Example with calendar :

you have a setup dir with inside the specific version of calendar and
the rules to move from a version to an other :

calendar/setup/setup.inc.php :


$setup_info['calendar']['name'] = 'calendar';
$setup_info['calendar']['version'] = '0.9.18.002';
$setup_info['calendar']['app_order'] = 3;
$setup_info['calendar']['enable'] = 1;
$setup_info['calendar']['app_group'] = 'office';

and in calednar/setup/tables_update.inc.php you have things like that :

$test[] = '0.9.10pre27';
function calendar_upgrade0_9_10pre27()
{
$GLOBALS['setup_info']['calendar']['currentver'] =
'0.9.10pre28';
return $GLOBALS['setup_info']['calendar']['currentver'];
}
$test[] = '0.9.10pre28';
function calendar_upgrade0_9_10pre28()
{
$GLOBALS['setup_info']['calendar']['currentver'] = '0.9.10';
return $GLOBALS['setup_info']['calendar']['currentver'];
}

this allow to move from a version to an other

=> each module leaves it's own life and have it's own version and
phpgroupware brings all together


with a trunk/tags/branches for each module (wether core or not) you will
be able to have tags for each calendar version

with a big hardcoded core with everything inside you will loose this ability

from quality and source control management this is awful !

svn:externals are a far less ugly approach for project management

what we agreed before was wether some apps would be considered core or
not core : what you are doing is pure nonsense !

appart a few specific dirs (if they exist) without this setup/* system
all these modules need to have a specific versionning life

WHAT YOU ARE DOING IS STUPID :
Dave Hall
2008-09-28 12:57:07 UTC
Permalink
Post by Maât
this allow to move from a version to an other
=> each module leaves it's own life and have it's own version and
phpgroupware brings all together
I have discussed this with you many times on IRC. The core part of the
phpGW (admin, addressbook, calendar, email, filemanager, notes,
preferences, setup todo) function as one.

You have even agreed that it wasn't your preferred option, but you would
accept it.
Post by Maât
with a trunk/tags/branches for each module (wether core or not) you will
be able to have tags for each calendar version
Most application versions are nothing more than a db schema change.
When module APIs change there is no version bump.
Post by Maât
with a big hardcoded core with everything inside you will loose this ability
from quality and source control management this is awful !
svn:externals are a far less ugly approach for project management
what we agreed before was wether some apps would be considered core or
not core : what you are doing is pure nonsense !
No, what we agreed is that some modules would be included in a core
module. The list of such modules was well publicised and agreed.
Post by Maât
appart a few specific dirs (if they exist) without this setup/* system
all these modules need to have a specific versionning life
I don't think that there is any need to shout especially in emails which
you know are being sent after the fact. You had ample opportunity to
discuss this further on IRC.

Rather than engage is an adult discussion on IRC this evening (my time)
you chose to be hostile. I will readily admit that I was annoyed about
the situation and let this show in the discussion.

If you wished to change the agreed position on how the tree was to be
structured you were free to do so, but not via svn commits. You should
have raised this on this list before commencing.

Cheers

Dave
--
Dave Hall (aka skwashd)
Coordinator - Community Building
phpGroupWare
e ***@phpgroupware.org
w phpgroupware.org
j ***@gmail.com
sip ***@fwd.pulver.com
_ ____ __ __
_ __ | |__ _ __ / ___|_ __ ___ _ _ _ _\ \ / /_ _ _ __ ___
| '_ \| '_ \| '_ \| | _| '__/ _ \| | | | '_ \ \ /\ / / _` | '__/ _ \
| |_) | | | | |_) | |_| | | | (_) | |_| | |_) \ V V / (_| | | | __/
| .__/|_| |_| .__/ \____|_| \___/ \__,_| .__/ \_/\_/ \__,_|_| \___|
|_| |_| |_|Web based collaboration platform
Maât
2008-09-28 13:46:14 UTC
Permalink
Post by Dave Hall
If you wished to change the agreed position on how the tree was to be
structured you were free to do so, but not via svn commits. You should
have raised this on this list before commencing.
Cheers
Dave
I was and i'm still hostile to this approach which is an anti-pattern as
far as source control of this specific project is concerned.

what i just said is that i would not go against a community decision but
dave hall decision is not community's i think ? by the way you made
those post reorganization changes today without referring to the
community :)

what i offered here on the list was a change so that we need a single
checkout to have a full working phpgroupware to make things simpler for
users and betatesters at first and as simple as possible for our developers.

that's what i did... after your changes things are still better than
before reorganization but the goal of sipmlicity is obviously missed

i give up : do whatever you want !

Maât
Dave Hall
2008-09-28 13:52:19 UTC
Permalink
Post by Maât
Post by Dave Hall
If you wished to change the agreed position on how the tree was to be
structured you were free to do so, but not via svn commits. You should
have raised this on this list before commencing.
Cheers
Dave
I was and i'm still hostile to this approach which is an anti-pattern as
far as source control of this specific project is concerned.
what i just said is that i would not go against a community decision but
dave hall decision is not community's i think ? by the way you made
those post reorganization changes today without referring to the
community :)
We had discussed this many times on IRC and agreed on how it would be
implemented. I had also offered for you to have the discussion here if
you disagreed with me. There was no need to discuss the mater here as
it has already been agreed. It was you who went against agreed
positions.

Cheers

Dave
--
Dave Hall (aka skwashd)
Coordinator - Community Building
phpGroupWare
e ***@phpgroupware.org
w phpgroupware.org
j ***@gmail.com
sip ***@fwd.pulver.com
_ ____ __ __
_ __ | |__ _ __ / ___|_ __ ___ _ _ _ _\ \ / /_ _ _ __ ___
| '_ \| '_ \| '_ \| | _| '__/ _ \| | | | '_ \ \ /\ / / _` | '__/ _ \
| |_) | | | | |_) | |_| | | | (_) | |_| | |_) \ V V / (_| | | | __/
| .__/|_| |_| .__/ \____|_| \___/ \__,_| .__/ \_/\_/ \__,_|_| \___|
|_| |_| |_|Web based collaboration platform
Maât
2008-09-28 14:10:58 UTC
Permalink
Post by Dave Hall
Post by Maât
Post by Dave Hall
If you wished to change the agreed position on how the tree was to be
structured you were free to do so, but not via svn commits. You should
have raised this on this list before commencing.
Cheers
Dave
I was and i'm still hostile to this approach which is an anti-pattern as
far as source control of this specific project is concerned.
what i just said is that i would not go against a community decision but
dave hall decision is not community's i think ? by the way you made
those post reorganization changes today without referring to the
community :)
We had discussed this many times on IRC and agreed on how it would be
implemented. I had also offered for you to have the discussion here if
you disagreed with me. There was no need to discuss the mater here as
it has already been agreed. It was you who went against agreed
positions.
Cheers
Dave
Seems we did not understand each other

You just agreed this with yourself and enforced it... it's not community
it's not democracy...

...simply davehallcracy :)
Dave Hall
2008-09-28 14:22:49 UTC
Permalink
Post by Maât
Post by Dave Hall
We had discussed this many times on IRC and agreed on how it would be
implemented. I had also offered for you to have the discussion here if
you disagreed with me. There was no need to discuss the mater here as
it has already been agreed. It was you who went against agreed
positions.
Seems we did not understand each other
You just agreed this with yourself and enforced it... it's not community
it's not democracy...
...simply davehallcracy :)
This is complete rubbish and you know it.

The last time we discussed it was on IRC 9 Sept. I can pull out the
logs if you like.

Cheers

Dave
Maât
2008-09-28 16:35:30 UTC
Permalink
Post by Dave Hall
Post by Maât
Post by Dave Hall
We had discussed this many times on IRC and agreed on how it would be
implemented. I had also offered for you to have the discussion here if
you disagreed with me. There was no need to discuss the mater here as
it has already been agreed. It was you who went against agreed
positions.
Seems we did not understand each other
You just agreed this with yourself and enforced it... it's not community
it's not democracy...
...simply davehallcracy :)
This is complete rubbish and you know it.
The last time we discussed it was on IRC 9 Sept. I can pull out the
logs if you like.
Cheers
Dave
i said that i would not fight... see : i gave up

(but hiding behind a self-decided-agreement will not clear you from
having taken a bad technical decision and enforced it)

Loading...