OFBiz › OFBiz - Dev

Brainstorming: changing the way we work and release

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Jacopo Cappellato-4

Brainstorming: changing the way we work and release

What if we start evaluating a different way we organize our svn, daily work and release strategy?
We may try to move in the direction of having a more stable framework and more dynamic applications.

A very simple strategy would be the following one:

all the changes to the framework (that are not bug fixes) are done in a separate branch (branches/framework-latest or similar); in this way trunk/framework will only get bug fixes.
Every 6-12 months (or whenever we want - we can discuss about this) we merge the branches/framework-latest into trunk/framework and fix the trunk/applications (of course we could do this in a separate temporary branch).

What do you think?

Jacopo

BJ Freeman

Re: Brainstorming: changing the way we work and release

I come from a time when everything was modularize similar to ofbiz.
I go by the principle that if one line of code is changed the whole
program is suspect for errors.
each modules was determined to have it own life cycle. Therefore if only
one module is changed it is the only one suspect for errors.

each module was define as a black box with input and outputs. to which
other modules would interface.

so each module had its own workspace. the team working on a module would
notify the other teams when their interface would change effecting the
other modules.
This would allow each module to be updated with out changing the
complete program.
so the versioning was at module level and the program version was
modified based on the modules versions.

so trunk would stay stable each module would have it own branch.
someone could move a module into their local version of the trunk to test.
but the basic test of the module while in their branch would be against
established black box input and output.

the would allow a module to advance but not actually effect the trunk
till the merge. and as long as the test passed there should not be any
merge issues.

so each folder of the frame work would be a module under the module
framework branch.
and each application would be a module under applications branch and so
forth.

=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>

Jacopo Cappellato sent the following on 5/4/2010 12:04 AM:

> What if we start evaluating a different way we organize our svn, daily work and release strategy?
> We may try to move in the direction of having a more stable framework and more dynamic applications.
>
> A very simple strategy would be the following one:
>
> all the changes to the framework (that are not bug fixes) are done in a separate branch (branches/framework-latest or similar); in this way trunk/framework will only get bug fixes.
> Every 6-12 months (or whenever we want - we can discuss about this) we merge the branches/framework-latest into trunk/framework and fix the trunk/applications (of course we could do this in a separate temporary branch).
>
> What do you think?
>
> Jacopo
>
>

Adrian Crum

Re: Brainstorming: changing the way we work and release

In reply to this post by Jacopo Cappellato-4

I'm confused. What do you mean by "a more stable framework?" Is the
framework currently unstable?

What do you mean by "more dynamic applications?"

-Adrian

On 5/4/2010 12:04 AM, Jacopo Cappellato wrote:

David E. Jones-2

Re: Brainstorming: changing the way we work and release

In reply to this post by Jacopo Cappellato-4

Is the hope for this proposal to avoid having to completely separate the framework from the applications? My first thought reading this was that it would probably be necessary to separate the two so dependencies only go one way (ie applications depend on the framework, framework does not depend on the applications) in order to realistically do this.

Also, if we are considering this sort of approach, why not just go one step further that will make things easier and move the framework to a separate part of SVN with it's own trunk and branches folders, and then only include a binary distribution of that separate framework on the applications side of things?

-David

On May 4, 2010, at 1:04 AM, Jacopo Cappellato wrote:

Jacopo Cappellato-4

Re: Brainstorming: changing the way we work and release

In reply to this post by Adrian Crum

On May 4, 2010, at 6:17 PM, Adrian Crum wrote:

> I'm confused. What do you mean by "a more stable framework?" Is the framework currently unstable?

I should have said probably "a more static framework"

>
> What do you mean by "more dynamic applications?"

This doesn't make a lot of sense, I was probably just tired.
My proposal was addressed in having a more severe policy in the commits that change the features of the framework but let the applications features set grows freely.
This is why I suggested to commit the new features for the framework in a separate branch, test it, and then merge back in a scheduled way.

Kind regards,

Jacopo

>
> -Adrian
>
> On 5/4/2010 12:04 AM, Jacopo Cappellato wrote:
>> What if we start evaluating a different way we organize our svn, daily work and release strategy?
>> We may try to move in the direction of having a more stable framework and more dynamic applications.
>>
>> A very simple strategy would be the following one:
>>
>> all the changes to the framework (that are not bug fixes) are done in a separate branch (branches/framework-latest or similar); in this way trunk/framework will only get bug fixes.
>> Every 6-12 months (or whenever we want - we can discuss about this) we merge the branches/framework-latest into trunk/framework and fix the trunk/applications (of course we could do this in a separate temporary branch).
>>
>> What do you think?
>>
>> Jacopo
>>
>>

Jacopo Cappellato-4

Re: Brainstorming: changing the way we work and release

In reply to this post by David E. Jones-2

On May 4, 2010, at 6:29 PM, David E Jones wrote:

>
> Is the hope for this proposal to avoid having to completely separate the framework from the applications?

No, this is not my goal: in fact I think that the first step (before any change in our strategy) would be to resolve the dependency of the framework on the applications completely.

> My first thought reading this was that it would probably be necessary to separate the two so dependencies only go one way (ie applications depend on the framework, framework does not depend on the applications) in order to realistically do this.

yes.

>
> Also, if we are considering this sort of approach, why not just go one step further that will make things easier and move the framework to a separate part of SVN with it's own trunk and branches folders, and then only include a binary distribution of that separate framework on the applications side of things?

