Slim-down effort: current situation

[Malin Nicolas]

Le 15/11/2012 08:49, Jacques Le Roux a écrit :
> I don't see much activity recently
> https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551
>
> Should we not focus a bit more on it?
>
> Jacques
>
Hi all,

To continue on slim-down effort, I propose to work on a POC.
We define the expected to manage component on extra.
We select a component or subject to move from OFBiz to extra and a
delivery date.

Each contributor wishing to work on it, would propose a solution to move
and use a component on extra, open an issue containing the process,
management and the example with selected component.

After the delivery date, we check avantage/disavantage of each
proposition and vote to choose the favorite solution.
Write a best pratice to move/create a component on extra usable by OFBiz.

Then we can start with this process
  * proposal/vote
  * open jira issue
  * write information on extras.html
  * run move

The aim isn't to define what to do but how to contribute when the goal
will be fixed.

Your opinions ?

Nicolas

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Jacques Le Roux]

From: "Nicolas Malin" <[hidden email]>

> Le 15/11/2012 08:49, Jacques Le Roux a écrit :
>> I don't see much activity recently
>> https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551
>>
>> Should we not focus a bit more on it?
>>
>> Jacques
>>
> Hi all,
>
> To continue on slim-down effort, I propose to work on a POC.
> We define the expected to manage component on extra.
> We select a component or subject to move from OFBiz to extra and a
> delivery date.

I think we should also refer to "[PROPOSAL] from specialpurpose to extras" thread here.
I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
Maybe before going on this we would create an evolving wiki page to state the current situation, ideas, consensus and future.
I personnaly begin to lose the focus, a sole place to look at would be easier.
There are a lot of good ideas, we need to pick the better (by consensus of course ;o)
 

> Each contributor wishing to work on it, would propose a solution to move
> and use a component on extra, open an issue containing the process,
> management and the example with selected component.
>
> After the delivery date, we check avantage/disavantage of each
> proposition and vote to choose the favorite solution.
> Write a best pratice to move/create a component on extra usable by OFBiz.
>
> Then we can start with this process
>  * proposal/vote
>  * open jira issue
>  * write information on extras.html
>  * run move

It sounds like this could be in the page I proposed to create.
Before going further I believe we need to clarify in all minds, get consensus and then work on them

My 2cts

Jacques
 

> The aim isn't to define what to do but how to contribute when the goal
> will be fixed.
>
> Your opinions ?
>
> Nicolas
>
> --
> Nicolas MALIN
> Consultant
> Tél : [phone]
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : [phone]
> Site : http://www.librenberry.net/
>

[Jacques Le Roux]

From: "Jacques Le Roux" <[hidden email]>

> From: "Nicolas Malin" <[hidden email]>
>> Le 15/11/2012 08:49, Jacques Le Roux a écrit :
>>> I don't see much activity recently
>>> https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551
>>>
>>> Should we not focus a bit more on it?
>>>
>>> Jacques
>>>
>> Hi all,
>>
>> To continue on slim-down effort, I propose to work on a POC.
>> We define the expected to manage component on extra.
>> We select a component or subject to move from OFBiz to extra and a
>> delivery date.
>
> I think we should also refer to "[PROPOSAL] from specialpurpose to extras" thread here.
> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
> Maybe before going on this we would create an evolving wiki page to state the current situation, ideas, consensus and future.
> I personnaly begin to lose the focus, a sole place to look at would be easier.
> There are a lot of good ideas, we need to pick the better (by consensus of course ;o)

I created https://cwiki.apache.org/confluence/display/OFBIZ/Slimdown+Effort+Roadmap (just a mock for now, feel free to do what you want...)

Jacques
 

