Ways to put back the specialpurpose components in the R13.07 branch

[Jacques Le Roux]

Hi,

Initially I wanted to write a complete email with several concerned points. I changed my mind and prefer to discuss each point in separated emails,
though in the same thread. It will be easier.

The 1st point which comes to my mind is what to exactly put back in release branch.

We can't put the current trunk HEAD state, because we will face the rule which says that we shall not add new features in release branches.  And
obviously there are some since we freezed this branch and moreover few (at least EntityQuery) are blockers. So I guess we should put the state of the
specialpurpose components in trunk when the branch was freezed http://svn.apache.org/viewvc?view=revision&revision=r1505933 and then add the bug fixes
since https://issues.apache.org/jira/issues/?filter=12329808

We cannot rely only on Jira, at least it's a start.

Jacques

[Gil Portenseigne]

Hi,

I think it's the good way to do (not trunk, but branch state) !

Gil

Le 30/11/2014 16:56, Jacques Le Roux a écrit :

> Hi,
>
> Initially I wanted to write a complete email with several concerned
> points. I changed my mind and prefer to discuss each point in
> separated emails, though in the same thread. It will be easier.
>
> The 1st point which comes to my mind is what to exactly put back in
> release branch.
>
> We can't put the current trunk HEAD state, because we will face the
> rule which says that we shall not add new features in release
> branches.  And obviously there are some since we freezed this branch
> and moreover few (at least EntityQuery) are blockers. So I guess we
> should put the state of the specialpurpose components in trunk when
> the branch was freezed
> http://svn.apache.org/viewvc?view=revision&revision=r1505933 and then
> add the bug fixes since
> https://issues.apache.org/jira/issues/?filter=12329808
>
> We cannot rely only on Jira, at least it's a start.
>
> Jacques
>
>
>
>
>

[monica ford]

Hi,
We need specialpurpose components,
specialpurpose components are big asset in Ofbiz.
We can keep them in trunk i belive.
so we can move Component to Current Release.
We can make certain changes so they work.
As for POS Jacques guided the changes to use in Ofbiz13.07
also helped by Mandeep. POS was working.

Monika

[Jacques Le Roux]

I think a bit about this today. There is one alternative. We could decide to let the future R13.07 releases as is the R13.07.01, ie without the
specialpurpose components but ecommerce. And we would freeze a new branch where we would keep some of the specialpurpose components disabled, but not
all, as Jacopo suggested.

Advantages: it's easy to do, we have not to collect and apply the specialpurpose bug fixes in trunk since 12329808. The R13.07 releases will be
consistent, no need to explain to our users what happened between R13.07.01 and R13.07.02
Drawbacks: when we will deliver our next freezed branch releases our users could ask why now some of the specialpurpose components are back. But this
is easy to explain. Of course the R13.07 releases will always miss the specialpurpose components but ecommerce.

We need to face it, removing the specialpurpose components but ecommerce was not a good idea. But putting them back in is a lot of work. So if our
users really want to use the R13.07 releases will some specific the specialpurpose components it would be their own responsibility.

Opinions?

Jacques

Le 30/11/2014 19:02, gil portenseigne a écrit :

> Hi,
>
> I think it's the good way to do (not trunk, but branch state) !
>
> Gil
>
> Le 30/11/2014 16:56, Jacques Le Roux a écrit :
>> Hi,
>>
>> Initially I wanted to write a complete email with several concerned points. I changed my mind and prefer to discuss each point in separated emails,
>> though in the same thread. It will be easier.
>>
>> The 1st point which comes to my mind is what to exactly put back in release branch.
>>
>> We can't put the current trunk HEAD state, because we will face the rule which says that we shall not add new features in release branches.  And
>> obviously there are some since we freezed this branch and moreover few (at least EntityQuery) are blockers. So I guess we should put the state of
>> the specialpurpose components in trunk when the branch was freezed http://svn.apache.org/viewvc?view=revision&revision=r1505933 and then add the
>> bug fixes since https://issues.apache.org/jira/issues/?filter=12329808
>>
>> We cannot rely only on Jira, at least it's a start.
>>
>> Jacques
>>
>>
>>
>>
>>
>
>

[Pierre Smits]

We can cut a release tomorrow including all that was left out of the r13.x
branch. And have a release available to the public within a week. There are
no issues in JIRA that could block it.

And after that we can work on getting consensus on what stays in and what
doesn't.


Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Sat, Dec 13, 2014 at 3:53 PM, Jacques Le Roux <
[hidden email]> wrote:

>
> I think a bit about this today. There is one alternative. We could decide
> to let the future R13.07 releases as is the R13.07.01, ie without the
> specialpurpose components but ecommerce. And we would freeze a new branch
> where we would keep some of the specialpurpose components disabled, but not
> all, as Jacopo suggested.
>
> Advantages: it's easy to do, we have not to collect and apply the
> specialpurpose bug fixes in trunk since 12329808. The R13.07 releases will
> be consistent, no need to explain to our users what happened between
> R13.07.01 and R13.07.02
> Drawbacks: when we will deliver our next freezed branch releases our users
> could ask why now some of the specialpurpose components are back. But this
> is easy to explain. Of course the R13.07 releases will always miss the
> specialpurpose components but ecommerce.
>
> We need to face it, removing the specialpurpose components but ecommerce
> was not a good idea. But putting them back in is a lot of work. So if our
> users really want to use the R13.07 releases will some specific the
> specialpurpose components it would be their own responsibility.
>
> Opinions?
>
> Jacques
>
> Le 30/11/2014 19:02, gil portenseigne a écrit :
>
>  Hi,
>>
>> I think it's the good way to do (not trunk, but branch state) !
>>
>> Gil
>>
>> Le 30/11/2014 16:56, Jacques Le Roux a écrit :
>>
>>> Hi,
>>>
>>> Initially I wanted to write a complete email with several concerned
>>> points. I changed my mind and prefer to discuss each point in separated
>>> emails, though in the same thread. It will be easier.
>>>
>>> The 1st point which comes to my mind is what to exactly put back in
>>> release branch.
>>>
>>> We can't put the current trunk HEAD state, because we will face the rule
>>> which says that we shall not add new features in release branches.  And
>>> obviously there are some since we freezed this branch and moreover few (at
>>> least EntityQuery) are blockers. So I guess we should put the state of the
>>> specialpurpose components in trunk when the branch was freezed
>>> http://svn.apache.org/viewvc?view=revision&revision=r1505933 and then
>>> add the bug fixes since https://issues.apache.org/
>>> jira/issues/?filter=12329808
>>>
>>> We cannot rely only on Jira, at least it's a start.
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>

[Jacques Le Roux]

You mean a new branch as a suggested, or?

Jacques

Le 15/12/2014 02:01, Pierre Smits a écrit :

> We can cut a release tomorrow including all that was left out of the r13.x
> branch. And have a release available to the public within a week. There are
> no issues in JIRA that could block it.
>
> And after that we can work on getting consensus on what stays in and what
> doesn't.
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Sat, Dec 13, 2014 at 3:53 PM, Jacques Le Roux <
> [hidden email]> wrote:
>> I think a bit about this today. There is one alternative. We could decide
>> to let the future R13.07 releases as is the R13.07.01, ie without the
>> specialpurpose components but ecommerce. And we would freeze a new branch
>> where we would keep some of the specialpurpose components disabled, but not
>> all, as Jacopo suggested.
>>
>> Advantages: it's easy to do, we have not to collect and apply the
>> specialpurpose bug fixes in trunk since 12329808. The R13.07 releases will
>> be consistent, no need to explain to our users what happened between
>> R13.07.01 and R13.07.02
>> Drawbacks: when we will deliver our next freezed branch releases our users
>> could ask why now some of the specialpurpose components are back. But this
>> is easy to explain. Of course the R13.07 releases will always miss the
>> specialpurpose components but ecommerce.
>>
>> We need to face it, removing the specialpurpose components but ecommerce
>> was not a good idea. But putting them back in is a lot of work. So if our
>> users really want to use the R13.07 releases will some specific the
>> specialpurpose components it would be their own responsibility.
>>
>> Opinions?
>>
>> Jacques
>>
>> Le 30/11/2014 19:02, gil portenseigne a écrit :
>>
>>   Hi,
>>> I think it's the good way to do (not trunk, but branch state) !
>>>
>>> Gil
>>>
>>> Le 30/11/2014 16:56, Jacques Le Roux a écrit :
>>>
>>>> Hi,
>>>>
>>>> Initially I wanted to write a complete email with several concerned
>>>> points. I changed my mind and prefer to discuss each point in separated
>>>> emails, though in the same thread. It will be easier.
>>>>
>>>> The 1st point which comes to my mind is what to exactly put back in
>>>> release branch.
>>>>
>>>> We can't put the current trunk HEAD state, because we will face the rule
>>>> which says that we shall not add new features in release branches.  And
>>>> obviously there are some since we freezed this branch and moreover few (at
>>>> least EntityQuery) are blockers. So I guess we should put the state of the
>>>> specialpurpose components in trunk when the branch was freezed
>>>> http://svn.apache.org/viewvc?view=revision&revision=r1505933 and then
>>>> add the bug fixes since https://issues.apache.org/
>>>> jira/issues/?filter=12329808
>>>>
>>>> We cannot rely only on Jira, at least it's a start.
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>

[Jacques Le Roux]

The last possibility is to put the EntityQuery stuff in the specialpurpose components took at the revision I said, I guess it's the only blocking new
feature, small and safe exception...

Jacques

Le 15/12/2014 06:36, Jacques Le Roux a écrit :

