I may be beating a dead horse but what Jacopo is proposing and the
concern that Jacques raised about resources would seem to fit very well
into a sub-project structure.
Split these modules out of the main line into their own OFBiz
sub-projects where they could attract their own resources (committers
even) and would be responsible for delivering modules that worked with
the various OFBiz cores that exist.
Let the sub-projects worry about their own relationship to OFBiz
releases and release branches.
They might just support the released 13.07.xx version, if that is what
the sub-project's user community can support or they might maintain 2
versions 13.07 and a 14.xx. that works with a recent version of the trunk.
In any case, it would no longer be a problem for the OFBiz core
developers and they could release just the OFBiz components that are
officially part of the core.
Clearly good communication between the core project and the sub-project
about release plans would help everyone but the core group would be
basically free to release the core as they want and the sub-projects
would have to communicate to their uses communities what impact this
would have on the users of the modules.
If a sub-project needs a change to the core to implement some feature,
they would have to file an enhancement JIRA issue and convince someone
to add it (unless they are a committer on the core).
If two sub-projects had a compatibility issue, they would at least know
who to talk to get a solution.
Ron
On 07/11/2014 7:04 AM, Jacopo Cappellato wrote:
On Nov 7, 2014, at 12:36 PM, Jacques Le Roux <jacques.le.r...@les7arts.com>
wrote:
This will no longer work for some components (scrum for instance)
I believe we could be reintroduce some specialpurpose component in next release,
There is a difference between including them in a release branch and including
them in the releases: I would be more inclined to include (all of them) in the
release branches but exclude them from the releases; this would simplify the
work required to keep them in synch and would also help end users to integrate
them.
However the specialpurpose components should be disabled in order to avoid the
users to get a default ootb release/branch with enabled special purpose
functionalities that may override the more general purpose ones offered by the
core applications.
We should still consider the idea of providing separate products for the
specialpurpose components (and having them in the branch would help this
process).
If the idea I am proposing here (include the specialpurpose components in the
branch but not in the releases) we could re-add them (as disabled) also to the
13.07 branch but exclude them from all the releases (13.07.02 etc...): this
will protect all the stabilization work we did on the branch (and also from
some licensing issues that may affects some of the artifacts in some of the
specialpurpose components) .
Jacopo
as long as they are backed by some efforts, come to mind
project manager (Pierre Smits?)
scrum (Hans?)
examples and ext (at least me)
myportal (French people use portals, not sure for myportal?)
Other components?
IRRW Jacopo said he was not against a new discussion on this subject (I could
not find his message), what do you think?
Jacques
Le 21/10/2014 09:06, gil portenseigne a écrit :
I've never used svn external property, just discovering. That sounds usefull
and i'll try it out !
Thanks for the advice !
Gil
On 20/10/2014 19:08, Jacques Le Roux wrote:
I use svn external in the stable demo, already explained that in the MLs: see
https://svn.apache.org/viewvc/ofbiz/trunk/tools/demo-backup/branch13.7-demo.patch?view=markup
You can use the same to keep in sync, only consider projectmgr in your case.
Since there is no projectmgr in R13.07 the risk of gettins conflicts or build
issue is extremely low
Jacques
Le 20/10/2014 17:28, gil portenseigne a écrit :
Hi Jacopo,
Ok then, i will have to re-synchronize new trunk devs each time i'll feel it
necessary. My fear is about incompatibility between 13.07 and trunk
technologies, but that won't happen soon, or i might backport the evolution
into my local environment.
That will do the job !
Thanks
Gil
On 20/10/2014 16:36, Jacopo Cappellato wrote:
Hi Gil,
I would suggest to check it out from the trunk to the hot-deploy folder of
13.07:
cd hot-deploy
svn co http://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr
Jacopo
On Oct 20, 2014, at 4:11 PM, gil portenseigne <gil.portensei...@nereide.fr>
wrote:
Hi all,
I don't want to relaunch the debate around including the projectMgmt component
into the 13.07 release, but i have a question :
What is the best way to import the projectMgr component in my local 13.07
checkout environment, to start using it in a real project and to contribute on
upgrading it for trunk and/or the 13.07 release ?
Trunk technical evolution might be a problem if a want to stick to 13.07
release with projectMgmt features.
Should I use trunk instead ?
Cheers
Gil
--
<siteon0.jpg>
Gil Portenseigne
Consultant ERP OFBiz
Société Néréide
3b Les isles
37270 Veretz
Tel : 09 74 53 46 09, puis 1, poste 61
Mob : 06 82 740 444
www.nereide.fr
--
<Mail Attachment.jpeg>
Gil Portenseigne
Consultant ERP OFBiz
Société Néréide
3b Les isles
37270 Veretz
Tel : 09 74 53 46 09, puis 1, poste 61
Mob : 06 82 740 444
www.nereide.fr
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