>> Each contributor wishing to work on it, would propose a solution to move
>> and use a component on extra, open an issue containing the process,
>> management and the example with selected component.
>>
>> After the delivery date, we check avantage/disavantage of each
>> proposition and vote to choose the favorite solution.
>> Write a best pratice to move/create a component on extra usable by OFBiz.
>>
>> Then we can start with this process
>>  * proposal/vote
>>  * open jira issue
>>  * write information on extras.html
>>  * run move
>
> It sounds like this could be in the page I proposed to create.
> Before going further I believe we need to clarify in all minds, get consensus and then work on them
>
> My 2cts
>
> Jacques
>
>> The aim isn't to define what to do but how to contribute when the goal
>> will be fixed.
>>
>> Your opinions ?
>>
>> Nicolas
>>
>> --
>> Nicolas MALIN
>> Consultant
>> Tél : [phone]
>> Site projet : http://www.neogia.org/
>> -------
>> Société LibrenBerry
>> Tél : [phone]
>> Site : http://www.librenberry.net/
>>
>

[Malin Nicolas]

Thanks jacques, create a wiki page sound good to me :)

Nicolas

Le 16/12/2012 14:28, Jacques Le Roux a écrit :

> From: "Jacques Le Roux" <[hidden email]>
>> From: "Nicolas Malin" <[hidden email]>
>>> Le 15/11/2012 08:49, Jacques Le Roux a écrit :
>>>> I don't see much activity recently
>>>> https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12320551
>>>>
>>>> Should we not focus a bit more on it?
>>>>
>>>> Jacques
>>>>
>>> Hi all,
>>>
>>> To continue on slim-down effort, I propose to work on a POC.
>>> We define the expected to manage component on extra.
>>> We select a component or subject to move from OFBiz to extra and a
>>> delivery date.
>> I think we should also refer to "[PROPOSAL] from specialpurpose to extras" thread here.
>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>> Maybe before going on this we would create an evolving wiki page to state the current situation, ideas, consensus and future.
>> I personnaly begin to lose the focus, a sole place to look at would be easier.
>> There are a lot of good ideas, we need to pick the better (by consensus of course ;o)
> I created https://cwiki.apache.org/confluence/display/OFBIZ/Slimdown+Effort+Roadmap (just a mock for now, feel free to do what you want...)
>
> Jacques
>  
>>> Each contributor wishing to work on it, would propose a solution to move
>>> and use a component on extra, open an issue containing the process,
>>> management and the example with selected component.
>>>
>>> After the delivery date, we check avantage/disavantage of each
>>> proposition and vote to choose the favorite solution.
>>> Write a best pratice to move/create a component on extra usable by OFBiz.
>>>
>>> Then we can start with this process
>>>   * proposal/vote
>>>   * open jira issue
>>>   * write information on extras.html
>>>   * run move
>> It sounds like this could be in the page I proposed to create.
>> Before going further I believe we need to clarify in all minds, get consensus and then work on them
>>
>> My 2cts
>>
>> Jacques
>>
>>> The aim isn't to define what to do but how to contribute when the goal
>>> will be fixed.
>>>
>>> Your opinions ?
>>>
>>> Nicolas
>>>
>>> --
>>> Nicolas MALIN
>>> Consultant
>>> Tél : [phone]
>>> Site projet : http://www.neogia.org/
>>> -------
>>> Société LibrenBerry
>>> Tél : [phone]
>>> Site : http://www.librenberry.net/
>>>

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Jacopo Cappellato-4]

On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:

> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?

Do you mean the following?

========================
BTW, some time ago I also proposed an alternative path: see email with subject "[PROPOSAL] from specialpurpose to extras": to that I can add that we could provide two set of ant scripts, one similar to the one we have that builds/tests everything (framework+applications+specialpurpose) and one (the default) that only builds/tests the framework+applications; the release branches may only contain the framework+applications and separate releases of specialpurpose applications could be voted/released at different time. This approach may reach two goals:
1) slim down the "main" code that the community is more focused to improve/maintain/release
2) keep under the OFBiz community the ownership of all the other specialpurpose components; if one of them will get more attention and interest and could grow in quality or it is generic enough we could decide to move it to the release branch (maybe move it to applications)
========================