> You mean a new branch as a suggested, or?
>
> Jacques
>
> Le 15/12/2014 02:01, Pierre Smits a écrit :
>> We can cut a release tomorrow including all that was left out of the r13.x
>> branch. And have a release available to the public within a week. There are
>> no issues in JIRA that could block it.
>>
>> And after that we can work on getting consensus on what stays in and what
>> doesn't.
>>
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Sat, Dec 13, 2014 at 3:53 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>> I think a bit about this today. There is one alternative. We could decide
>>> to let the future R13.07 releases as is the R13.07.01, ie without the
>>> specialpurpose components but ecommerce. And we would freeze a new branch
>>> where we would keep some of the specialpurpose components disabled, but not
>>> all, as Jacopo suggested.
>>>
>>> Advantages: it's easy to do, we have not to collect and apply the
>>> specialpurpose bug fixes in trunk since 12329808. The R13.07 releases will
>>> be consistent, no need to explain to our users what happened between
>>> R13.07.01 and R13.07.02
>>> Drawbacks: when we will deliver our next freezed branch releases our users
>>> could ask why now some of the specialpurpose components are back. But this
>>> is easy to explain. Of course the R13.07 releases will always miss the
>>> specialpurpose components but ecommerce.
>>>
>>> We need to face it, removing the specialpurpose components but ecommerce
>>> was not a good idea. But putting them back in is a lot of work. So if our
>>> users really want to use the R13.07 releases will some specific the
>>> specialpurpose components it would be their own responsibility.
>>>
>>> Opinions?
>>>
>>> Jacques
>>>
>>> Le 30/11/2014 19:02, gil portenseigne a écrit :
>>>
>>>   Hi,
>>>> I think it's the good way to do (not trunk, but branch state) !
>>>>
>>>> Gil
>>>>
>>>> Le 30/11/2014 16:56, Jacques Le Roux a écrit :
>>>>
>>>>> Hi,
>>>>>
>>>>> Initially I wanted to write a complete email with several concerned
>>>>> points. I changed my mind and prefer to discuss each point in separated
>>>>> emails, though in the same thread. It will be easier.
>>>>>
>>>>> The 1st point which comes to my mind is what to exactly put back in
>>>>> release branch.
>>>>>
>>>>> We can't put the current trunk HEAD state, because we will face the rule
>>>>> which says that we shall not add new features in release branches.  And
>>>>> obviously there are some since we freezed this branch and moreover few (at
>>>>> least EntityQuery) are blockers. So I guess we should put the state of the
>>>>> specialpurpose components in trunk when the branch was freezed
>>>>> http://svn.apache.org/viewvc?view=revision&revision=r1505933 and then
>>>>> add the bug fixes since https://issues.apache.org/
>>>>> jira/issues/?filter=12329808
>>>>>
>>>>> We cannot rely only on Jira, at least it's a start.
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>

[Jacques Le Roux]

I think we need to make a decision about this. Let me summarize the alternatives I proposed:

1. Put the state of the specialpurpose components in trunk when the branch was freezed r1505933 and then add the bug fixes since
https://issues.apache.org/jira/issues/?filter=12329808
2. let the future R13.07 releases as is the R13.07.01, ie without the specialpurpose components but ecommerce.
3. Put the EntityQuery stuff in the specialpurpose components took at the revision I said, and put back the relevant components (to be defined, who
cares about ebay and google for instance?)

The 1st alternative is obviously the more professional solution but it's heavy. The 3rd alternative is easier and safer (less changes) but it break
the rules of no new features in released packages. Nobody like the 2nd alternative it seems.

Jacques


Le 15/12/2014 09:37, Jacques Le Roux a écrit :

