Brainstorming: changing the way we work and release

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Brainstorming: changing the way we work and release

[Raj Saini <ra...@gmail.com>]

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."
>

Re: Brainstorming: changing the way we work and release

[Christopher Snow <sn...@snowconsulting.co.uk>]

> 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."

Re: Brainstorming: changing the way we work and release

[Adrian Crum <ad...@yahoo.com>]

--- On Tue, 5/4/10, Jacopo Cappellato <ja...@hotwaxmedia.com> 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
> >> 
> >> 
> 
> 


      

Re: Brainstorming: changing the way we work and release

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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
>> 
>> 

Re: Brainstorming: changing the way we work and release

[Adrian Crum <ad...@hlmksw.com>]

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:
> 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
>
>

Re: Brainstorming: changing the way we work and release

[chris snow <ch...@gmail.com>]

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
-- 
View this message in context: http://ofbiz.135035.n4.nabble.com/Brainstorming-changing-the-way-we-work-and-release-tp2125090p2195599.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Brainstorming: changing the way we work and release

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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
>> 
> 

Re: Brainstorming: changing the way we work and release

[David E Jones <de...@me.com>]

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:

> 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
>