Jacopo

[Jacques Le Roux]

Yes thanks!

Jacques

From: "Jacopo Cappellato" <[hidden email]>

>
> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>
>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>
> Do you mean the following?
>
> ========================
> BTW, some time ago I also proposed an alternative path: see email with subject "[PROPOSAL] from specialpurpose to extras": to that I can add that we could provide two set of ant scripts, one similar to the one we have that builds/tests everything (framework+applications+specialpurpose) and one (the default) that only builds/tests the framework+applications; the release branches may only contain the framework+applications and separate releases of specialpurpose applications could be voted/released at different time. This approach may reach two goals:
> 1) slim down the "main" code that the community is more focused to improve/maintain/release
> 2) keep under the OFBiz community the ownership of all the other specialpurpose components; if one of them will get more attention and interest and could grow in quality or it is generic enough we could decide to move it to the release branch (maybe move it to applications)
> ========================
>
> Jacopo
>
>

[Jacques Le Roux]

I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)?
http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html

Opinions?

Jacques

From: "Jacques Le Roux" <[hidden email]>

> Yes thanks!
>
> Jacques
>
> From: "Jacopo Cappellato" <[hidden email]>
>>
>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>
>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>
>> Do you mean the following?
>>
>> ========================
>> BTW, some time ago I also proposed an alternative path: see email with subject "[PROPOSAL] from specialpurpose to extras": to that I can add that we could provide two set of ant scripts, one similar to the one we have that builds/tests everything (framework+applications+specialpurpose) and one (the default) that only builds/tests the framework+applications; the release branches may only contain the framework+applications and separate releases of specialpurpose applications could be voted/released at different time. This approach may reach two goals:
>> 1) slim down the "main" code that the community is more focused to improve/maintain/release
>> 2) keep under the OFBiz community the ownership of all the other specialpurpose components; if one of them will get more attention and interest and could grow in quality or it is generic enough we could decide to move it to the release branch (maybe move it to applications)
>> ========================
>>
>> Jacopo
>>
>>
>

[Anil Patel-3]

One of the solutions is to create brach on github, https://github.com/apache/ofbiz. A feature can be developed on Github and then a final patch can be submitted to Ofbiz Jira.

Regards
Anil Patel



On Jan 4, 2013, at 9:17 AM, Jacques Le Roux <[hidden email]> wrote:

> I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)?
> http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html
>
> Opinions?
>
> Jacques
>
> From: "Jacques Le Roux" <[hidden email]>
>> Yes thanks!
>>
>> Jacques
>>
>> From: "Jacopo Cappellato" <[hidden email]>
>>>
>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>
>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>>
>>> Do you mean the following?
>>>
>>> ========================
>>> BTW, some time ago I also proposed an alternative path: see email with subject "[PROPOSAL] from specialpurpose to extras": to that I can add that we could provide two set of ant scripts, one similar to the one we have that builds/tests everything (framework+applications+specialpurpose) and one (the default) that only builds/tests the framework+applications; the release branches may only contain the framework+applications and separate releases of specialpurpose applications could be voted/released at different time. This approach may reach two goals:
>>> 1) slim down the "main" code that the community is more focused to improve/maintain/release
>>> 2) keep under the OFBiz community the ownership of all the other specialpurpose components; if one of them will get more attention and interest and could grow in quality or it is generic enough we could decide to move it to the release branch (maybe move it to applications)
>>> ========================
>>>
>>> Jacopo
>>>
>>>
>>

[Ean Schuessler]

Why wouldn't they just fork and then issue a pull request on GitHub?

----- "Jacques Le Roux" wrote:
> I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)?
> http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html 

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com 

[Jacques Le Roux]

Because it's possibly easier for committers to follow the work done and not get a big patch at the end.
With Git you tend to receive either a burst of patches or a big one, both in one shoot.
Then it's hard to review the work done. By steps it's easier

