Plan for the creation of the new branch (13.04?)

[Jacopo Cappellato-4]

Are we ready to create the new branch or we want to postpone it?

Based on what we discussed recently, the plan could be the following:
* before the end of April, create a branch (13.04) as a snapshot of the trunk and without all specialpurpose components (except the ecommerce component that will be included for the dependencies we have on it)
** alternatively, we could postpone the creation of the branch (to May?), if there are ongoing efforts that we would like to include in the branch; we could still name the branch 13.04 or create it as 13.05

If we are ok with this plan I will take care of the creation of the branch before the end of April.

Jacopo

[Adrian Crum-3]

I would like to postpone creation of the branch until I finish fixing
the entity condition cache problems. I should have it finished this weekend.

If we create the branch in May, then I think the branch should be
labeled according to the pattern we agreed upon earlier - 13.05.

-Adrian

On 4/24/2013 9:01 AM, Jacopo Cappellato wrote:
> Are we ready to create the new branch or we want to postpone it?
>
> Based on what we discussed recently, the plan could be the following:
> * before the end of April, create a branch (13.04) as a snapshot of the trunk and without all specialpurpose components (except the ecommerce component that will be included for the dependencies we have on it)
> ** alternatively, we could postpone the creation of the branch (to May?), if there are ongoing efforts that we would like to include in the branch; we could still name the branch 13.04 or create it as 13.05
>
> If we are ok with this plan I will take care of the creation of the branch before the end of April.
>
> Jacopo

[Jacques Le Roux]

Agreed on the plan. Indeed if in may, 13.05 should be the way.
Just to say: I will not be available (vacation) at the end of week and next week. Anyway I have nothing pending.

Jacques

From: "Adrian Crum" <[hidden email]>

>I would like to postpone creation of the branch until I finish fixing
> the entity condition cache problems. I should have it finished this weekend.
>
> If we create the branch in May, then I think the branch should be
> labeled according to the pattern we agreed upon earlier - 13.05.
>
> -Adrian
>
> On 4/24/2013 9:01 AM, Jacopo Cappellato wrote:
>> Are we ready to create the new branch or we want to postpone it?
>>
>> Based on what we discussed recently, the plan could be the following:
>> * before the end of April, create a branch (13.04) as a snapshot of the trunk and without all specialpurpose components (except the ecommerce component that will be included for the dependencies we have on it)
>> ** alternatively, we could postpone the creation of the branch (to May?), if there are ongoing efforts that we would like to include in the branch; we could still name the branch 13.04 or create it as 13.05
>>
>> If we are ok with this plan I will take care of the creation of the branch before the end of April.
>>
>> Jacopo
>

[Jacopo Cappellato-4]

It sounds like a plan; we will postpone the decision of a few weeks and we will probably create the new branch 13.05 in May.

Jacopo


On Apr 24, 2013, at 10:49 AM, Jacques Le Roux <[hidden email]> wrote:

> Agreed on the plan. Indeed if in may, 13.05 should be the way.
> Just to say: I will not be available (vacation) at the end of week and next week. Anyway I have nothing pending.
>
> Jacques
>
> From: "Adrian Crum" <[hidden email]>
>> I would like to postpone creation of the branch until I finish fixing
>> the entity condition cache problems. I should have it finished this weekend.
>>
>> If we create the branch in May, then I think the branch should be
>> labeled according to the pattern we agreed upon earlier - 13.05.
>>
>> -Adrian
>>
>> On 4/24/2013 9:01 AM, Jacopo Cappellato wrote:
>>> Are we ready to create the new branch or we want to postpone it?
>>>
>>> Based on what we discussed recently, the plan could be the following:
>>> * before the end of April, create a branch (13.04) as a snapshot of the trunk and without all specialpurpose components (except the ecommerce component that will be included for the dependencies we have on it)
>>> ** alternatively, we could postpone the creation of the branch (to May?), if there are ongoing efforts that we would like to include in the branch; we could still name the branch 13.04 or create it as 13.05
>>>
>>> If we are ok with this plan I will take care of the creation of the branch before the end of April.
>>>
>>> Jacopo
>>