> The last possibility is to put the EntityQuery stuff in the specialpurpose components took at the revision I said, I guess it's the only blocking
> new feature, small and safe exception...
>
> Jacques
>
> Le 15/12/2014 06:36, Jacques Le Roux a écrit :
>> You mean a new branch as a suggested, or?
>>
>> Jacques
>>
>> Le 15/12/2014 02:01, Pierre Smits a écrit :
>>> We can cut a release tomorrow including all that was left out of the r13.x
>>> branch. And have a release available to the public within a week. There are
>>> no issues in JIRA that could block it.
>>>
>>> And after that we can work on getting consensus on what stays in and what
>>> doesn't.
>>>
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Sat, Dec 13, 2014 at 3:53 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>> I think a bit about this today. There is one alternative. We could decide
>>>> to let the future R13.07 releases as is the R13.07.01, ie without the
>>>> specialpurpose components but ecommerce. And we would freeze a new branch
>>>> where we would keep some of the specialpurpose components disabled, but not
>>>> all, as Jacopo suggested.
>>>>
>>>> Advantages: it's easy to do, we have not to collect and apply the
>>>> specialpurpose bug fixes in trunk since 12329808. The R13.07 releases will
>>>> be consistent, no need to explain to our users what happened between
>>>> R13.07.01 and R13.07.02
>>>> Drawbacks: when we will deliver our next freezed branch releases our users
>>>> could ask why now some of the specialpurpose components are back. But this
>>>> is easy to explain. Of course the R13.07 releases will always miss the
>>>> specialpurpose components but ecommerce.
>>>>
>>>> We need to face it, removing the specialpurpose components but ecommerce
>>>> was not a good idea. But putting them back in is a lot of work. So if our
>>>> users really want to use the R13.07 releases will some specific the
>>>> specialpurpose components it would be their own responsibility.
>>>>
>>>> Opinions?
>>>>
>>>> Jacques
>>>>
>>>> Le 30/11/2014 19:02, gil portenseigne a écrit :
>>>>
>>>>   Hi,
>>>>> I think it's the good way to do (not trunk, but branch state) !
>>>>>
>>>>> Gil
>>>>>
>>>>> Le 30/11/2014 16:56, Jacques Le Roux a écrit :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Initially I wanted to write a complete email with several concerned
>>>>>> points. I changed my mind and prefer to discuss each point in separated
>>>>>> emails, though in the same thread. It will be easier.
>>>>>>
>>>>>> The 1st point which comes to my mind is what to exactly put back in
>>>>>> release branch.
>>>>>>
>>>>>> We can't put the current trunk HEAD state, because we will face the rule
>>>>>> which says that we shall not add new features in release branches.  And
>>>>>> obviously there are some since we freezed this branch and moreover few (at
>>>>>> least EntityQuery) are blockers. So I guess we should put the state of the
>>>>>> specialpurpose components in trunk when the branch was freezed
>>>>>> http://svn.apache.org/viewvc?view=revision&revision=r1505933 and then
>>>>>> add the bug fixes since https://issues.apache.org/
>>>>>> jira/issues/?filter=12329808
>>>>>>
>>>>>> We cannot rely only on Jira, at least it's a start.
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>

[Jacopo Cappellato-4]

On Jan 7, 2015, at 11:13 AM, Jacques Le Roux <[hidden email]> wrote:

> Nobody like the 2nd alternative it seems.

?

Jacopo

[Ron Wheeler]

4) Cut the special purpose loose and let interested parties set up
sub-projects to work on them and release versions of individual special
purpose projects as required to support new releases of the trunk.
Focus on getting the core and framework into a stable well documented
product with:
- a clear roadmap,
- frequent releases of production quality code that most people are
running in production
- a clear documented process for adding new special purpose modules or
user customizations
and work towards a community that is not running private forks of the
trunk because the releases are not usable in production and do not get
new bug fix releases in a suitable timeframe.

The support of special purpose modules will be up to the community that
wants to use them.

Ron

On 07/01/2015 5:13 AM, Jacques Le Roux wrote:

> I think we need to make a decision about this. Let me summarize the
> alternatives I proposed:
>
> 1. Put the state of the specialpurpose components in trunk when the
> branch was freezed r1505933 and then add the bug fixes since
> https://issues.apache.org/jira/issues/?filter=12329808
> 2. let the future R13.07 releases as is the R13.07.01, ie without the
> specialpurpose components but ecommerce.
> 3. Put the EntityQuery stuff in the specialpurpose components took at
> the revision I said, and put back the relevant components (to be
> defined, who cares about ebay and google for instance?)
>
> The 1st alternative is obviously the more professional solution but
> it's heavy. The 3rd alternative is easier and safer (less changes) but
> it break the rules of no new features in released packages. Nobody
> like the 2nd alternative it seems.
>
> Jacques
>
>
> Le 15/12/2014 09:37, Jacques Le Roux a écrit :
>> The last possibility is to put the EntityQuery stuff in the
>> specialpurpose components took at the revision I said, I guess it's
>> the only blocking new feature, small and safe exception...
>>
>> Jacques
>>
>> Le 15/12/2014 06:36, Jacques Le Roux a écrit :
>>> You mean a new branch as a suggested, or?
>>>
>>> Jacques
>>>
>>> Le 15/12/2014 02:01, Pierre Smits a écrit :
>>>> We can cut a release tomorrow including all that was left out of
>>>> the r13.x
>>>> branch. And have a release available to the public within a week.
>>>> There are
>>>> no issues in JIRA that could block it.
>>>>
>>>> And after that we can work on getting consensus on what stays in
>>>> and what
>>>> doesn't.
>>>>
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>> On Sat, Dec 13, 2014 at 3:53 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>> I think a bit about this today. There is one alternative. We could
>>>>> decide
>>>>> to let the future R13.07 releases as is the R13.07.01, ie without the
>>>>> specialpurpose components but ecommerce. And we would freeze a new
>>>>> branch
>>>>> where we would keep some of the specialpurpose components
>>>>> disabled, but not
>>>>> all, as Jacopo suggested.
>>>>>
>>>>> Advantages: it's easy to do, we have not to collect and apply the
>>>>> specialpurpose bug fixes in trunk since 12329808. The R13.07
>>>>> releases will
>>>>> be consistent, no need to explain to our users what happened between
>>>>> R13.07.01 and R13.07.02
>>>>> Drawbacks: when we will deliver our next freezed branch releases
>>>>> our users
>>>>> could ask why now some of the specialpurpose components are back.
>>>>> But this
>>>>> is easy to explain. Of course the R13.07 releases will always miss
>>>>> the
>>>>> specialpurpose components but ecommerce.
>>>>>
>>>>> We need to face it, removing the specialpurpose components but
>>>>> ecommerce
>>>>> was not a good idea. But putting them back in is a lot of work. So
>>>>> if our
>>>>> users really want to use the R13.07 releases will some specific the
>>>>> specialpurpose components it would be their own responsibility.
>>>>>
>>>>> Opinions?
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 30/11/2014 19:02, gil portenseigne a écrit :
>>>>>
>>>>>   Hi,
>>>>>> I think it's the good way to do (not trunk, but branch state) !
>>>>>>
>>>>>> Gil
>>>>>>
>>>>>> Le 30/11/2014 16:56, Jacques Le Roux a écrit :
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Initially I wanted to write a complete email with several concerned
>>>>>>> points. I changed my mind and prefer to discuss each point in
>>>>>>> separated
>>>>>>> emails, though in the same thread. It will be easier.
>>>>>>>
>>>>>>> The 1st point which comes to my mind is what to exactly put back in
>>>>>>> release branch.
>>>>>>>
>>>>>>> We can't put the current trunk HEAD state, because we will face
>>>>>>> the rule
>>>>>>> which says that we shall not add new features in release
>>>>>>> branches.  And
>>>>>>> obviously there are some since we freezed this branch and
>>>>>>> moreover few (at
>>>>>>> least EntityQuery) are blockers. So I guess we should put the
>>>>>>> state of the
>>>>>>> specialpurpose components in trunk when the branch was freezed
>>>>>>> http://svn.apache.org/viewvc?view=revision&revision=r1505933 and
>>>>>>> then
>>>>>>> add the bug fixes since https://issues.apache.org/
>>>>>>> jira/issues/?filter=12329808
>>>>>>>
>>>>>>> We cannot rely only on Jira, at least it's a start.
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Jacques Le Roux]