I don't use GitHub, I have enough to do with OFBiz patches already...

Jacques

From: "Ean Schuessler" <[hidden email]>

> Why wouldn't they just fork and then issue a pull request on GitHub?
>
> ----- "Jacques Le Roux" wrote:
>> I was reading this article and suddenly thought: why not giving access to branches in OFBiz project to people who need more than a patch to submit in a Jira (clearly Tom and I would have loved that)?
>> http://prng.blogspot.fr/2009/02/commit-access-its-social-problem.html 
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com 
>

[Ean Schuessler]

I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted. I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository. The nice thing about GIT is that the chaff doesn't get into the wheat bucket.
----- "Jacques Le Roux" wrote:
> Because it's possibly easier for committers to follow the work done and not get a big patch at the end.
> With Git you tend to receive either a burst of patches or a big one, both in one shoot.
> Then it's hard to review the work done. By steps it's easier
> I don't use GitHub, I have enough to do with OFBiz patches already...

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com 

[Jacques Le Roux]

From: "Ean Schuessler" <[hidden email]>
> I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted.
>I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository.

Depends, if committer/s follow/s the work closely then it can be a could way to share until the work is finished. I don't see what GitHub adds to this.

>The nice thing about GIT is that the chaff doesn't get into the wheat bucket.

Don't make sense to me. In svn branches in OFBiz repo if the work is of low quality, and dropping a branch is only few clicks.
If the work is of low quality in GitHub it will be ignored as well.

If the work is of good quality, why wait to have it in GitHub in the meantime and not directly in a svn branch?

I still really don't see what GitHub brings here... apart (for me at leat) learning to use Git

Jacques

> ----- "Jacques Le Roux" wrote:
>> Because it's possibly easier for committers to follow the work done and not get a big patch at the end.
>> With Git you tend to receive either a burst of patches or a big one, both in one shoot.
>> Then it's hard to review the work done. By steps it's easier
>> I don't use GitHub, I have enough to do with OFBiz patches already...
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com 
>

[David E. Jones-2]

On Jan 5, 2013, at 1:47 PM, Jacques Le Roux <[hidden email]> wrote:

> From: "Ean Schuessler" <[hidden email]>
>> I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted.
>> I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository.
>
> Depends, if committer/s follow/s the work closely then it can be a could way to share until the work is finished. I don't see what GitHub adds to this.
>
>> The nice thing about GIT is that the chaff doesn't get into the wheat bucket.
>
> Don't make sense to me. In svn branches in OFBiz repo if the work is of low quality, and dropping a branch is only few clicks.
> If the work is of low quality in GitHub it will be ignored as well.
>
> If the work is of good quality, why wait to have it in GitHub in the meantime and not directly in a svn branch?
>
> I still really don't see what GitHub brings here... apart (for me at leat) learning to use Git

Can we even restrict commit access to branches in the ASF SVN any more? We moved away from restricted access to framework versus applications a long time ago due to pressure from infra/others, and I'm not sure if we can so easily make someone a committer to just a branch.

With GitHub we don't need to do anything, anyone can create a public or private fork of OFBiz and change it all they want. People can also still extract patches across multiple commits so it's not so much work to apply them. It's really a much better approach.

-David

[Jacques Le Roux]

From: <[hidden email]>