[hans_bakker]

Jacopo,

As was discussed often before, we at least now have a standard reporting
system included in the system which was moved from the framework without
my agreement. I think this is an essential part of an ERP system and a
framework component.

So does it matter that I, as a PMC member with over 2000 commits, do not
agree that the Birt reporting system (and sure later the Help system) is
not included in the release and said this pretty often?

probably not....

Regards,
Hans

On 04/24/2013 03:01 PM, Jacopo Cappellato wrote:
> Are we ready to create the new branch or we want to postpone it?
>
> Based on what we discussed recently, the plan could be the following:
> * before the end of April, create a branch (13.04) as a snapshot of the trunk and without all specialpurpose components (except the ecommerce component that will be included for the dependencies we have on it)
> ** alternatively, we could postpone the creation of the branch (to May?), if there are ongoing efforts that we would like to include in the branch; we could still name the branch 13.04 or create it as 13.05
>
> If we are ok with this plan I will take care of the creation of the branch before the end of April.
>
> Jacopo

[Jacopo Cappellato-4]

A good start would be fixing the many issues that are affecting the component and its report make it unreliable in production (and in releases). I mentioned them several times and you didn't take any action.
Also, that component was added (by you) to the project following the commit-than-review approach... when this happen it is still possible that, on a subsequent review, others will find that the contribution in inadequate for the project.

Jacopo


On Apr 24, 2013, at 1:45 PM, Hans Bakker <[hidden email]> wrote:

> Jacopo,
>
> As was discussed often before, we at least now have a standard reporting system included in the system which was moved from the framework without my agreement. I think this is an essential part of an ERP system and a framework component.
>
> So does it matter that I, as a PMC member with over 2000 commits, do not agree that the Birt reporting system (and sure later the Help system) is not included in the release and said this pretty often?
>
> probably not....
>
> Regards,
> Hans
>
> On 04/24/2013 03:01 PM, Jacopo Cappellato wrote:
>> Are we ready to create the new branch or we want to postpone it?
>>
>> Based on what we discussed recently, the plan could be the following:
>> * before the end of April, create a branch (13.04) as a snapshot of the trunk and without all specialpurpose components (except the ecommerce component that will be included for the dependencies we have on it)
>> ** alternatively, we could postpone the creation of the branch (to May?), if there are ongoing efforts that we would like to include in the branch; we could still name the branch 13.04 or create it as 13.05
>>
>> If we are ok with this plan I will take care of the creation of the branch before the end of April.
>>
>> Jacopo
>

[hans_bakker]

Jacopo,

For me is the BI, Eclipse and help system essential for the operation of
our system and that of our customers. For me there are no bocking
problems and this part is working fine.

If you think, that it is not good enough, feel free to improve it what
should be the goal of our community and not order me to solve the
problems you seem to have with this part of the system

Regards,
Hans.

On 04/24/2013 07:49 PM, Jacopo Cappellato wrote:

> A good start would be fixing the many issues that are affecting the component and its report make it unreliable in production (and in releases). I mentioned them several times and you didn't take any action.
> Also, that component was added (by you) to the project following the commit-than-review approach... when this happen it is still possible that, on a subsequent review, others will find that the contribution in inadequate for the project.
>
> Jacopo
>
>
> On Apr 24, 2013, at 1:45 PM, Hans Bakker <[hidden email]> wrote:
>
>> Jacopo,
>>
>> As was discussed often before, we at least now have a standard reporting system included in the system which was moved from the framework without my agreement. I think this is an essential part of an ERP system and a framework component.
>>
>> So does it matter that I, as a PMC member with over 2000 commits, do not agree that the Birt reporting system (and sure later the Help system) is not included in the release and said this pretty often?
>>
>> probably not....
>>
>> Regards,
>> Hans
>>
>> On 04/24/2013 03:01 PM, Jacopo Cappellato wrote:
>>> Are we ready to create the new branch or we want to postpone it?
>>>
>>> Based on what we discussed recently, the plan could be the following:
>>> * before the end of April, create a branch (13.04) as a snapshot of the trunk and without all specialpurpose components (except the ecommerce component that will be included for the dependencies we have on it)
>>> ** alternatively, we could postpone the creation of the branch (to May?), if there are ongoing efforts that we would like to include in the branch; we could still name the branch 13.04 or create it as 13.05
>>>
>>> If we are ok with this plan I will take care of the creation of the branch before the end of April.
>>>
>>> Jacopo