Le 07/01/2015 12:47, Jacopo Cappellato a écrit :
> On Jan 7, 2015, at 11:13 AM, Jacques Le Roux <[hidden email]> wrote:
>
>> Nobody like the 2nd alternative it seems.
> ?

It's obvious we (the OFBIz community) are missing some components in specialpurpose. Maybe not all...
A fact proves that: they are back in R14.12

Jacques

>
> Jacopo
>

[Jacopo Cappellato-4]

On Jan 7, 2015, at 3:56 PM, Jacques Le Roux <[hidden email]> wrote:

>
> Le 07/01/2015 12:47, Jacopo Cappellato a écrit :
>> On Jan 7, 2015, at 11:13 AM, Jacques Le Roux <[hidden email]> wrote:
>>
>>> Nobody like the 2nd alternative it seems.
>> ?
>
> It's obvious we (the OFBIz community) are missing some components in specialpurpose.

It isn't "obvious": unless you think to represent "the OFBiz community".

> Maybe not all...
> A fact proves that: they are back in R14.12

This doesn't prove anything: I have been the one that proposed to include them (even if temporarily) in order to facilitate the work of the committers (backporting) but we are still discussing this and they may stay or go away; most of all, they will probably not be part of any release.

Jacopo

>
> Jacques
>
>>
>> Jacopo
>>

[Jacques Le Roux]

Le 07/01/2015 16:59, Jacopo Cappellato a écrit :

> On Jan 7, 2015, at 3:56 PM, Jacques Le Roux <[hidden email]> wrote:
>
>> Le 07/01/2015 12:47, Jacopo Cappellato a écrit :
>>> On Jan 7, 2015, at 11:13 AM, Jacques Le Roux <[hidden email]> wrote:
>>>
>>>> Nobody like the 2nd alternative it seems.
>>> ?
>> It's obvious we (the OFBIz community) are missing some components in specialpurpose.
> It isn't "obvious": unless you think to represent "the OFBiz community".
>
>> Maybe not all...
>> A fact proves that: they are back in R14.12
> This doesn't prove anything: I have been the one that proposed to include them (even if temporarily) in order to facilitate the work of the committers (backporting) but we are still discussing this and they may stay or go away; most of all, they will probably not be part of any release.

Do you <<think "you" represent "the OFBiz community" >> ?

Jacques

>
> Jacopo
>
>> Jacques
>>
>>> Jacopo
>>>
>
>

[Ron Wheeler]

This is the kind of discussion that I am hoping to avoid with option 4.

Let the community decide and show their choice by a willingness to
support the components that "the OFBiz Community" wants to keep.

If a component does not need enhancement and can run as is in 13.x.x or
there is no one who wants to run 13.x.x with a certain component, then
why waste resources porting it or worrying about it until individuals
from the community steps forward and says "I need module xxx and am
willing to help support it".