> On Jan 5, 2013, at 1:47 PM, Jacques Le Roux <[hidden email]> wrote:
>
>> From: "Ean Schuessler" <[hidden email]>
>>> I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted.
>>> I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository.
>>
>> Depends, if committer/s follow/s the work closely then it can be a could way to share until the work is finished. I don't see what GitHub adds to this.
>>
>>> The nice thing about GIT is that the chaff doesn't get into the wheat bucket.
>>
>> Don't make sense to me. In svn branches in OFBiz repo if the work is of low quality, and dropping a branch is only few clicks.
>> If the work is of low quality in GitHub it will be ignored as well.
>>
>> If the work is of good quality, why wait to have it in GitHub in the meantime and not directly in a svn branch?
>>
>> I still really don't see what GitHub brings here... apart (for me at leat) learning to use Git
>
> Can we even restrict commit access to branches in the ASF SVN any more? We moved away from restricted access to framework versus applications a long time ago due to pressure from infra/others, and I'm not sure if we can so easily make someone a committer to just a branch.

I'd have to check that, but I believe once well (and very politely ;o) explained it should be possible to convince them
 
> With GitHub we don't need to do anything, anyone can create a public or private fork of OFBiz and change it all they want. People can also still extract patches across multiple commits so it's not so much work to apply them. It's really a much better approach.

Of course, as you said it's already there, so we have nothing to do, nothing happens.

Jacques

> -David
>

[Jacopo Cappellato-4]

Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:

* svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
* however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
* we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
* the official releases (and release branches) will not contain the specialpurpose folder
* we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
* key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...

The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)
b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)

Some clarifications:
* we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
* we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose

As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.

What do you think?

Jacopo

On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:

> Yes thanks!
>
> Jacques
>
> From: "Jacopo Cappellato" <[hidden email]>
>>
>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>
>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>
>> Do you mean the following?
>>
>> ========================
>> BTW, some time ago I also proposed an alternative path: see email with subject "[PROPOSAL] from specialpurpose to extras": to that I can add that we could provide two set of ant scripts, one similar to the one we have that builds/tests everything (framework+applications+specialpurpose) and one (the default) that only builds/tests the framework+applications; the release branches may only contain the framework+applications and separate releases of specialpurpose applications could be voted/released at different time. This approach may reach two goals:
>> 1) slim down the "main" code that the community is more focused to improve/maintain/release
>> 2) keep under the OFBiz community the ownership of all the other specialpurpose components; if one of them will get more attention and interest and could grow in quality or it is generic enough we could decide to move it to the release branch (maybe move it to applications)
>> ========================
>>
>> Jacopo
>>
>>

[Paul Piper]

I think this is a very good idea, Jacopo - straight forward and easy to maintain

[Jacques Le Roux]

From: "Jacopo Cappellato" <[hidden email]>

> Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:
>
> * svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
> * however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
> * we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
> * the official releases (and release branches) will not contain the specialpurpose folder
> * we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
> * key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...
>
> The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
> a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)

About the side note: indeed! It will be easier to do with your proposed new way.

> b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)
>
> Some clarifications:
> * we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
> * we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose
>
> As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.
>
> What do you think?

+1, definitively the way to go, with maybe some refinements

Jacques

>
> Jacopo
>
> On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
>
>> Yes thanks!
>>
>> Jacques
>>
>> From: "Jacopo Cappellato" <[hidden email]>
>>>
>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>
>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>>
>>> Do you mean the following?
>>>
>>> ========================
>>> BTW, some time ago I also proposed an alternative path: see email with subject "[PROPOSAL] from specialpurpose to extras": to that I can add that we could provide two set of ant scripts, one similar to the one we have that builds/tests everything (framework+applications+specialpurpose) and one (the default) that only builds/tests the framework+applications; the release branches may only contain the framework+applications and separate releases of specialpurpose applications could be voted/released at different time. This approach may reach two goals:
>>> 1) slim down the "main" code that the community is more focused to improve/maintain/release
>>> 2) keep under the OFBiz community the ownership of all the other specialpurpose components; if one of them will get more attention and interest and could grow in quality or it is generic enough we could decide to move it to the release branch (maybe move it to applications)
>>> ========================
>>>
>>> Jacopo
>>>
>>>
>
>

[Jacques Le Roux]