That would be even better: my only concern is that the ASF may (but maybe not) ask us to implement a more formal separation, with the definition of sub projects with independent PMC and releases, and this would be too heavy for the size of the community at the moment.

Jacopo

>
> -David
>
>
> On May 4, 2010, at 1:04 AM, Jacopo Cappellato wrote:
>
>> What if we start evaluating a different way we organize our svn, daily work and release strategy?
>> We may try to move in the direction of having a more stable framework and more dynamic applications.
>>
>> A very simple strategy would be the following one:
>>
>> all the changes to the framework (that are not bug fixes) are done in a separate branch (branches/framework-latest or similar); in this way trunk/framework will only get bug fixes.
>> Every 6-12 months (or whenever we want - we can discuss about this) we merge the branches/framework-latest into trunk/framework and fix the trunk/applications (of course we could do this in a separate temporary branch).
>>
>> What do you think?
>>
>> Jacopo
>>
>

Adrian Crum-2

Re: Brainstorming: changing the way we work and release

In reply to this post by Jacopo Cappellato-4

--- On Tue, 5/4/10, Jacopo Cappellato <[hidden email]> wrote:
> On May 4, 2010, at 6:17 PM, Adrian Crum wrote:
>
> > I'm confused. What do you mean by "a more stable
> framework?" Is the framework currently unstable?
>
> I should have said probably "a more static framework"

Okay, that makes sense.

> > What do you mean by "more dynamic applications?"
>
> This doesn't make a lot of sense, I was probably just
> tired.
> My proposal was addressed in having a more severe policy in
> the commits that change the features of the framework but
> let the applications features set grows freely.
> This is why I suggested to commit the new features for the
> framework in a separate branch, test it, and then merge back
> in a scheduled way.

I would support any effort to add more control to the framework. I support having many committers involved in the framework (so it doesn't become stagnant), but at the same time it would be nice to have better control over framework releases (so it can be reliable). David's suggestion of a separate branch for the framework is an excellent idea.

-Adrian

> > On 5/4/2010 12:04 AM, Jacopo Cappellato wrote:
> >> What if we start evaluating a different way we
> organize our svn, daily work and release strategy?
> >> We may try to move in the direction of having a
> more stable framework and more dynamic applications.
> >>
> >> A very simple strategy would be the following
> one:
> >>
> >> all the changes to the framework (that are not bug
> fixes) are done in a separate branch
> (branches/framework-latest or similar); in this way
> trunk/framework will only get bug fixes.
> >> Every 6-12 months (or whenever we want - we can
> discuss about this) we merge the branches/framework-latest
> into trunk/framework and fix the trunk/applications (of
> course we could do this in a separate temporary branch).
> >>
> >> What do you think?
> >>
> >> Jacopo
> >>
> >>
>
>

Chris Snow-3

Re: Brainstorming: changing the way we work and release

> I would support any effort to add more control to the framework. I support having many committers involved in the framework (so it doesn't become stagnant), but at the same time it would be nice to have better control over framework releases (so it can be reliable). David's suggestion of a separate branch for the framework is an excellent idea.
>
> -Adrian
>

A separate branch along with David's proposal for configuration in Moqui
(below) would also make security updates to production ofbiz
installations much easier too. Framework code (which shouldn't be
changed by the end user) such as the entityengine could be updated just
by replacing the entityengine.jar file.

"Configuration files are meant to come from a runtime directory and are not
spread around the code. There is a default-conf directory in the framework
so that if a configuration file is left out the framework will have a
default
to fallback on that will work in most cases."

rajsaini

Re: Brainstorming: changing the way we work and release

Recently, I worked on running the framework inside a OSGi framework. I
could run the framework standalone except some minor issues such as
loading of configuration files (entity engine and service engine
configuration files) from classpath. Generally these files should be
external to framework so that they can be places out side of the
classpath. A system variable for the location of config files may a good
idea. I also found, some dependency issues between entity engine and
service engine. Entity engine depends on entityext and entityext depends
on service engine which makes entity engine to depend on service engine.

Thanks,

Raj

On 05/05/10 11:31, Christopher Snow wrote:

>
>> I would support any effort to add more control to the framework. I
>> support having many committers involved in the framework (so it
>> doesn't become stagnant), but at the same time it would be nice to
>> have better control over framework releases (so it can be reliable).
>> David's suggestion of a separate branch for the framework is an
>> excellent idea.
>>
>> -Adrian
>
> A separate branch along with David's proposal for configuration in
> Moqui (below) would also make security updates to production ofbiz
> installations much easier too. Framework code (which shouldn't be
> changed by the end user) such as the entityengine could be updated
> just by replacing the entityengine.jar file.
>
> "Configuration files are meant to come from a runtime directory and
> are not
> spread around the code. There is a default-conf directory in the
> framework
> so that if a configuration file is left out the framework will have a
> default
> to fallback on that will work in most cases."
>

chris snow

Re: Brainstorming: changing the way we work and release

In reply to this post by Jacopo Cappellato-4

Hi Jacopo,

Has there been any more progress on your suggestion for this substantial improvement to ofbiz?

I would also be in favor of David's idea of moving the framework to it's own svn location (perhaps, eventually this concept could even be extended so that the entity engine could have it's own svn location).

Many thanks,

Chris