The other options seem to invite this kind of contentious speculation
where people who care about the core and framework are wasting time
trying to guess the needs of the community for various modules.

Once you make this policy decision and remove the special purpose from
the core and framework project, we can start to look at individual
modules and see who will support what.
I gather that some will get support right away and sub-projects will be
set up within days with people who are committed to making these work
(ecommerce, project management seem to have interested parties already).

Ron

On 07/01/2015 10:59 AM, Jacopo Cappellato wrote:

> On Jan 7, 2015, at 3:56 PM, Jacques Le Roux <[hidden email]> wrote:
>
>> Le 07/01/2015 12:47, Jacopo Cappellato a écrit :
>>> On Jan 7, 2015, at 11:13 AM, Jacques Le Roux <[hidden email]> wrote:
>>>
>>>> Nobody like the 2nd alternative it seems.
>>> ?
>> It's obvious we (the OFBIz community) are missing some components in specialpurpose.
> It isn't "obvious": unless you think to represent "the OFBiz community".
>
>> Maybe not all...
>> A fact proves that: they are back in R14.12
> This doesn't prove anything: I have been the one that proposed to include them (even if temporarily) in order to facilitate the work of the committers (backporting) but we are still discussing this and they may stay or go away; most of all, they will probably not be part of any release.
>
> Jacopo
>
>> Jacques
>>
>>> Jacopo
>>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Jacques Le Roux]

The raw question is "should we put back the specialpurpose components back in R13.07 or not?"

It's not planning something new here, just cleaning our mess!

Jacques

Le 07/01/2015 17:28, Ron Wheeler a écrit :

> This is the kind of discussion that I am hoping to avoid with option 4.
>
> Let the community decide and show their choice by a willingness to support the components that "the OFBiz Community" wants to keep.
>
> If a component does not need enhancement and can run as is in 13.x.x or there is no one who wants to run 13.x.x with a certain component, then why
> waste resources porting it or worrying about it until individuals from the community steps forward and says "I need module xxx and am willing to
> help support it".
>
> The other options seem to invite this kind of contentious speculation where people who care about the core and framework are wasting time trying to
> guess the needs of the community for various modules.
>
> Once you make this policy decision and remove the special purpose from the core and framework project, we can start to look at individual modules
> and see who will support what.
> I gather that some will get support right away and sub-projects will be set up within days with people who are committed to making these work
> (ecommerce, project management seem to have interested parties already).
>
> Ron
>
> On 07/01/2015 10:59 AM, Jacopo Cappellato wrote:
>> On Jan 7, 2015, at 3:56 PM, Jacques Le Roux <[hidden email]> wrote:
>>
>>> Le 07/01/2015 12:47, Jacopo Cappellato a écrit :
>>>> On Jan 7, 2015, at 11:13 AM, Jacques Le Roux <[hidden email]> wrote:
>>>>
>>>>> Nobody like the 2nd alternative it seems.
>>>> ?
>>> It's obvious we (the OFBIz community) are missing some components in specialpurpose.
>> It isn't "obvious": unless you think to represent "the OFBiz community".
>>
>>> Maybe not all...
>>> A fact proves that: they are back in R14.12
>> This doesn't prove anything: I have been the one that proposed to include them (even if temporarily) in order to facilitate the work of the
>> committers (backporting) but we are still discussing this and they may stay or go away; most of all, they will probably not be part of any release.
>>
>> Jacopo
>>
>>> Jacques
>>>
>>>> Jacopo
>>>>
>>
>
>

[Jacopo Cappellato-4]

On Jan 7, 2015, at 5:22 PM, Jacques Le Roux <[hidden email]> wrote:

> Do you <<think "you" represent "the OFBiz community" >> ?

I don't, in fact I am just expressing my own opinion: there are people that agree with me and people that do not agree with me.
You should do the same instead of writing:
"It's obvious we (the OFBIz community) are missing some components in specialpurpose"
or
"Nobody like the 2nd alternative it seems."

Jacopo

[Jacques Le Roux]

Ha OK, I see, I was biased indeed. I still believe we miss them :p

Jacques

Le 07/01/2015 17:55, Jacopo Cappellato a écrit :

> On Jan 7, 2015, at 5:22 PM, Jacques Le Roux <[hidden email]> wrote:
>
>> Do you <<think "you" represent "the OFBiz community" >> ?
> I don't, in fact I am just expressing my own opinion: there are people that agree with me and people that do not agree with me.
> You should do the same instead of writing:
> "It's obvious we (the OFBIz community) are missing some components in specialpurpose"
> or
> "Nobody like the 2nd alternative it seems."
>
> Jacopo
>
>
>

[Ron Wheeler]

I would say "no" if that is the only question being asked.

We can have the discussion about how to support individual modules later
if you want to do it in 2 steps.

Ron

On 07/01/2015 11:43 AM, Jacques Le Roux wrote:

> The raw question is "should we put back the specialpurpose components
> back in R13.07 or not?"
>
> It's not planning something new here, just cleaning our mess!
>
> Jacques
>
> Le 07/01/2015 17:28, Ron Wheeler a écrit :
>> This is the kind of discussion that I am hoping to avoid with option 4.
>>
>> Let the community decide and show their choice by a willingness to
>> support the components that "the OFBiz Community" wants to keep.
>>
>> If a component does not need enhancement and can run as is in 13.x.x
>> or there is no one who wants to run 13.x.x with a certain component,
>> then why waste resources porting it or worrying about it until
>> individuals from the community steps forward and says "I need module
>> xxx and am willing to help support it".
>>
>> The other options seem to invite this kind of contentious speculation
>> where people who care about the core and framework are wasting time
>> trying to guess the needs of the community for various modules.
>>
>> Once you make this policy decision and remove the special purpose
>> from the core and framework project, we can start to look at
>> individual modules and see who will support what.
>> I gather that some will get support right away and sub-projects will
>> be set up within days with people who are committed to making these
>> work (ecommerce, project management seem to have interested parties
>> already).
>>
>> Ron
>>
>> On 07/01/2015 10:59 AM, Jacopo Cappellato wrote:
>>> On Jan 7, 2015, at 3:56 PM, Jacques Le Roux
>>> <[hidden email]> wrote:
>>>
>>>> Le 07/01/2015 12:47, Jacopo Cappellato a écrit :
>>>>> On Jan 7, 2015, at 11:13 AM, Jacques Le Roux
>>>>> <[hidden email]> wrote:
>>>>>
>>>>>> Nobody like the 2nd alternative it seems.
>>>>> ?
>>>> It's obvious we (the OFBIz community) are missing some components
>>>> in specialpurpose.
>>> It isn't "obvious": unless you think to represent "the OFBiz
>>> community".
>>>
>>>> Maybe not all...
>>>> A fact proves that: they are back in R14.12
>>> This doesn't prove anything: I have been the one that proposed to
>>> include them (even if temporarily) in order to facilitate the work
>>> of the committers (backporting) but we are still discussing this and
>>> they may stay or go away; most of all, they will probably not be
>>> part of any release.
>>>
>>> Jacopo
>>>
>>>> Jacques
>>>>
>>>>> Jacopo
>>>>>
>>>
>>
>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Jacques Le Roux]

So you prefer R13.01 w/ only the ecommerce component in specialpurpose, why?

Jacques

Le 07/01/2015 20:32, Ron Wheeler a écrit :

> I would say "no" if that is the only question being asked.
>
> We can have the discussion about how to support individual modules later if you want to do it in 2 steps.
>
> Ron
>
> On 07/01/2015 11:43 AM, Jacques Le Roux wrote:
>> The raw question is "should we put back the specialpurpose components back in R13.07 or not?"
>>
>> It's not planning something new here, just cleaning our mess!
>>
>> Jacques
>>
>> Le 07/01/2015 17:28, Ron Wheeler a écrit :
>>> This is the kind of discussion that I am hoping to avoid with option 4.
>>>
>>> Let the community decide and show their choice by a willingness to support the components that "the OFBiz Community" wants to keep.
>>>
>>> If a component does not need enhancement and can run as is in 13.x.x or there is no one who wants to run 13.x.x with a certain component, then why
>>> waste resources porting it or worrying about it until individuals from the community steps forward and says "I need module xxx and am willing to
>>> help support it".
>>>
>>> The other options seem to invite this kind of contentious speculation where people who care about the core and framework are wasting time trying
>>> to guess the needs of the community for various modules.
>>>
>>> Once you make this policy decision and remove the special purpose from the core and framework project, we can start to look at individual modules
>>> and see who will support what.
>>> I gather that some will get support right away and sub-projects will be set up within days with people who are committed to making these work
>>> (ecommerce, project management seem to have interested parties already).
>>>
>>> Ron
>>>
>>> On 07/01/2015 10:59 AM, Jacopo Cappellato wrote:
>>>> On Jan 7, 2015, at 3:56 PM, Jacques Le Roux <[hidden email]> wrote:
>>>>
>>>>> Le 07/01/2015 12:47, Jacopo Cappellato a écrit :
>>>>>> On Jan 7, 2015, at 11:13 AM, Jacques Le Roux <[hidden email]> wrote:
>>>>>>
>>>>>>> Nobody like the 2nd alternative it seems.
>>>>>> ?
>>>>> It's obvious we (the OFBIz community) are missing some components in specialpurpose.
>>>> It isn't "obvious": unless you think to represent "the OFBiz community".
>>>>
>>>>> Maybe not all...
>>>>> A fact proves that: they are back in R14.12
>>>> This doesn't prove anything: I have been the one that proposed to include them (even if temporarily) in order to facilitate the work of the
>>>> committers (backporting) but we are still discussing this and they may stay or go away; most of all, they will probably not be part of any release.
>>>>
>>>> Jacopo
>>>>
>>>>> Jacques
>>>>>
>>>>>> Jacopo
>>>>>>
>>>>
>>>
>>>
>>
>
>