A bit out of subject, I found this article interesting http://kohsuke.org/2013/01/04/the-other-side-of-forking-and-pull-requests
And he made me wonder how the OpenErp project is handling its addons (some years ago someone told me this was a weak part of the project, I never dug)

Jacques

From: "Jacques Le Roux" <[hidden email]>

> From: <[hidden email]>
>> On Jan 5, 2013, at 1:47 PM, Jacques Le Roux <[hidden email]> wrote:
>>
>>> From: "Ean Schuessler" <[hidden email]>
>>>> I don't know that its much worse. On GitHub you will see the forks and could track their changes if you wanted.
>>>> I think the complication with handing out SVN branches is that we will end up with a lot of low quality branches in the core repository.
>>>
>>> Depends, if committer/s follow/s the work closely then it can be a could way to share until the work is finished. I don't see what GitHub adds to this.
>>>
>>>> The nice thing about GIT is that the chaff doesn't get into the wheat bucket.
>>>
>>> Don't make sense to me. In svn branches in OFBiz repo if the work is of low quality, and dropping a branch is only few clicks.
>>> If the work is of low quality in GitHub it will be ignored as well.
>>>
>>> If the work is of good quality, why wait to have it in GitHub in the meantime and not directly in a svn branch?
>>>
>>> I still really don't see what GitHub brings here... apart (for me at leat) learning to use Git
>>
>> Can we even restrict commit access to branches in the ASF SVN any more? We moved away from restricted access to framework versus applications a long time ago due to pressure from infra/others, and I'm not sure if we can so easily make someone a committer to just a branch.
>
> I'd have to check that, but I believe once well (and very politely ;o) explained it should be possible to convince them
>
>> With GitHub we don't need to do anything, anyone can create a public or private fork of OFBiz and change it all they want. People can also still extract patches across multiple commits so it's not so much work to apply them. It's really a much better approach.
>
> Of course, as you said it's already there, so we have nothing to do, nothing happens.
>
> Jacques
>
>> -David
>>
>

[Olivier.heintz]

Very clear and efficient

Le 07/01/2013 09:20, Jacopo Cappellato a écrit :
> Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:
>
> * svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
> * however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
+1
> * we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
+1
> * the official releases (and release branches) will not contain the specialpurpose folder
+1
> * we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
+1
> * key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...
+1
maybe it will be necessary in future to decide how to process when a
component in specialpurpose has junit and selenium test for all functions
>
> The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
> a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)
+1
> b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)
+1
>
> Some clarifications:
> * we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
> * we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose
+1
>
> As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.
>
> What do you think?
Completely agree
even if I would have liked a little note on the notion addon (smaller
than a component) :-)

>
> Jacopo
>
> On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
>
>> Yes thanks!
>>
>> Jacques
>>
>> From: "Jacopo Cappellato" <[hidden email]>
>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>
>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>> Do you mean the following?
>>>
>>> ========================
>>> BTW, some time ago I also proposed an alternative path: see email with subject "[PROPOSAL] from specialpurpose to extras": to that I can add that we could provide two set of ant scripts, one similar to the one we have that builds/tests everything (framework+applications+specialpurpose) and one (the default) that only builds/tests the framework+applications; the release branches may only contain the framework+applications and separate releases of specialpurpose applications could be voted/released at different time. This approach may reach two goals:
>>> 1) slim down the "main" code that the community is more focused to improve/maintain/release
>>> 2) keep under the OFBiz community the ownership of all the other specialpurpose components; if one of them will get more attention and interest and could grow in quality or it is generic enough we could decide to move it to the release branch (maybe move it to applications)
>>> ========================
>>>
>>> Jacopo
>>>
>>>
>

[Malin Nicolas]

Hi Jacopo,
Your solution is a good pragmatism and give a clear work to do for
contributors

If other people are ok with your proposition, I will try to find a
solution to activate a component with ant.

PS : My apologies for the latency

Nicolas



Le 07/01/2013 09:20, Jacopo Cappellato a écrit :