[Ean Schuessler]

I have to concur that the reporting feature feels "core" to me for business users. BIRT seems to be the most widely accepted standard since Jasper has gone "freemium" and BI seems like a huge selling point for us if we get it right.


I do have issues with the way BIRT is integrated (which I can elaborate separately). In some cases I run the stand-alone BIRT servlet directly. I don't know whether this makes a case for pulling BIRT out or keeping it in. I suppose what I'm saying is that reporting really needs to be present "out of the box" for us to make a compelling business case for the system.

----- "Hans Bakker" wrote:
> Jacopo,
> As was discussed often before, we at least now have a standard reporting
> system included in the system which was moved from the framework without
> my agreement. I think this is an essential part of an ERP system and a
> framework component.
> So does it matter that I, as a PMC member with over 2000 commits, do not
> agree that the Birt reporting system (and sure later the Help system) is
> not included in the release and said this pretty often?
> probably not....

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

[Adrian Crum-3]

The approach we take at 1Tech Ltd is to enable easy third-party
reporting tools integration - via database meta-data. Unless the client
has no infrastructure whatsoever, they usually prefer to use their
existing reporting tool with OFBiz, and exposing database meta-data
makes that easy.

We could debate the merits of various reporting tools at length, but the
end result will be that different people have different preferences. In
other words, you're not going to find unanimous agreement on using any
one tool.

So, I agree that reporting is core for business users, but forcing users
to use a particular reporting tool seems wrong.

-Adrian

On 4/24/2013 6:03 PM, Ean Schuessler wrote:

> I have to concur that the reporting feature feels "core" to me for business users. BIRT seems to be the most widely accepted standard since Jasper has gone "freemium" and BI seems like a huge selling point for us if we get it right.
>
>
> I do have issues with the way BIRT is integrated (which I can elaborate separately). In some cases I run the stand-alone BIRT servlet directly. I don't know whether this makes a case for pulling BIRT out or keeping it in. I suppose what I'm saying is that reporting really needs to be present "out of the box" for us to make a compelling business case for the system.
>
> ----- "Hans Bakker" wrote:
>> Jacopo,
>> As was discussed often before, we at least now have a standard reporting
>> system included in the system which was moved from the framework without
>> my agreement. I think this is an essential part of an ERP system and a
>> framework component.
>> So does it matter that I, as a PMC member with over 2000 commits, do not
>> agree that the Birt reporting system (and sure later the Help system) is
>> not included in the release and said this pretty often?
>> probably not....

[Jacopo Cappellato-4]

On Apr 24, 2013, at 7:03 PM, Ean Schuessler <[hidden email]> wrote:

> I do have issues with the way BIRT is integrated (which I can elaborate separately).

Here the problem is that the ASF asks us to publish in releases only high quality and production code.
We can say that the current implementation of the birt integration and its reports is "experimental" and it is not a good fit for the release branch: if you look at how things are implemented under the hood there, at the jars and the versions it uses etc... you will realize that including this component in the new release branch expose us to the risk of potentially having to publish a huge number of bug fix releases [*]
But the component is still available in the trunk and if the community is interested it can bi enhanced or refactored there (contributions are welcome), and then we could also release it ("Apache-OFBiz-Birt-Integration") for the users that want to use this type of integration, want to use Birt but they don't already have it installed and want to run it embedded in OFBiz.

Jacopo