[Ron Wheeler]

It will move the project forward towards more community involvement if
the core and framework get the attention that they need and the non-core
modules are free to attract their own following and start to have
independent lives with independent roadmaps, release schedules and
communities within the Apache OFBiz umbrella.

If someone wants the project management module to run under 13.07.x,
then they can assemble a team, fix it and release a PM module that is
guaranteed by them to work with 13.07.x. or pay someone to do it.
If no one cares, why should the core team spend time on it.

It also avoids the contentious and someone demoralizing arguments about
"who represents the community" for these peripheral modules.
Save the fights and energy for the core and framework roadmap.

My feeling is that OFBiz is too big a project and needs to be broken
down into manageable chunks that can be run in a more transparent and
planned way.

Splitting out modules that do not affect the core will help in a number
of ways.
- force the framework team to be more transparent and have a clear plan
about what new functionality is coming and when.
- force the core team to look at extensibility in a transparent way -
what is immutable within a release, what are the immutable APIs, what is
the process to get an enhancement included in the roadmap,
- allow the core to get a more frequent release pattern by reducing the
number of things that have to be done to get a release out. I would like
to get people actually running releases not having everyone forced to
build and test their own versions to get the last year's worth of bug
fixes. If there was a monthly or bi-monthly release pattern with
emergency releases for security bugs, adoption would be a lot easier.
- focus everyone on how extensions must be constructed to play nicely
with the core and each other.
- allow expertise to be developed in sub-projects that are small enough
for new developers to start without compromising the core. OFBiz is a
big chunk to chew on.
This will also force each group to offer its own warranty which is a big
job in the current structure and contributes to the slow release schedule.
- allow the core team to get focused on the core and not get distracted
by all kinds of requests for special purpose modules

and so on.

Ron

On 07/01/2015 4:03 PM, Jacques Le Roux wrote:

> So you prefer R13.01 w/ only the ecommerce component in
> specialpurpose, why?
>
> Jacques
>
> Le 07/01/2015 20:32, Ron Wheeler a écrit :
>> I would say "no" if that is the only question being asked.
>>
>> We can have the discussion about how to support individual modules
>> later if you want to do it in 2 steps.
>>
>> Ron
>>
>> On 07/01/2015 11:43 AM, Jacques Le Roux wrote:
>>> The raw question is "should we put back the specialpurpose
>>> components back in R13.07 or not?"
>>>
>>> It's not planning something new here, just cleaning our mess!
>>>
>>> Jacques
>>>
>>> Le 07/01/2015 17:28, Ron Wheeler a écrit :
>>>> This is the kind of discussion that I am hoping to avoid with
>>>> option 4.
>>>>
>>>> Let the community decide and show their choice by a willingness to
>>>> support the components that "the OFBiz Community" wants to keep.
>>>>
>>>> If a component does not need enhancement and can run as is in
>>>> 13.x.x or there is no one who wants to run 13.x.x with a certain
>>>> component, then why waste resources porting it or worrying about it
>>>> until individuals from the community steps forward and says "I need
>>>> module xxx and am willing to help support it".
>>>>
>>>> The other options seem to invite this kind of contentious
>>>> speculation where people who care about the core and framework are
>>>> wasting time trying to guess the needs of the community for various
>>>> modules.
>>>>
>>>> Once you make this policy decision and remove the special purpose
>>>> from the core and framework project, we can start to look at
>>>> individual modules and see who will support what.
>>>> I gather that some will get support right away and sub-projects
>>>> will be set up within days with people who are committed to making
>>>> these work (ecommerce, project management seem to have interested
>>>> parties already).
>>>>
>>>> Ron
>>>>
>>>> On 07/01/2015 10:59 AM, Jacopo Cappellato wrote:
>>>>> On Jan 7, 2015, at 3:56 PM, Jacques Le Roux
>>>>> <[hidden email]> wrote:
>>>>>
>>>>>> Le 07/01/2015 12:47, Jacopo Cappellato a écrit :
>>>>>>> On Jan 7, 2015, at 11:13 AM, Jacques Le Roux
>>>>>>> <[hidden email]> wrote:
>>>>>>>
>>>>>>>> Nobody like the 2nd alternative it seems.
>>>>>>> ?
>>>>>> It's obvious we (the OFBIz community) are missing some components
>>>>>> in specialpurpose.
>>>>> It isn't "obvious": unless you think to represent "the OFBiz
>>>>> community".
>>>>>
>>>>>> Maybe not all...
>>>>>> A fact proves that: they are back in R14.12
>>>>> This doesn't prove anything: I have been the one that proposed to
>>>>> include them (even if temporarily) in order to facilitate the work
>>>>> of the committers (backporting) but we are still discussing this
>>>>> and they may stay or go away; most of all, they will probably not
>>>>> be part of any release.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102