> Let's see if we can move on the slim-down effort in this direction; here is a slightly more detailed proposal:
>
> * svn layout of the project will stay as is now: framework+applications+specialpupose; if you checkout the trunk you will get everything as it is now
> * however all the specialpupose components will be disabled by default; building the project will not build them, running tests will not run the tests on them etc...
> * we will provide easy mechanisms (ant scripts/settings or similar) to enable specialpurpose components; in this way developers interested in testing/working on some specialpurpose components will have an easy way to do this
> * the official releases (and release branches) will not contain the specialpurpose folder
> * we could release specialpurpose components separately ("OFBiz Extra 1.0", 2.0, 3.0 etc...) if there is interest; we could even release individual components if there is interest ("OFBiz Extra - POS 1.0", "OFBiz Extra - Birt 1.0")
> * key point: it will be acceptable to commit code to improve OFBiz even if it breaks some of the specialpurpose components: e.g. API changes, jar updates (duplicated of jars in some specialpurpose components) etc...
>
> The last point is the most important because with it we will reach some important goals that could alleviate the tension/conflicts we had in the past while discussing topics about what should go in OFBiz and what not:
> a) committers will have a core set of common, generic and more frequently used components (framework/applications) to focus on; it will be easier to maintain a smaller codebase and this will speed up the evolution of OFBiz; it will also remove a lot of burden in the release management because we will have less external dependencies to look for for vulnerability reports; for example, if a vulnerability report is reported by the Birt community, and we are distributing the Birt jars in our releases, in the current situation we would be forced to issue a new release (as a side note, I am not even sure if we are keeping an eye on vulnerability reports from all the projects we have pulled jars from)
> b) committers interested in keeping up-to-date some of the specialpurpose components could easily update the code and commit it; over time we will see what are the specialpurpose components that are actively maintained (and we could issue releases for them) and what are the components that are not (and we could discuss if it is worth of keeping them in the trunk or not, but they will not cause any major issues even if they stay there)
>
> Some clarifications:
> * we may want to review over time the list of components currently under specialpurpose; if there is a general consensus in the direction of keeping a few of them in the releases then we could keep them enabled and include them in branches
> * we will have to change something in the way we build the classpath in ant in order to include jars and build the component only if the component is enabled; it should not be difficult to achieve but this is important because it will allow us to have potentially conflicting jars in the framework/applications and specialpurpose
>
> As a roadmap, we could try to implement this approach before the next cut of the 13.04 release branch (in April 2013): that branch could be the first one without the specialpurpose components.
>
> What do you think?
>
> Jacopo
>
> On Dec 31, 2012, at 11:39 AM, Jacques Le Roux wrote:
>
>> Yes thanks!
>>
>> Jacques
>>
>> From: "Jacopo Cappellato" <[hidden email]>
>>> On Dec 16, 2012, at 9:07 AM, Jacques Le Roux wrote:
>>>
>>>> I even wonder if Jacopo did not make a more recent (and flexible) proposition with which I totaly agreed (during fall, it seems to me but, I can't find it), Jacopo?
>>> Do you mean the following?
>>>
>>> ========================
>>> BTW, some time ago I also proposed an alternative path: see email with subject "[PROPOSAL] from specialpurpose to extras": to that I can add that we could provide two set of ant scripts, one similar to the one we have that builds/tests everything (framework+applications+specialpurpose) and one (the default) that only builds/tests the framework+applications; the release branches may only contain the framework+applications and separate releases of specialpurpose applications could be voted/released at different time. This approach may reach two goals:
>>> 1) slim down the "main" code that the community is more focused to improve/maintain/release
>>> 2) keep under the OFBiz community the ownership of all the other specialpurpose components; if one of them will get more attention and interest and could grow in quality or it is generic enough we could decide to move it to the release branch (maybe move it to applications)
>>> ========================
>>>
>>> Jacopo
>>>
>>>