[*]: please consider that maintaining a branch and releasing a new bug fix release is a time consuming task (and releasing bug fixes too often is not a great marketing message) and here we are trying to prevent this risk; please also consider that who is pushing to keep this component in the release until now has shown zero interest in releases and did not help the community to maintain them or publish them or respond to vulnerability reports.

[Jacopo Cappellato-4]

On Apr 24, 2013, at 6:47 PM, Hans Bakker <[hidden email]> wrote:

> If you think, that it is not good enough, feel free to improve it what should be the goal of our community and not order me to solve the problems you seem to have with this part of the system

I am not ordering you to do the job.
As regards me, I have already invested a big amount of time in this component (and I don't have a special interest on it) reviewing it and reporting its several issues; then I spent a big amount of time making it a pluggable component and I think this was a very good contribution to it; now it is optional and users that like it as is can check it out and plug it in; the community can also improve it (even if no one in the last year+, apart me, did anything on it).
In short, I already *fixed* it by making it pluggable: now it can be excluded from the release (where experimental/unsafe code is banned) and can be kept in the trunk, where experimental code can be maintained and improved... now it is up to the community to fix the issues and enhance it and at that point we could also publish it if we like.

Jacopo

[Ean Schuessler]

----- "Jacopo Cappellato" wrote:
> please also consider that who is pushing to keep this component in the release until now has shown zero interest in releases and did not help the community to maintain them or publish them or respond to vulnerability reports.

I stand suitably chastised. Please consider my observation withdrawn.

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

[Jacques Le Roux]

Looks like a good approach indeed. Could this be contributed?

For the rest, I simply agree with Jacopo.

Jacques

From: "Adrian Crum" <[hidden email]>

> The approach we take at 1Tech Ltd is to enable easy third-party
> reporting tools integration - via database meta-data. Unless the client
> has no infrastructure whatsoever, they usually prefer to use their
> existing reporting tool with OFBiz, and exposing database meta-data
> makes that easy.
>
> We could debate the merits of various reporting tools at length, but the
> end result will be that different people have different preferences. In
> other words, you're not going to find unanimous agreement on using any
> one tool.
>
> So, I agree that reporting is core for business users, but forcing users
> to use a particular reporting tool seems wrong.
>
> -Adrian
>
> On 4/24/2013 6:03 PM, Ean Schuessler wrote:
>> I have to concur that the reporting feature feels "core" to me for business users. BIRT seems to be the most widely accepted standard since Jasper has gone "freemium" and BI seems like a huge selling point for us if we get it right.
>>
>>
>> I do have issues with the way BIRT is integrated (which I can elaborate separately). In some cases I run the stand-alone BIRT servlet directly. I don't know whether this makes a case for pulling BIRT out or keeping it in. I suppose what I'm saying is that reporting really needs to be present "out of the box" for us to make a compelling business case for the system.
>>
>> ----- "Hans Bakker" wrote:
>>> Jacopo,
>>> As was discussed often before, we at least now have a standard reporting
>>> system included in the system which was moved from the framework without
>>> my agreement. I think this is an essential part of an ERP system and a
>>> framework component.
>>> So does it matter that I, as a PMC member with over 2000 commits, do not
>>> agree that the Birt reporting system (and sure later the Help system) is
>>> not included in the release and said this pretty often?
>>> probably not....
>

[hans_bakker]

Hi Jacopo,

I was not aware, that the changes only affect the release and in the
trunk these components are still active. If that is the case, it is fine
with me.

Regards,
Hans

On 04/25/2013 01:13 PM, Jacopo Cappellato wrote:
> On Apr 24, 2013, at 6:47 PM, Hans Bakker <[hidden email]> wrote:
>
>> If you think, that it is not good enough, feel free to improve it what should be the goal of our community and not order me to solve the problems you seem to have with this part of the system
> I am not ordering you to do the job.
> As regards me, I have already invested a big amount of time in this component (and I don't have a special interest on it) reviewing it and reporting its several issues; then I spent a big amount of time making it a pluggable component and I think this was a very good contribution to it; now it is optional and users that like it as is can check it out and plug it in; the community can also improve it (even if no one in the last year+, apart me, did anything on it).
> In short, I already *fixed* it by making it pluggable: now it can be excluded from the release (where experimental/unsafe code is banned) and can be kept in the trunk, where experimental code can be maintained and improved... now it is up to the community to fix the issues and enhance it and at that point we could also publish it if we like.
>
> Jacopo

[Jacopo Cappellato-4]

Ah ok, yes, here we are only talking about the upcoming new release branch 13.05, not the trunk... we are in a good spot then.

Jacopo

On Apr 25, 2013, at 10:01 AM, Hans Bakker <[hidden email]> wrote:

> Hi Jacopo,
>
> I was not aware, that the changes only affect the release and in the trunk these components are still active. If that is the case, it is fine with me.
>
> Regards,
> Hans
>
> On 04/25/2013 01:13 PM, Jacopo Cappellato wrote:
>> On Apr 24, 2013, at 6:47 PM, Hans Bakker <[hidden email]> wrote:
>>
>>> If you think, that it is not good enough, feel free to improve it what should be the goal of our community and not order me to solve the problems you seem to have with this part of the system
>> I am not ordering you to do the job.
>> As regards me, I have already invested a big amount of time in this component (and I don't have a special interest on it) reviewing it and reporting its several issues; then I spent a big amount of time making it a pluggable component and I think this was a very good contribution to it; now it is optional and users that like it as is can check it out and plug it in; the community can also improve it (even if no one in the last year+, apart me, did anything on it).
>> In short, I already *fixed* it by making it pluggable: now it can be excluded from the release (where experimental/unsafe code is banned) and can be kept in the trunk, where experimental code can be maintained and improved... now it is up to the community to fix the issues and enhance it and at that point we could also publish it if we like.
>>
>> Jacopo
>

[hans_bakker]

Hi Jacopo,

Good to hear the background reason of the slimdown activity. First of
all we are member of the Apache foundation and we should follow its
general directions and policies.

Now with the branch of 13.05 only general accepted production code will
be included which is the first release where that is happening.

If, instead of the attic, extra's and all the other proposals i can live
with the fact if only functions with high quality and production code
are included in future releases but are allowed in the trunk versions.

Here in AntWebsystems we are moving in the direction of continuous
integration and also continuous installation (also called rolling
releases) and therefore can only use the trunk version of ofbiz where we
pick versions after a relatively short continues testing period to base
our releases on.

Regards,
Hans


On 04/25/2013 01:02 PM, Jacopo Cappellato wrote:
> Here the problem is that the ASF asks us to publish in releases only
> high quality and production code.

[Jacopo Cappellato-4]

Ean,

I was actually referring to Hans, because I was surprised that he was trying to influence the way we were preparing our release after he clearly mentioned in several occasions that he was not interested in releases... but the discussion is now resolved after we realized there was a misunderstanding.
I was not chastising you for not being involved with release management and your point of view is always welcome.

Jacopo

On Apr 25, 2013, at 8:48 AM, Ean Schuessler <[hidden email]> wrote:

> ----- "Jacopo Cappellato" wrote:
>> please also consider that who is pushing to keep this component in the release until now has shown zero interest in releases and did not help the community to maintain them or publish them or respond to vulnerability reports.
>
> I stand suitably chastised. Please consider my observation withdrawn.
>
> --
> Ean Schuessler, CTO
> [hidden email]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com 

[Ean Schuessler]

Clearly I'm feeling some guilt about not helping with releases. :-D


Thanks for clarifying.
----- "Jacopo Cappellato" wrote:
> I was actually referring to Hans, because I was surprised that he was trying to influence the way we were preparing our release after he clearly mentioned in several occasions that he was not interested in releases... but the discussion is now resolved after we realized there was a misunderstanding.
> I was not chastising you for not being involved with release management and your point of view is always welcome.

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