Bug Crush

[Jacques Le Roux <ja...@les7arts.com>]

Hi,

It's great to see a second Bug Crush effort!

I have though a question, I see that you (HotWax Media team) only backport bug fixes to the R13 branch.
I guess it's intended, so why?

Jacques

Re: Bug Crush

[Jacques Le Roux <ja...@les7arts.com>]

Le 22/09/2014 06:50, Ashish Vijaywargiya a écrit :
>>> I wonder if we should not face the reality. Even during large efforts
> like HWM Bugs Crush, we don't/can't backport all bug fixes.
> I think we should make that clear and expose a way to users for them to
> more "easily" maintain the releases they use. I feel that with the help of
> the Jira changes logs reports (thanks Jacopo) this should be possible. I
> don't think at an automated way, just a process for users to follow.
>
> I liked this option and yes if does exists inside download page then that
> will be of great help. This will encourage end users to help PMC/Committer
> to manage release branches.
>
> Hello Ron, Jacques,
>
> Please wait for couple of weeks, I will try my best to back port all the
> necessary changes to Release 12.04. Thanks.
This is great to hear Ashish. Unfortunately, like mine, your effort will not be enough.
As Ron continued on this, we need to clearly define a policy to apply and stick with it

Jacques

>
> --
> Kind Regards,
> Ashish VIjaywargiya
>
>
> On Sat, Sep 20, 2014 at 10:53 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> I understand your point of view and I even tend to agree with.
>>
>> For the moment I still personally try to backport on all maintained
>> branches (those having releases pending). Most of the time it's
>> straightforward, but I got bitten once or two by wrong backports which
>> created new bugs that I had to fix.
>>
>> Still, though it's better now with Jira changes logs reports, the problem
>> is not everybody is aware of bug fixes backported or not.
>> The official download page http://ofbiz.apache.org/download.html, says
>> that we stabilize releases with bug fixes. It's not quite clear if we are
>> backporting all or only some bug fixes.
>>
>> I wonder if we should not face the reality. Even during large efforts like
>> HWM Bugs Crush, we don't/can't backport all bug fixes.
>> I think we should make that clear and expose a way to users for them to
>> more "easily" maintain the releases they use. I feel that with the help of
>> the Jira changes logs reports (thanks Jacopo) this should be possible. I
>> don't think at an automated way, just a process for users to follow.
>>
>> Jacques
>>
>> Le 20/09/2014 18:47, Adrian Crum a écrit :
>>
>>   I don't have time to maintain 4 code bases (trunk + 3 branches). I will
>>> fix things in the trunk, and I will backport those fixes to the most recent
>>> branch. I have no interest in older branches. If someone else is using
>>> them, then they can create a patch for them. So, I have no issues with
>>> releasing old branches with missing fixes - because if anyone really cared
>>> about them they would work harder to maintain them.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>>>
>>>> It seems a bit weird to me to officially release code with bugs when we
>>>> have already bug fixes in trunk
>>>>
>>>> Jacques
>>>>
>>>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>>>
>>>>>  From my perspective, anyone wanting to use older versions can backport
>>>>> the changes themselves - either locally, or in the release branches by
>>>>> providing a patch.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>>>
>>>>>> Hello Jacques,
>>>>>>
>>>>>> Thanks for your kind words. We started this event considering the fact
>>>>>> to provide fixes for trunk and latest release branch which is 13.07. It
>>>>>> will be of great help if someone from community could pick and back
>>>>>> port
>>>>>> the required changes to Release Branch 12.04. In future if we get time
>>>>>> we will also be taking care of back porting to R12.04.
>>>>>>
>>>>>> We didn't back port changes in R11.04 just because it is very old
>>>>>> branch
>>>>>> and very soon will not be maintained. Thanks.
>>>>>>
>>>>>> --
>>>>>> Kind Regards
>>>>>> Ashish Vijaywargiya
>>>>>> HotWax Media - est. 1997
>>>>>> ApacheCon US 2014 Silver Sponsor
>>>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>>>
>>>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> It's great to see a second Bug Crush effort!
>>>>>>>>
>>>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>>>> backport bug fixes to the R13 branch.
>>>>>>>> I guess it's intended, so why?
>>>>>>>>
>>>>>>> I ask this because I already found myself trying to fix issues in R12
>>>>>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>>>>>> found they were already backported in R13
>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>
>>>>>>

Re: Bug Crush

[Ashish Vijaywargiya <vi...@gmail.com>]

>> I wonder if we should not face the reality. Even during large efforts
like HWM Bugs Crush, we don't/can't backport all bug fixes.
I think we should make that clear and expose a way to users for them to
more "easily" maintain the releases they use. I feel that with the help of
the Jira changes logs reports (thanks Jacopo) this should be possible. I
don't think at an automated way, just a process for users to follow.

I liked this option and yes if does exists inside download page then that
will be of great help. This will encourage end users to help PMC/Committer
to manage release branches.

Hello Ron, Jacques,

Please wait for couple of weeks, I will try my best to back port all the
necessary changes to Release 12.04. Thanks.

--
Kind Regards,
Ashish VIjaywargiya


On Sat, Sep 20, 2014 at 10:53 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> I understand your point of view and I even tend to agree with.
>
> For the moment I still personally try to backport on all maintained
> branches (those having releases pending). Most of the time it's
> straightforward, but I got bitten once or two by wrong backports which
> created new bugs that I had to fix.
>
> Still, though it's better now with Jira changes logs reports, the problem
> is not everybody is aware of bug fixes backported or not.
> The official download page http://ofbiz.apache.org/download.html, says
> that we stabilize releases with bug fixes. It's not quite clear if we are
> backporting all or only some bug fixes.
>
> I wonder if we should not face the reality. Even during large efforts like
> HWM Bugs Crush, we don't/can't backport all bug fixes.
> I think we should make that clear and expose a way to users for them to
> more "easily" maintain the releases they use. I feel that with the help of
> the Jira changes logs reports (thanks Jacopo) this should be possible. I
> don't think at an automated way, just a process for users to follow.
>
> Jacques
>
> Le 20/09/2014 18:47, Adrian Crum a écrit :
>
>  I don't have time to maintain 4 code bases (trunk + 3 branches). I will
>> fix things in the trunk, and I will backport those fixes to the most recent
>> branch. I have no interest in older branches. If someone else is using
>> them, then they can create a patch for them. So, I have no issues with
>> releasing old branches with missing fixes - because if anyone really cared
>> about them they would work harder to maintain them.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>>
>>> It seems a bit weird to me to officially release code with bugs when we
>>> have already bug fixes in trunk
>>>
>>> Jacques
>>>
>>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>>
>>>> From my perspective, anyone wanting to use older versions can backport
>>>> the changes themselves - either locally, or in the release branches by
>>>> providing a patch.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>>
>>>>> Hello Jacques,
>>>>>
>>>>> Thanks for your kind words. We started this event considering the fact
>>>>> to provide fixes for trunk and latest release branch which is 13.07. It
>>>>> will be of great help if someone from community could pick and back
>>>>> port
>>>>> the required changes to Release Branch 12.04. In future if we get time
>>>>> we will also be taking care of back porting to R12.04.
>>>>>
>>>>> We didn't back port changes in R11.04 just because it is very old
>>>>> branch
>>>>> and very soon will not be maintained. Thanks.
>>>>>
>>>>> --
>>>>> Kind Regards
>>>>> Ashish Vijaywargiya
>>>>> HotWax Media - est. 1997
>>>>> ApacheCon US 2014 Silver Sponsor
>>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>>
>>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>
>>>>>>
>>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It's great to see a second Bug Crush effort!
>>>>>>>
>>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>>> backport bug fixes to the R13 branch.
>>>>>>> I guess it's intended, so why?
>>>>>>>
>>>>>> I ask this because I already found myself trying to fix issues in R12
>>>>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>>>>> found they were already backported in R13
>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Bug Crush

[Ron Wheeler <rw...@artifact-software.com>]

For companies adopting an ERP, this is a big decision and the Apache 
name generates certain expectations.

I think that writing up an honest statement about what the PMC defines 
as a "stable release" would be helpful.
It should describe the EOL condition/date and what the commitment is to 
fixing bugs in the "current stable release".
If 12.x.x is no longer supported, the PMC should say so.

If 11.x.x is no longer going to be maintained, that should be clearly 
stated as well.

If only certain types of bugs are going to be fixed, this should be stated.

If 13.07.x is actually the "Current Stable Release", this should be 
stated and the release finished.
I am not sure what the customer reaction will be for a product that 
defines EOL of one release to be the day when the next major version is 
release.
One month prior to the release date is clearly not acceptable for an ERP.

The PMC has to make some management decisions that it believes in and 
can defend as reasonable for a project of this type and that it can live 
up to.


Ron



On 20/09/2014 1:23 PM, Jacques Le Roux wrote:
> I understand your point of view and I even tend to agree with.
>
> For the moment I still personally try to backport on all maintained 
> branches (those having releases pending). Most of the time it's 
> straightforward, but I got bitten once or two by wrong backports which 
> created new bugs that I had to fix.
>
> Still, though it's better now with Jira changes logs reports, the 
> problem is not everybody is aware of bug fixes backported or not.
> The official download page http://ofbiz.apache.org/download.html, says 
> that we stabilize releases with bug fixes. It's not quite clear if we 
> are backporting all or only some bug fixes.
>
> I wonder if we should not face the reality. Even during large efforts 
> like HWM Bugs Crush, we don't/can't backport all bug fixes.
> I think we should make that clear and expose a way to users for them 
> to more "easily" maintain the releases they use. I feel that with the 
> help of the Jira changes logs reports (thanks Jacopo) this should be 
> possible. I don't think at an automated way, just a process for users 
> to follow.
>
> Jacques
>
> Le 20/09/2014 18:47, Adrian Crum a écrit :
>> I don't have time to maintain 4 code bases (trunk + 3 branches). I 
>> will fix things in the trunk, and I will backport those fixes to the 
>> most recent branch. I have no interest in older branches. If someone 
>> else is using them, then they can create a patch for them. So, I have 
>> no issues with releasing old branches with missing fixes - because if 
>> anyone really cared about them they would work harder to maintain them.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>>> It seems a bit weird to me to officially release code with bugs when we
>>> have already bug fixes in trunk
>>>
>>> Jacques
>>>
>>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>>> From my perspective, anyone wanting to use older versions can backport
>>>> the changes themselves - either locally, or in the release branches by
>>>> providing a patch.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>>> Hello Jacques,
>>>>>
>>>>> Thanks for your kind words. We started this event considering the 
>>>>> fact
>>>>> to provide fixes for trunk and latest release branch which is 
>>>>> 13.07. It
>>>>> will be of great help if someone from community could pick and 
>>>>> back port
>>>>> the required changes to Release Branch 12.04. In future if we get 
>>>>> time
>>>>> we will also be taking care of back porting to R12.04.
>>>>>
>>>>> We didn't back port changes in R11.04 just because it is very old 
>>>>> branch
>>>>> and very soon will not be maintained. Thanks.
>>>>>
>>>>> -- 
>>>>> Kind Regards
>>>>> Ashish Vijaywargiya
>>>>> HotWax Media - est. 1997
>>>>> ApacheCon US 2014 Silver Sponsor
>>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>>
>>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> It's great to see a second Bug Crush effort!
>>>>>>>
>>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>>> backport bug fixes to the R13 branch.
>>>>>>> I guess it's intended, so why?
>>>>>> I ask this because I already found myself trying to fix issues in 
>>>>>> R12
>>>>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>>>>> found they were already backported in R13
>>>>>>> Jacques
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Bug Crush

[Ron Wheeler <rw...@artifact-software.com>]

End-users want a reliable project with lots of functionality that is 
going to be maintained by the suppliers (like Apache HTTP,  Maven, ORACLE).

If the goal is for a few integrators to share some code, that should be 
clearly described as the mission and perhaps it should be dropped as an 
Apache project

If it is to produce an ERP that can be adopted by companies for their 
mission-critical applications, there needs to be a release and 
maintenance policy that makes business sense for the end-users.
At a minimum:
a) Releases have to be supported until "end of life".
b) The EOL and maintenance policy has to be clear.
c) The PMC has to ensure that the team is committed to the projects 
policies and procedures.

What would you say to someone who needed an ERP and wanted to install 
the "stable" release of OFBIZ in a real company?


Ron

On 21/09/2014 12:07 PM, Anil Patel wrote:
> Ron,
> You are making good point.
>
>
> On Sep 21, 2014, at 8:43 AM, Ron Wheeler <rw...@artifact-software.com> wrote:
>
>> +1
>> If this is ever going to be a commercial success, there has to be enough transparency and reliability that people feel confident in committing to OFBiz.
> +1
>
>> If the policy is "You can download the current release and commit your organization's most critical business functions to it but we are not going to fix the bugs that we find.", it is going to be hard for someone to sell OFBiz to management regardless of how great the feature list might be.
> +1
>
> What if, Users of certain release e.g 11.04 clearly communicate their willingness to help with maintaining the release. Help includes reporting bugs and keeping track of fixes that have not made into release of their interest.
>
> In absence of any managed effort to maintain ofbiz release, My recommendation is to use most recent release. Recently Hans posted nice article on this topic (https://www.linkedin.com/pulse/article/20140909060033-1227556-upgrade-your-erp-system-like-a-phone-app).
>
>> Imaging how happy we would be if ORCLE announced that maintaining all these versions of Java was too much work and they were only going to fix bugs in Java 8. We would be looking for another Java PDQ.
> We all know how commercial products are maintained. In case of community based products, Users of software own the product and so they have right to maintain software.
>
>> If there is any doubt as to the effect of this policy, perhaps some of the system integrators could ask their customers how this policy would fit their needs
> I agree with you. Customers don’t like to spend money on migrating their system to newer version of OFBiz unless their is real ROI involved. System Integrators can support their customers by participating in the community and supporting OFBiz release branch.
>
>> Ron
> Regards
> Anil Patel
>
>
>
>>
>> On 20/09/2014 1:23 PM, Jacques Le Roux wrote:
>>> I understand your point of view and I even tend to agree with.
>>>
>>> For the moment I still personally try to backport on all maintained branches (those having releases pending). Most of the time it's straightforward, but I got bitten once or two by wrong backports which created new bugs that I had to fix.
>>>
>>> Still, though it's better now with Jira changes logs reports, the problem is not everybody is aware of bug fixes backported or not.
>>> The official download page http://ofbiz.apache.org/download.html, says that we stabilize releases with bug fixes. It's not quite clear if we are backporting all or only some bug fixes.
>>>
>>> I wonder if we should not face the reality. Even during large efforts like HWM Bugs Crush, we don't/can't backport all bug fixes.
>>> I think we should make that clear and expose a way to users for them to more "easily" maintain the releases they use. I feel that with the help of the Jira changes logs reports (thanks Jacopo) this should be possible. I don't think at an automated way, just a process for users to follow.
>>>
>>> Jacques
>>>
>>> Le 20/09/2014 18:47, Adrian Crum a écrit :
>>>> I don't have time to maintain 4 code bases (trunk + 3 branches). I will fix things in the trunk, and I will backport those fixes to the most recent branch. I have no interest in older branches. If someone else is using them, then they can create a patch for them. So, I have no issues with releasing old branches with missing fixes - because if anyone really cared about them they would work harder to maintain them.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>>>>> It seems a bit weird to me to officially release code with bugs when we
>>>>> have already bug fixes in trunk
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>>>>>  From my perspective, anyone wanting to use older versions can backport
>>>>>> the changes themselves - either locally, or in the release branches by
>>>>>> providing a patch.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>>>>> Hello Jacques,
>>>>>>>
>>>>>>> Thanks for your kind words. We started this event considering the fact
>>>>>>> to provide fixes for trunk and latest release branch which is 13.07. It
>>>>>>> will be of great help if someone from community could pick and back port
>>>>>>> the required changes to Release Branch 12.04. In future if we get time
>>>>>>> we will also be taking care of back porting to R12.04.
>>>>>>>
>>>>>>> We didn't back port changes in R11.04 just because it is very old branch
>>>>>>> and very soon will not be maintained. Thanks.
>>>>>>>
>>>>>>> -- 
>>>>>>> Kind Regards
>>>>>>> Ashish Vijaywargiya
>>>>>>> HotWax Media - est. 1997
>>>>>>> ApacheCon US 2014 Silver Sponsor
>>>>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>>>>
>>>>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> It's great to see a second Bug Crush effort!
>>>>>>>>>
>>>>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>>>>> backport bug fixes to the R13 branch.
>>>>>>>>> I guess it's intended, so why?
>>>>>>>> I ask this because I already found myself trying to fix issues in R12
>>>>>>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>>>>>>> found they were already backported in R13
>>>>>>>>> Jacques
>>>>>>>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Bug Crush

[Anil Patel <an...@hotwaxmedia.com>]

Ron,
You are making good point. 


On Sep 21, 2014, at 8:43 AM, Ron Wheeler <rw...@artifact-software.com> wrote:

> +1
> If this is ever going to be a commercial success, there has to be enough transparency and reliability that people feel confident in committing to OFBiz.

+1 

> 
> If the policy is "You can download the current release and commit your organization's most critical business functions to it but we are not going to fix the bugs that we find.", it is going to be hard for someone to sell OFBiz to management regardless of how great the feature list might be.

+1

What if, Users of certain release e.g 11.04 clearly communicate their willingness to help with maintaining the release. Help includes reporting bugs and keeping track of fixes that have not made into release of their interest.

In absence of any managed effort to maintain ofbiz release, My recommendation is to use most recent release. Recently Hans posted nice article on this topic (https://www.linkedin.com/pulse/article/20140909060033-1227556-upgrade-your-erp-system-like-a-phone-app).

> 
> Imaging how happy we would be if ORCLE announced that maintaining all these versions of Java was too much work and they were only going to fix bugs in Java 8. We would be looking for another Java PDQ.

We all know how commercial products are maintained. In case of community based products, Users of software own the product and so they have right to maintain software.

> 
> If there is any doubt as to the effect of this policy, perhaps some of the system integrators could ask their customers how this policy would fit their needs

I agree with you. Customers don’t like to spend money on migrating their system to newer version of OFBiz unless their is real ROI involved. System Integrators can support their customers by participating in the community and supporting OFBiz release branch. 

> 
> Ron

Regards
Anil Patel



> 
> 
> On 20/09/2014 1:23 PM, Jacques Le Roux wrote:
>> I understand your point of view and I even tend to agree with.
>> 
>> For the moment I still personally try to backport on all maintained branches (those having releases pending). Most of the time it's straightforward, but I got bitten once or two by wrong backports which created new bugs that I had to fix.
>> 
>> Still, though it's better now with Jira changes logs reports, the problem is not everybody is aware of bug fixes backported or not.
>> The official download page http://ofbiz.apache.org/download.html, says that we stabilize releases with bug fixes. It's not quite clear if we are backporting all or only some bug fixes.
>> 
>> I wonder if we should not face the reality. Even during large efforts like HWM Bugs Crush, we don't/can't backport all bug fixes.
>> I think we should make that clear and expose a way to users for them to more "easily" maintain the releases they use. I feel that with the help of the Jira changes logs reports (thanks Jacopo) this should be possible. I don't think at an automated way, just a process for users to follow.
>> 
>> Jacques
>> 
>> Le 20/09/2014 18:47, Adrian Crum a écrit :
>>> I don't have time to maintain 4 code bases (trunk + 3 branches). I will fix things in the trunk, and I will backport those fixes to the most recent branch. I have no interest in older branches. If someone else is using them, then they can create a patch for them. So, I have no issues with releasing old branches with missing fixes - because if anyone really cared about them they would work harder to maintain them.
>>> 
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>> 
>>> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>>>> It seems a bit weird to me to officially release code with bugs when we
>>>> have already bug fixes in trunk
>>>> 
>>>> Jacques
>>>> 
>>>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>>>> From my perspective, anyone wanting to use older versions can backport
>>>>> the changes themselves - either locally, or in the release branches by
>>>>> providing a patch.
>>>>> 
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>> 
>>>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>>>> Hello Jacques,
>>>>>> 
>>>>>> Thanks for your kind words. We started this event considering the fact
>>>>>> to provide fixes for trunk and latest release branch which is 13.07. It
>>>>>> will be of great help if someone from community could pick and back port
>>>>>> the required changes to Release Branch 12.04. In future if we get time
>>>>>> we will also be taking care of back porting to R12.04.
>>>>>> 
>>>>>> We didn't back port changes in R11.04 just because it is very old branch
>>>>>> and very soon will not be maintained. Thanks.
>>>>>> 
>>>>>> -- 
>>>>>> Kind Regards
>>>>>> Ashish Vijaywargiya
>>>>>> HotWax Media - est. 1997
>>>>>> ApacheCon US 2014 Silver Sponsor
>>>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>>> 
>>>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>>> 
>>>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> It's great to see a second Bug Crush effort!
>>>>>>>> 
>>>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>>>> backport bug fixes to the R13 branch.
>>>>>>>> I guess it's intended, so why?
>>>>>>> I ask this because I already found myself trying to fix issues in R12
>>>>>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>>>>>> found they were already backported in R13
>>>>>>>> Jacques
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 

Re: Bug Crush

[Ron Wheeler <rw...@artifact-software.com>]

+1
If this is ever going to be a commercial success, there has to be enough 
transparency and reliability that people feel confident in committing to 
OFBiz.

If the policy is "You can download the current release and commit your 
organization's most critical business functions to it but we are not 
going to fix the bugs that we find.", it is going to be hard for someone 
to sell OFBiz to management regardless of how great the feature list 
might be.

Imaging how happy we would be if ORCLE announced that maintaining all 
these versions of Java was too much work and they were only going to fix 
bugs in Java 8. We would be looking for another Java PDQ.

If there is any doubt as to the effect of this policy, perhaps some of 
the system integrators could ask their customers how this policy would 
fit their needs

Ron


On 20/09/2014 1:23 PM, Jacques Le Roux wrote:
> I understand your point of view and I even tend to agree with.
>
> For the moment I still personally try to backport on all maintained 
> branches (those having releases pending). Most of the time it's 
> straightforward, but I got bitten once or two by wrong backports which 
> created new bugs that I had to fix.
>
> Still, though it's better now with Jira changes logs reports, the 
> problem is not everybody is aware of bug fixes backported or not.
> The official download page http://ofbiz.apache.org/download.html, says 
> that we stabilize releases with bug fixes. It's not quite clear if we 
> are backporting all or only some bug fixes.
>
> I wonder if we should not face the reality. Even during large efforts 
> like HWM Bugs Crush, we don't/can't backport all bug fixes.
> I think we should make that clear and expose a way to users for them 
> to more "easily" maintain the releases they use. I feel that with the 
> help of the Jira changes logs reports (thanks Jacopo) this should be 
> possible. I don't think at an automated way, just a process for users 
> to follow.
>
> Jacques
>
> Le 20/09/2014 18:47, Adrian Crum a écrit :
>> I don't have time to maintain 4 code bases (trunk + 3 branches). I 
>> will fix things in the trunk, and I will backport those fixes to the 
>> most recent branch. I have no interest in older branches. If someone 
>> else is using them, then they can create a patch for them. So, I have 
>> no issues with releasing old branches with missing fixes - because if 
>> anyone really cared about them they would work harder to maintain them.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>>> It seems a bit weird to me to officially release code with bugs when we
>>> have already bug fixes in trunk
>>>
>>> Jacques
>>>
>>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>>> From my perspective, anyone wanting to use older versions can backport
>>>> the changes themselves - either locally, or in the release branches by
>>>> providing a patch.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>>> Hello Jacques,
>>>>>
>>>>> Thanks for your kind words. We started this event considering the 
>>>>> fact
>>>>> to provide fixes for trunk and latest release branch which is 
>>>>> 13.07. It
>>>>> will be of great help if someone from community could pick and 
>>>>> back port
>>>>> the required changes to Release Branch 12.04. In future if we get 
>>>>> time
>>>>> we will also be taking care of back porting to R12.04.
>>>>>
>>>>> We didn't back port changes in R11.04 just because it is very old 
>>>>> branch
>>>>> and very soon will not be maintained. Thanks.
>>>>>
>>>>> -- 
>>>>> Kind Regards
>>>>> Ashish Vijaywargiya
>>>>> HotWax Media - est. 1997
>>>>> ApacheCon US 2014 Silver Sponsor
>>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>>
>>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> It's great to see a second Bug Crush effort!
>>>>>>>
>>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>>> backport bug fixes to the R13 branch.
>>>>>>> I guess it's intended, so why?
>>>>>> I ask this because I already found myself trying to fix issues in 
>>>>>> R12
>>>>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>>>>> found they were already backported in R13
>>>>>>> Jacques
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Bug Crush

[Jacques Le Roux <ja...@les7arts.com>]

I understand your point of view and I even tend to agree with.

For the moment I still personally try to backport on all maintained branches (those having releases pending). Most of the time it's straightforward, 
but I got bitten once or two by wrong backports which created new bugs that I had to fix.

Still, though it's better now with Jira changes logs reports, the problem is not everybody is aware of bug fixes backported or not.
The official download page http://ofbiz.apache.org/download.html, says that we stabilize releases with bug fixes. It's not quite clear if we are 
backporting all or only some bug fixes.

I wonder if we should not face the reality. Even during large efforts like HWM Bugs Crush, we don't/can't backport all bug fixes.
I think we should make that clear and expose a way to users for them to more "easily" maintain the releases they use. I feel that with the help of the 
Jira changes logs reports (thanks Jacopo) this should be possible. I don't think at an automated way, just a process for users to follow.

Jacques

Le 20/09/2014 18:47, Adrian Crum a écrit :
> I don't have time to maintain 4 code bases (trunk + 3 branches). I will fix things in the trunk, and I will backport those fixes to the most recent 
> branch. I have no interest in older branches. If someone else is using them, then they can create a patch for them. So, I have no issues with 
> releasing old branches with missing fixes - because if anyone really cared about them they would work harder to maintain them.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>> It seems a bit weird to me to officially release code with bugs when we
>> have already bug fixes in trunk
>>
>> Jacques
>>
>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>> From my perspective, anyone wanting to use older versions can backport
>>> the changes themselves - either locally, or in the release branches by
>>> providing a patch.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>> Hello Jacques,
>>>>
>>>> Thanks for your kind words. We started this event considering the fact
>>>> to provide fixes for trunk and latest release branch which is 13.07. It
>>>> will be of great help if someone from community could pick and back port
>>>> the required changes to Release Branch 12.04. In future if we get time
>>>> we will also be taking care of back porting to R12.04.
>>>>
>>>> We didn't back port changes in R11.04 just because it is very old branch
>>>> and very soon will not be maintained. Thanks.
>>>>
>>>> -- 
>>>> Kind Regards
>>>> Ashish Vijaywargiya
>>>> HotWax Media - est. 1997
>>>> ApacheCon US 2014 Silver Sponsor
>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>
>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>
>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>> Hi,
>>>>>>
>>>>>> It's great to see a second Bug Crush effort!
>>>>>>
>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>> backport bug fixes to the R13 branch.
>>>>>> I guess it's intended, so why?
>>>>> I ask this because I already found myself trying to fix issues in R12
>>>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>>>> found they were already backported in R13
>>>>>> Jacques
>>>>>
>>>>
>>>>
>>>
>>
>

Re: Bug Crush

[Ron Wheeler <rw...@artifact-software.com>]

On 22/09/2014 9:51 AM, Jacopo Cappellato wrote:
> Some ideas to manage this workflow in a better way:
>
> * if a bug that affects an old release branch is not backported, when we resolve the ticket we create a new one that is linked to the original and has the field "affected releases" set the affected old branch; this will be a placeholder for the ones willing to maintain the old branch
The "current stable release" should be the first place a bug is fixed.
> * about the end of life of release branches: when we perceive a decreasing interest from the community to backport to an old release, we could run a vote to decide if the community is ok to anticipate the end of life of a release branch; the ones that vote to keep the branch alive could offer to help in the backporting process
Very good idea. You might want to think about setting a suggested EOL 
date when the release is issued.
It would be helpful to the user community to know that by such and such 
a date, this branch will no longer be maintained.
This would allow the user to understand the TCO of switching to it.

I get a sense that :
a) 13.07 took too long to release and got to a point where a lot of the 
main contributors are already using it in production and have a business 
interest in maintaining it and no business interest in earlier releases.
b) many of the end-users of OFBiz do not have to deal with the project 
directly and have SLA's and maintenance commitments from SI companies 
that insulate them from the OFBiz project.


Ron

>
> Jacopo
>
>
>
> On Sep 22, 2014, at 12:48 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
>
>> This discussion seems to be spinning off into a strange direction.
>>
>> I stated my personal perspective on backporting bug fixes, and the amount of backporting my free time allows. Others are free to disagree with me.
>>
>> I might be wrong, but it seems to me you are suggesting the PMC should twist my arm to do a more thorough job of backporting bug fixes. If that is true, then you need to understand that is not the PMC's role. Even if it was, I would reject that attempt and restate my viewpoint: If the bug fix backport is important enough to someone, then they will do it themselves.
>>
>> Even if that isn't what you are suggesting, you seem to be TELLING the PMC its role, instead of LEARNING the PMC's role.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 9/21/2014 2:45 PM, Ron Wheeler wrote:
>>> The PMC has to manage the team.
>>> It is called a Project MANAGEMENT Committee for a reason.
>>>
>>> You are right that the PMC can not order anyone to do anything.
>>> Apache is based on volunteers working together as a team.
>>> That does not mean that the Committee is powerless.
>>> It has to work in a collaborative way to manage the project.
>>> This means setting policy, setting priorities and assigning tasks or
>>> more accurately soliciting volunteers to do tasks that the PMC
>>> identifies as important.
>>> It means agreeing on dates by which tasks will be performed and taking
>>> action when it is clear that volunteers are not going to be able to
>>> finish work that they have agreed to do for whatever reason. This action
>>> may be soliciting additional help, revising dates to match reality or
>>> revising scope or a combination.
>>>
>>> The PMC should make sure that the people fixing the bugs understand that
>>> the bugs need to be fixed in all supported versions if that is the
>>> Policy of the PMC.
>>> If they are not willing to follow the direction of the PMC, the the PMC
>>> needs to act.
>>>
>>> The "merit" in meritocracy does not just mean code. It also means team
>>> commitment, collaboration skills and management. If someone does not
>>> want to work in a collaborative way and only does the parts of a task
>>> that appeals to them, they should be treated in the same way as someone
>>> who commits code that only fixes the interesting part of the bug and
>>> breaks other code or someone who doesn't want to use the framework and
>>> rewrites code to directly access data rather than using the framework.
>>> Some behaviour is not acceptable to the PMC regardless of how much time
>>> the volunteer is willing to put in.
>>>
>>> How often does the PMC meet?
>>> When was the last set of minutes published?
>>> What is the most significant policy decision or other issue that the PMC
>>> is currently working on?
>>> When was the last PMC meeting about the release roadmap?
>>>
>>> Ron
>>>
>>> On 21/09/2014 8:50 AM, Jacopo Cappellato wrote:
>>>> The PMC doesn't manage a team: we can't ask people to work on what we
>>>> think is important.
>>>> The persons that contribute code to the project (and backport
>>>> features) are persons like you and me, and the PMC doesn't have the
>>>> authority or will to assign tasks to them.
>>>> In fact, I doubt I could ask you to test and backport to 12.04 all the
>>>> 59 features that the have been committed yesterday :-)
>>>>
>>>> Regards,
>>>>
>>>> Jacopo
>>>>
>>>> On Sep 21, 2014, at 2:31 PM, Ron Wheeler
>>>> <rw...@artifact-software.com> wrote:
>>>>
>>>>> No one has time to fix all of the bugs by themselves but by managing
>>>>> the team, it should be possible to get all of the required work done.
>>>>>
>>>>> The PMC needs to develop a consensus about how bugs are handled in
>>>>> the official releases and then make lists of things that need doing.
>>>>> If a bug is found and added to he JIRA, determining which releases it
>>>>> applies to should be part of the analysis.
>>>>>
>>>>> If a patch is developed it should be possible to apply it to each
>>>>> release at the same time.
>>>>>
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>> On 20/09/2014 12:47 PM, Adrian Crum wrote:
>>>>>> I don't have time to maintain 4 code bases (trunk + 3 branches). I
>>>>>> will fix things in the trunk, and I will backport those fixes to the
>>>>>> most recent branch. I have no interest in older branches. If someone
>>>>>> else is using them, then they can create a patch for them. So, I
>>>>>> have no issues with releasing old branches with missing fixes -
>>>>>> because if anyone really cared about them they would work harder to
>>>>>> maintain them.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>>>>>>> It seems a bit weird to me to officially release code with bugs
>>>>>>> when we
>>>>>>> have already bug fixes in trunk
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>>>>>>>  From my perspective, anyone wanting to use older versions can
>>>>>>>> backport
>>>>>>>> the changes themselves - either locally, or in the release
>>>>>>>> branches by
>>>>>>>> providing a patch.
>>>>>>>>
>>>>>>>> Adrian Crum
>>>>>>>> Sandglass Software
>>>>>>>> www.sandglass-software.com
>>>>>>>>
>>>>>>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>>>>>>> Hello Jacques,
>>>>>>>>>
>>>>>>>>> Thanks for your kind words. We started this event considering the
>>>>>>>>> fact
>>>>>>>>> to provide fixes for trunk and latest release branch which is
>>>>>>>>> 13.07. It
>>>>>>>>> will be of great help if someone from community could pick and
>>>>>>>>> back port
>>>>>>>>> the required changes to Release Branch 12.04. In future if we get
>>>>>>>>> time
>>>>>>>>> we will also be taking care of back porting to R12.04.
>>>>>>>>>
>>>>>>>>> We didn't back port changes in R11.04 just because it is very old
>>>>>>>>> branch
>>>>>>>>> and very soon will not be maintained. Thanks.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Kind Regards
>>>>>>>>> Ashish Vijaywargiya
>>>>>>>>> HotWax Media - est. 1997
>>>>>>>>> ApacheCon US 2014 Silver Sponsor
>>>>>>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>>>>>>
>>>>>>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> It's great to see a second Bug Crush effort!
>>>>>>>>>>>
>>>>>>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>>>>>>> backport bug fixes to the R13 branch.
>>>>>>>>>>> I guess it's intended, so why?
>>>>>>>>>> I ask this because I already found myself trying to fix issues
>>>>>>>>>> in R12
>>>>>>>>>> and R11 branches (I know will be soon no longer maintained R11 )
>>>>>>>>>> and
>>>>>>>>>> found they were already backported in R13
>>>>>>>>>>> Jacques
>>>>> --
>>>>> Ron Wheeler
>>>>> President
>>>>> Artifact Software Inc
>>>>> email: rwheeler@artifact-software.com
>>>>> skype: ronaldmwheeler
>>>>> phone: 866-970-2435, ext 102
>>>>>
>>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Bug Crush

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

Some ideas to manage this workflow in a better way:

* if a bug that affects an old release branch is not backported, when we resolve the ticket we create a new one that is linked to the original and has the field "affected releases" set the affected old branch; this will be a placeholder for the ones willing to maintain the old branch
* about the end of life of release branches: when we perceive a decreasing interest from the community to backport to an old release, we could run a vote to decide if the community is ok to anticipate the end of life of a release branch; the ones that vote to keep the branch alive could offer to help in the backporting process

Jacopo



On Sep 22, 2014, at 12:48 PM, Adrian Crum <ad...@sandglass-software.com> wrote:

> This discussion seems to be spinning off into a strange direction.
> 
> I stated my personal perspective on backporting bug fixes, and the amount of backporting my free time allows. Others are free to disagree with me.
> 
> I might be wrong, but it seems to me you are suggesting the PMC should twist my arm to do a more thorough job of backporting bug fixes. If that is true, then you need to understand that is not the PMC's role. Even if it was, I would reject that attempt and restate my viewpoint: If the bug fix backport is important enough to someone, then they will do it themselves.
> 
> Even if that isn't what you are suggesting, you seem to be TELLING the PMC its role, instead of LEARNING the PMC's role.
> 
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
> 
> On 9/21/2014 2:45 PM, Ron Wheeler wrote:
>> The PMC has to manage the team.
>> It is called a Project MANAGEMENT Committee for a reason.
>> 
>> You are right that the PMC can not order anyone to do anything.
>> Apache is based on volunteers working together as a team.
>> That does not mean that the Committee is powerless.
>> It has to work in a collaborative way to manage the project.
>> This means setting policy, setting priorities and assigning tasks or
>> more accurately soliciting volunteers to do tasks that the PMC
>> identifies as important.
>> It means agreeing on dates by which tasks will be performed and taking
>> action when it is clear that volunteers are not going to be able to
>> finish work that they have agreed to do for whatever reason. This action
>> may be soliciting additional help, revising dates to match reality or
>> revising scope or a combination.
>> 
>> The PMC should make sure that the people fixing the bugs understand that
>> the bugs need to be fixed in all supported versions if that is the
>> Policy of the PMC.
>> If they are not willing to follow the direction of the PMC, the the PMC
>> needs to act.
>> 
>> The "merit" in meritocracy does not just mean code. It also means team
>> commitment, collaboration skills and management. If someone does not
>> want to work in a collaborative way and only does the parts of a task
>> that appeals to them, they should be treated in the same way as someone
>> who commits code that only fixes the interesting part of the bug and
>> breaks other code or someone who doesn't want to use the framework and
>> rewrites code to directly access data rather than using the framework.
>> Some behaviour is not acceptable to the PMC regardless of how much time
>> the volunteer is willing to put in.
>> 
>> How often does the PMC meet?
>> When was the last set of minutes published?
>> What is the most significant policy decision or other issue that the PMC
>> is currently working on?
>> When was the last PMC meeting about the release roadmap?
>> 
>> Ron
>> 
>> On 21/09/2014 8:50 AM, Jacopo Cappellato wrote:
>>> The PMC doesn't manage a team: we can't ask people to work on what we
>>> think is important.
>>> The persons that contribute code to the project (and backport
>>> features) are persons like you and me, and the PMC doesn't have the
>>> authority or will to assign tasks to them.
>>> In fact, I doubt I could ask you to test and backport to 12.04 all the
>>> 59 features that the have been committed yesterday :-)
>>> 
>>> Regards,
>>> 
>>> Jacopo
>>> 
>>> On Sep 21, 2014, at 2:31 PM, Ron Wheeler
>>> <rw...@artifact-software.com> wrote:
>>> 
>>>> No one has time to fix all of the bugs by themselves but by managing
>>>> the team, it should be possible to get all of the required work done.
>>>> 
>>>> The PMC needs to develop a consensus about how bugs are handled in
>>>> the official releases and then make lists of things that need doing.
>>>> If a bug is found and added to he JIRA, determining which releases it
>>>> applies to should be part of the analysis.
>>>> 
>>>> If a patch is developed it should be possible to apply it to each
>>>> release at the same time.
>>>> 
>>>> 
>>>> Ron
>>>> 
>>>> 
>>>> On 20/09/2014 12:47 PM, Adrian Crum wrote:
>>>>> I don't have time to maintain 4 code bases (trunk + 3 branches). I
>>>>> will fix things in the trunk, and I will backport those fixes to the
>>>>> most recent branch. I have no interest in older branches. If someone
>>>>> else is using them, then they can create a patch for them. So, I
>>>>> have no issues with releasing old branches with missing fixes -
>>>>> because if anyone really cared about them they would work harder to
>>>>> maintain them.
>>>>> 
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>> 
>>>>> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>>>>>> It seems a bit weird to me to officially release code with bugs
>>>>>> when we
>>>>>> have already bug fixes in trunk
>>>>>> 
>>>>>> Jacques
>>>>>> 
>>>>>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>>>>>> From my perspective, anyone wanting to use older versions can
>>>>>>> backport
>>>>>>> the changes themselves - either locally, or in the release
>>>>>>> branches by
>>>>>>> providing a patch.
>>>>>>> 
>>>>>>> Adrian Crum
>>>>>>> Sandglass Software
>>>>>>> www.sandglass-software.com
>>>>>>> 
>>>>>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>>>>>> Hello Jacques,
>>>>>>>> 
>>>>>>>> Thanks for your kind words. We started this event considering the
>>>>>>>> fact
>>>>>>>> to provide fixes for trunk and latest release branch which is
>>>>>>>> 13.07. It
>>>>>>>> will be of great help if someone from community could pick and
>>>>>>>> back port
>>>>>>>> the required changes to Release Branch 12.04. In future if we get
>>>>>>>> time
>>>>>>>> we will also be taking care of back porting to R12.04.
>>>>>>>> 
>>>>>>>> We didn't back port changes in R11.04 just because it is very old
>>>>>>>> branch
>>>>>>>> and very soon will not be maintained. Thanks.
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Kind Regards
>>>>>>>> Ashish Vijaywargiya
>>>>>>>> HotWax Media - est. 1997
>>>>>>>> ApacheCon US 2014 Silver Sponsor
>>>>>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>>>>> 
>>>>>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> It's great to see a second Bug Crush effort!
>>>>>>>>>> 
>>>>>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>>>>>> backport bug fixes to the R13 branch.
>>>>>>>>>> I guess it's intended, so why?
>>>>>>>>> I ask this because I already found myself trying to fix issues
>>>>>>>>> in R12
>>>>>>>>> and R11 branches (I know will be soon no longer maintained R11 )
>>>>>>>>> and
>>>>>>>>> found they were already backported in R13
>>>>>>>>>> Jacques
>>>>>>>> 
>>>> 
>>>> --
>>>> Ron Wheeler
>>>> President
>>>> Artifact Software Inc
>>>> email: rwheeler@artifact-software.com
>>>> skype: ronaldmwheeler
>>>> phone: 866-970-2435, ext 102
>>>> 
>>> 
>> 
>> 

Re: Bug Crush

[Adrian Crum <ad...@sandglass-software.com>]

This discussion seems to be spinning off into a strange direction.

I stated my personal perspective on backporting bug fixes, and the 
amount of backporting my free time allows. Others are free to disagree 
with me.

I might be wrong, but it seems to me you are suggesting the PMC should 
twist my arm to do a more thorough job of backporting bug fixes. If that 
is true, then you need to understand that is not the PMC's role. Even if 
it was, I would reject that attempt and restate my viewpoint: If the bug 
fix backport is important enough to someone, then they will do it 
themselves.

Even if that isn't what you are suggesting, you seem to be TELLING the 
PMC its role, instead of LEARNING the PMC's role.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 9/21/2014 2:45 PM, Ron Wheeler wrote:
> The PMC has to manage the team.
> It is called a Project MANAGEMENT Committee for a reason.
>
> You are right that the PMC can not order anyone to do anything.
> Apache is based on volunteers working together as a team.
> That does not mean that the Committee is powerless.
> It has to work in a collaborative way to manage the project.
> This means setting policy, setting priorities and assigning tasks or
> more accurately soliciting volunteers to do tasks that the PMC
> identifies as important.
> It means agreeing on dates by which tasks will be performed and taking
> action when it is clear that volunteers are not going to be able to
> finish work that they have agreed to do for whatever reason. This action
> may be soliciting additional help, revising dates to match reality or
> revising scope or a combination.
>
> The PMC should make sure that the people fixing the bugs understand that
> the bugs need to be fixed in all supported versions if that is the
> Policy of the PMC.
> If they are not willing to follow the direction of the PMC, the the PMC
> needs to act.
>
> The "merit" in meritocracy does not just mean code. It also means team
> commitment, collaboration skills and management. If someone does not
> want to work in a collaborative way and only does the parts of a task
> that appeals to them, they should be treated in the same way as someone
> who commits code that only fixes the interesting part of the bug and
> breaks other code or someone who doesn't want to use the framework and
> rewrites code to directly access data rather than using the framework.
> Some behaviour is not acceptable to the PMC regardless of how much time
> the volunteer is willing to put in.
>
> How often does the PMC meet?
> When was the last set of minutes published?
> What is the most significant policy decision or other issue that the PMC
> is currently working on?
> When was the last PMC meeting about the release roadmap?
>
> Ron
>
> On 21/09/2014 8:50 AM, Jacopo Cappellato wrote:
>> The PMC doesn't manage a team: we can't ask people to work on what we
>> think is important.
>> The persons that contribute code to the project (and backport
>> features) are persons like you and me, and the PMC doesn't have the
>> authority or will to assign tasks to them.
>> In fact, I doubt I could ask you to test and backport to 12.04 all the
>> 59 features that the have been committed yesterday :-)
>>
>> Regards,
>>
>> Jacopo
>>
>> On Sep 21, 2014, at 2:31 PM, Ron Wheeler
>> <rw...@artifact-software.com> wrote:
>>
>>> No one has time to fix all of the bugs by themselves but by managing
>>> the team, it should be possible to get all of the required work done.
>>>
>>> The PMC needs to develop a consensus about how bugs are handled in
>>> the official releases and then make lists of things that need doing.
>>> If a bug is found and added to he JIRA, determining which releases it
>>> applies to should be part of the analysis.
>>>
>>> If a patch is developed it should be possible to apply it to each
>>> release at the same time.
>>>
>>>
>>> Ron
>>>
>>>
>>> On 20/09/2014 12:47 PM, Adrian Crum wrote:
>>>> I don't have time to maintain 4 code bases (trunk + 3 branches). I
>>>> will fix things in the trunk, and I will backport those fixes to the
>>>> most recent branch. I have no interest in older branches. If someone
>>>> else is using them, then they can create a patch for them. So, I
>>>> have no issues with releasing old branches with missing fixes -
>>>> because if anyone really cared about them they would work harder to
>>>> maintain them.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>>>>> It seems a bit weird to me to officially release code with bugs
>>>>> when we
>>>>> have already bug fixes in trunk
>>>>>
>>>>> Jacques
>>>>>
>>>>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>>>>>  From my perspective, anyone wanting to use older versions can
>>>>>> backport
>>>>>> the changes themselves - either locally, or in the release
>>>>>> branches by
>>>>>> providing a patch.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>>>>> Hello Jacques,
>>>>>>>
>>>>>>> Thanks for your kind words. We started this event considering the
>>>>>>> fact
>>>>>>> to provide fixes for trunk and latest release branch which is
>>>>>>> 13.07. It
>>>>>>> will be of great help if someone from community could pick and
>>>>>>> back port
>>>>>>> the required changes to Release Branch 12.04. In future if we get
>>>>>>> time
>>>>>>> we will also be taking care of back porting to R12.04.
>>>>>>>
>>>>>>> We didn't back port changes in R11.04 just because it is very old
>>>>>>> branch
>>>>>>> and very soon will not be maintained. Thanks.
>>>>>>>
>>>>>>> --
>>>>>>> Kind Regards
>>>>>>> Ashish Vijaywargiya
>>>>>>> HotWax Media - est. 1997
>>>>>>> ApacheCon US 2014 Silver Sponsor
>>>>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>>>>
>>>>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> It's great to see a second Bug Crush effort!
>>>>>>>>>
>>>>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>>>>> backport bug fixes to the R13 branch.
>>>>>>>>> I guess it's intended, so why?
>>>>>>>> I ask this because I already found myself trying to fix issues
>>>>>>>> in R12
>>>>>>>> and R11 branches (I know will be soon no longer maintained R11 )
>>>>>>>> and
>>>>>>>> found they were already backported in R13
>>>>>>>>> Jacques
>>>>>>>
>>>
>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwheeler@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>
>
>

Re: Bug Crush

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

I don't have time to reply at the moment but you should find useful information about the ASF and its PMCs in the apache website.

Jacopo

On Sep 21, 2014, at 3:45 PM, Ron Wheeler <rw...@artifact-software.com> wrote:

> The PMC has to manage the team.
> It is called a Project MANAGEMENT Committee for a reason.
> 
> You are right that the PMC can not order anyone to do anything.
> Apache is based on volunteers working together as a team.
> That does not mean that the Committee is powerless.
> It has to work in a collaborative way to manage the project.
> This means setting policy, setting priorities and assigning tasks or more accurately soliciting volunteers to do tasks that the PMC identifies as important.
> It means agreeing on dates by which tasks will be performed and taking action when it is clear that volunteers are not going to be able to finish work that they have agreed to do for whatever reason. This action may be soliciting additional help, revising dates to match reality or revising scope or a combination.
> 
> The PMC should make sure that the people fixing the bugs understand that the bugs need to be fixed in all supported versions if that is the Policy of the PMC.
> If they are not willing to follow the direction of the PMC, the the PMC needs to act.
> 
> The "merit" in meritocracy does not just mean code. It also means team commitment, collaboration skills and management. If someone does not want to work in a collaborative way and only does the parts of a task that appeals to them, they should be treated in the same way as someone who commits code that only fixes the interesting part of the bug and breaks other code or someone who doesn't want to use the framework and rewrites code to directly access data rather than using the framework. Some behaviour is not acceptable to the PMC regardless of how much time the volunteer is willing to put in.
> 
> How often does the PMC meet?
> When was the last set of minutes published?
> What is the most significant policy decision or other issue that the PMC is currently working on?
> When was the last PMC meeting about the release roadmap?
> 
> Ron
> 
> On 21/09/2014 8:50 AM, Jacopo Cappellato wrote:
>> The PMC doesn't manage a team: we can't ask people to work on what we think is important.
>> The persons that contribute code to the project (and backport features) are persons like you and me, and the PMC doesn't have the authority or will to assign tasks to them.
>> In fact, I doubt I could ask you to test and backport to 12.04 all the 59 features that the have been committed yesterday :-)
>> 
>> Regards,
>> 
>> Jacopo
>> 
>> On Sep 21, 2014, at 2:31 PM, Ron Wheeler <rw...@artifact-software.com> wrote:
>> 
>>> No one has time to fix all of the bugs by themselves but by managing the team, it should be possible to get all of the required work done.
>>> 
>>> The PMC needs to develop a consensus about how bugs are handled in the official releases and then make lists of things that need doing.
>>> If a bug is found and added to he JIRA, determining which releases it applies to should be part of the analysis.
>>> 
>>> If a patch is developed it should be possible to apply it to each release at the same time.
>>> 
>>> 
>>> Ron
>>> 
>>> 
>>> On 20/09/2014 12:47 PM, Adrian Crum wrote:
>>>> I don't have time to maintain 4 code bases (trunk + 3 branches). I will fix things in the trunk, and I will backport those fixes to the most recent branch. I have no interest in older branches. If someone else is using them, then they can create a patch for them. So, I have no issues with releasing old branches with missing fixes - because if anyone really cared about them they would work harder to maintain them.
>>>> 
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>> 
>>>> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>>>>> It seems a bit weird to me to officially release code with bugs when we
>>>>> have already bug fixes in trunk
>>>>> 
>>>>> Jacques
>>>>> 
>>>>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>>>>> From my perspective, anyone wanting to use older versions can backport
>>>>>> the changes themselves - either locally, or in the release branches by
>>>>>> providing a patch.
>>>>>> 
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>> 
>>>>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>>>>> Hello Jacques,
>>>>>>> 
>>>>>>> Thanks for your kind words. We started this event considering the fact
>>>>>>> to provide fixes for trunk and latest release branch which is 13.07. It
>>>>>>> will be of great help if someone from community could pick and back port
>>>>>>> the required changes to Release Branch 12.04. In future if we get time
>>>>>>> we will also be taking care of back porting to R12.04.
>>>>>>> 
>>>>>>> We didn't back port changes in R11.04 just because it is very old branch
>>>>>>> and very soon will not be maintained. Thanks.
>>>>>>> 
>>>>>>> -- 
>>>>>>> Kind Regards
>>>>>>> Ashish Vijaywargiya
>>>>>>> HotWax Media - est. 1997
>>>>>>> ApacheCon US 2014 Silver Sponsor
>>>>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>>>> 
>>>>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> It's great to see a second Bug Crush effort!
>>>>>>>>> 
>>>>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>>>>> backport bug fixes to the R13 branch.
>>>>>>>>> I guess it's intended, so why?
>>>>>>>> I ask this because I already found myself trying to fix issues in R12
>>>>>>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>>>>>>> found they were already backported in R13
>>>>>>>>> Jacques
>>>>>>> 
>>> 
>>> -- 
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwheeler@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>> 
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 

Re: Bug Crush

[Ron Wheeler <rw...@artifact-software.com>]

The PMC has to manage the team.
It is called a Project MANAGEMENT Committee for a reason.

You are right that the PMC can not order anyone to do anything.
Apache is based on volunteers working together as a team.
That does not mean that the Committee is powerless.
It has to work in a collaborative way to manage the project.
This means setting policy, setting priorities and assigning tasks or 
more accurately soliciting volunteers to do tasks that the PMC 
identifies as important.
It means agreeing on dates by which tasks will be performed and taking 
action when it is clear that volunteers are not going to be able to 
finish work that they have agreed to do for whatever reason. This action 
may be soliciting additional help, revising dates to match reality or 
revising scope or a combination.

The PMC should make sure that the people fixing the bugs understand that 
the bugs need to be fixed in all supported versions if that is the 
Policy of the PMC.
If they are not willing to follow the direction of the PMC, the the PMC 
needs to act.

The "merit" in meritocracy does not just mean code. It also means team 
commitment, collaboration skills and management. If someone does not 
want to work in a collaborative way and only does the parts of a task 
that appeals to them, they should be treated in the same way as someone 
who commits code that only fixes the interesting part of the bug and 
breaks other code or someone who doesn't want to use the framework and 
rewrites code to directly access data rather than using the framework. 
Some behaviour is not acceptable to the PMC regardless of how much time 
the volunteer is willing to put in.

How often does the PMC meet?
When was the last set of minutes published?
What is the most significant policy decision or other issue that the PMC 
is currently working on?
When was the last PMC meeting about the release roadmap?

Ron

On 21/09/2014 8:50 AM, Jacopo Cappellato wrote:
> The PMC doesn't manage a team: we can't ask people to work on what we think is important.
> The persons that contribute code to the project (and backport features) are persons like you and me, and the PMC doesn't have the authority or will to assign tasks to them.
> In fact, I doubt I could ask you to test and backport to 12.04 all the 59 features that the have been committed yesterday :-)
>
> Regards,
>
> Jacopo
>
> On Sep 21, 2014, at 2:31 PM, Ron Wheeler <rw...@artifact-software.com> wrote:
>
>> No one has time to fix all of the bugs by themselves but by managing the team, it should be possible to get all of the required work done.
>>
>> The PMC needs to develop a consensus about how bugs are handled in the official releases and then make lists of things that need doing.
>> If a bug is found and added to he JIRA, determining which releases it applies to should be part of the analysis.
>>
>> If a patch is developed it should be possible to apply it to each release at the same time.
>>
>>
>> Ron
>>
>>
>> On 20/09/2014 12:47 PM, Adrian Crum wrote:
>>> I don't have time to maintain 4 code bases (trunk + 3 branches). I will fix things in the trunk, and I will backport those fixes to the most recent branch. I have no interest in older branches. If someone else is using them, then they can create a patch for them. So, I have no issues with releasing old branches with missing fixes - because if anyone really cared about them they would work harder to maintain them.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>>>> It seems a bit weird to me to officially release code with bugs when we
>>>> have already bug fixes in trunk
>>>>
>>>> Jacques
>>>>
>>>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>>>>  From my perspective, anyone wanting to use older versions can backport
>>>>> the changes themselves - either locally, or in the release branches by
>>>>> providing a patch.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>>>> Hello Jacques,
>>>>>>
>>>>>> Thanks for your kind words. We started this event considering the fact
>>>>>> to provide fixes for trunk and latest release branch which is 13.07. It
>>>>>> will be of great help if someone from community could pick and back port
>>>>>> the required changes to Release Branch 12.04. In future if we get time
>>>>>> we will also be taking care of back porting to R12.04.
>>>>>>
>>>>>> We didn't back port changes in R11.04 just because it is very old branch
>>>>>> and very soon will not be maintained. Thanks.
>>>>>>
>>>>>> -- 
>>>>>> Kind Regards
>>>>>> Ashish Vijaywargiya
>>>>>> HotWax Media - est. 1997
>>>>>> ApacheCon US 2014 Silver Sponsor
>>>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>>>
>>>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> It's great to see a second Bug Crush effort!
>>>>>>>>
>>>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>>>> backport bug fixes to the R13 branch.
>>>>>>>> I guess it's intended, so why?
>>>>>>> I ask this because I already found myself trying to fix issues in R12
>>>>>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>>>>>> found they were already backported in R13
>>>>>>>> Jacques
>>>>>>
>>
>> -- 
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Bug Crush

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

The PMC doesn't manage a team: we can't ask people to work on what we think is important.
The persons that contribute code to the project (and backport features) are persons like you and me, and the PMC doesn't have the authority or will to assign tasks to them.
In fact, I doubt I could ask you to test and backport to 12.04 all the 59 features that the have been committed yesterday :-)

Regards,

Jacopo

On Sep 21, 2014, at 2:31 PM, Ron Wheeler <rw...@artifact-software.com> wrote:

> No one has time to fix all of the bugs by themselves but by managing the team, it should be possible to get all of the required work done.
> 
> The PMC needs to develop a consensus about how bugs are handled in the official releases and then make lists of things that need doing.
> If a bug is found and added to he JIRA, determining which releases it applies to should be part of the analysis.
> 
> If a patch is developed it should be possible to apply it to each release at the same time.
> 
> 
> Ron
> 
> 
> On 20/09/2014 12:47 PM, Adrian Crum wrote:
>> I don't have time to maintain 4 code bases (trunk + 3 branches). I will fix things in the trunk, and I will backport those fixes to the most recent branch. I have no interest in older branches. If someone else is using them, then they can create a patch for them. So, I have no issues with releasing old branches with missing fixes - because if anyone really cared about them they would work harder to maintain them.
>> 
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>> 
>> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>>> It seems a bit weird to me to officially release code with bugs when we
>>> have already bug fixes in trunk
>>> 
>>> Jacques
>>> 
>>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>>> From my perspective, anyone wanting to use older versions can backport
>>>> the changes themselves - either locally, or in the release branches by
>>>> providing a patch.
>>>> 
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>> 
>>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>>> Hello Jacques,
>>>>> 
>>>>> Thanks for your kind words. We started this event considering the fact
>>>>> to provide fixes for trunk and latest release branch which is 13.07. It
>>>>> will be of great help if someone from community could pick and back port
>>>>> the required changes to Release Branch 12.04. In future if we get time
>>>>> we will also be taking care of back porting to R12.04.
>>>>> 
>>>>> We didn't back port changes in R11.04 just because it is very old branch
>>>>> and very soon will not be maintained. Thanks.
>>>>> 
>>>>> -- 
>>>>> Kind Regards
>>>>> Ashish Vijaywargiya
>>>>> HotWax Media - est. 1997
>>>>> ApacheCon US 2014 Silver Sponsor
>>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>> 
>>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>> 
>>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>>> Hi,
>>>>>>> 
>>>>>>> It's great to see a second Bug Crush effort!
>>>>>>> 
>>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>>> backport bug fixes to the R13 branch.
>>>>>>> I guess it's intended, so why?
>>>>>> I ask this because I already found myself trying to fix issues in R12
>>>>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>>>>> found they were already backported in R13
>>>>>>> Jacques
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 

Re: Bug Crush

[Ron Wheeler <rw...@artifact-software.com>]

No one has time to fix all of the bugs by themselves but by managing the 
team, it should be possible to get all of the required work done.

The PMC needs to develop a consensus about how bugs are handled in the 
official releases and then make lists of things that need doing.
If a bug is found and added to he JIRA, determining which releases it 
applies to should be part of the analysis.

If a patch is developed it should be possible to apply it to each 
release at the same time.


Ron


On 20/09/2014 12:47 PM, Adrian Crum wrote:
> I don't have time to maintain 4 code bases (trunk + 3 branches). I 
> will fix things in the trunk, and I will backport those fixes to the 
> most recent branch. I have no interest in older branches. If someone 
> else is using them, then they can create a patch for them. So, I have 
> no issues with releasing old branches with missing fixes - because if 
> anyone really cared about them they would work harder to maintain them.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
>> It seems a bit weird to me to officially release code with bugs when we
>> have already bug fixes in trunk
>>
>> Jacques
>>
>> Le 20/09/2014 17:17, Adrian Crum a écrit :
>>> From my perspective, anyone wanting to use older versions can backport
>>> the changes themselves - either locally, or in the release branches by
>>> providing a patch.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>>> Hello Jacques,
>>>>
>>>> Thanks for your kind words. We started this event considering the fact
>>>> to provide fixes for trunk and latest release branch which is 
>>>> 13.07. It
>>>> will be of great help if someone from community could pick and back 
>>>> port
>>>> the required changes to Release Branch 12.04. In future if we get time
>>>> we will also be taking care of back porting to R12.04.
>>>>
>>>> We didn't back port changes in R11.04 just because it is very old 
>>>> branch
>>>> and very soon will not be maintained. Thanks.
>>>>
>>>> -- 
>>>> Kind Regards
>>>> Ashish Vijaywargiya
>>>> HotWax Media - est. 1997
>>>> ApacheCon US 2014 Silver Sponsor
>>>> http://na.apachecon.com/sponsor/our-sponsors
>>>>
>>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>>
>>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>>> Hi,
>>>>>>
>>>>>> It's great to see a second Bug Crush effort!
>>>>>>
>>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>>> backport bug fixes to the R13 branch.
>>>>>> I guess it's intended, so why?
>>>>> I ask this because I already found myself trying to fix issues in R12
>>>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>>>> found they were already backported in R13
>>>>>> Jacques
>>>>>
>>>>
>>>>
>>>
>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Bug Crush

[Adrian Crum <ad...@sandglass-software.com>]

I don't have time to maintain 4 code bases (trunk + 3 branches). I will 
fix things in the trunk, and I will backport those fixes to the most 
recent branch. I have no interest in older branches. If someone else is 
using them, then they can create a patch for them. So, I have no issues 
with releasing old branches with missing fixes - because if anyone 
really cared about them they would work harder to maintain them.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 9/20/2014 5:29 PM, Jacques Le Roux wrote:
> It seems a bit weird to me to officially release code with bugs when we
> have already bug fixes in trunk
>
> Jacques
>
> Le 20/09/2014 17:17, Adrian Crum a écrit :
>> From my perspective, anyone wanting to use older versions can backport
>> the changes themselves - either locally, or in the release branches by
>> providing a patch.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>>> Hello Jacques,
>>>
>>> Thanks for your kind words. We started this event considering the fact
>>> to provide fixes for trunk and latest release branch which is 13.07. It
>>> will be of great help if someone from community could pick and back port
>>> the required changes to Release Branch 12.04. In future if we get time
>>> we will also be taking care of back porting to R12.04.
>>>
>>> We didn't back port changes in R11.04 just because it is very old branch
>>> and very soon will not be maintained. Thanks.
>>>
>>> --
>>> Kind Regards
>>> Ashish Vijaywargiya
>>> HotWax Media - est. 1997
>>> ApacheCon US 2014 Silver Sponsor
>>> http://na.apachecon.com/sponsor/our-sponsors
>>>
>>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>>
>>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>>> Hi,
>>>>>
>>>>> It's great to see a second Bug Crush effort!
>>>>>
>>>>> I have though a question, I see that you (HotWax Media team) only
>>>>> backport bug fixes to the R13 branch.
>>>>> I guess it's intended, so why?
>>>> I ask this because I already found myself trying to fix issues in R12
>>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>>> found they were already backported in R13
>>>>> Jacques
>>>>
>>>
>>>
>>
>

Re: Bug Crush

[Jacques Le Roux <ja...@les7arts.com>]

It seems a bit weird to me to officially release code with bugs when we have already bug fixes in trunk

Jacques

Le 20/09/2014 17:17, Adrian Crum a écrit :
> From my perspective, anyone wanting to use older versions can backport the changes themselves - either locally, or in the release branches by 
> providing a patch.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>> Hello Jacques,
>>
>> Thanks for your kind words. We started this event considering the fact
>> to provide fixes for trunk and latest release branch which is 13.07. It
>> will be of great help if someone from community could pick and back port
>> the required changes to Release Branch 12.04. In future if we get time
>> we will also be taking care of back porting to R12.04.
>>
>> We didn't back port changes in R11.04 just because it is very old branch
>> and very soon will not be maintained. Thanks.
>>
>> -- 
>> Kind Regards
>> Ashish Vijaywargiya
>> HotWax Media - est. 1997
>> ApacheCon US 2014 Silver Sponsor
>> http://na.apachecon.com/sponsor/our-sponsors
>>
>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>
>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>> Hi,
>>>>
>>>> It's great to see a second Bug Crush effort!
>>>>
>>>> I have though a question, I see that you (HotWax Media team) only
>>>> backport bug fixes to the R13 branch.
>>>> I guess it's intended, so why?
>>> I ask this because I already found myself trying to fix issues in R12
>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>> found they were already backported in R13
>>>> Jacques
>>>
>>
>>
>

Re: Bug Crush

[Ron Wheeler <rw...@artifact-software.com>]

According the website, 12.04 is the current version and as such, users 
would expect bugs to be fixed in this release.

The website is a bit vague about the status of 11.04.06   " it is 
probably the last release of this series."
Perhaps the PMC should take a few minutes to make a decision about this.

 From an outside point of view, it is hard to imagine how the current 
official release would not be getting bug fixes.
There would normally be an expectation that 12.04.06 will be produced 
someday in the not too distant future and include all of the bug fixes 
that are currently going into 13.07.
No new features of course.

What is the policy for the supported lifetime of a release?
Does OFBiz have a statement of policy about how many years a release 
will be supported?
Most systems that are this critical to a business should provide an 
"end-of-life" plan for each release so people can make their own  
lifecycle management plans.

Ron


On 20/09/2014 11:17 AM, Adrian Crum wrote:
> From my perspective, anyone wanting to use older versions can backport 
> the changes themselves - either locally, or in the release branches by 
> providing a patch.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
>> Hello Jacques,
>>
>> Thanks for your kind words. We started this event considering the fact
>> to provide fixes for trunk and latest release branch which is 13.07. It
>> will be of great help if someone from community could pick and back port
>> the required changes to Release Branch 12.04. In future if we get time
>> we will also be taking care of back porting to R12.04.
>>
>> We didn't back port changes in R11.04 just because it is very old branch
>> and very soon will not be maintained. Thanks.
>>
>> -- 
>> Kind Regards
>> Ashish Vijaywargiya
>> HotWax Media - est. 1997
>> ApacheCon US 2014 Silver Sponsor
>> http://na.apachecon.com/sponsor/our-sponsors
>>
>> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>>
>>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>>> Hi,
>>>>
>>>> It's great to see a second Bug Crush effort!
>>>>
>>>> I have though a question, I see that you (HotWax Media team) only
>>>> backport bug fixes to the R13 branch.
>>>> I guess it's intended, so why?
>>> I ask this because I already found myself trying to fix issues in R12
>>> and R11 branches (I know will be soon no longer maintained R11 ) and
>>> found they were already backported in R13
>>>> Jacques
>>>
>>
>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Bug Crush

[Adrian Crum <ad...@sandglass-software.com>]

 From my perspective, anyone wanting to use older versions can backport 
the changes themselves - either locally, or in the release branches by 
providing a patch.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 9/20/2014 4:07 PM, Ashish Vijaywargiya wrote:
> Hello Jacques,
>
> Thanks for your kind words. We started this event considering the fact
> to provide fixes for trunk and latest release branch which is 13.07. It
> will be of great help if someone from community could pick and back port
> the required changes to Release Branch 12.04. In future if we get time
> we will also be taking care of back porting to R12.04.
>
> We didn't back port changes in R11.04 just because it is very old branch
> and very soon will not be maintained. Thanks.
>
> --
> Kind Regards
> Ashish Vijaywargiya
> HotWax Media - est. 1997
> ApacheCon US 2014 Silver Sponsor
> http://na.apachecon.com/sponsor/our-sponsors
>
> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>
>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>> Hi,
>>>
>>> It's great to see a second Bug Crush effort!
>>>
>>> I have though a question, I see that you (HotWax Media team) only
>>> backport bug fixes to the R13 branch.
>>> I guess it's intended, so why?
>> I ask this because I already found myself trying to fix issues in R12
>> and R11 branches (I know will be soon no longer maintained R11 ) and
>> found they were already backported in R13
>>> Jacques
>>
>
>

Re: Bug Crush

[Jacques Le Roux <ja...@les7arts.com>]

Hi Ashish,

Ah, I read your answer after Adrian's. Anyway what do you think about my proposition?

Jacques

Le 20/09/2014 17:07, Ashish Vijaywargiya a écrit :
> Hello Jacques,
>
> Thanks for your kind words. We started this event considering the fact to provide fixes for trunk and latest release branch which is 13.07. It will 
> be of great help if someone from community could pick and back port the required changes to Release Branch 12.04. In future if we get time we will 
> also be taking care of back porting to R12.04.
>
> We didn't back port changes in R11.04 just because it is very old branch and very soon will not be maintained. Thanks.
>
> -- 
> Kind Regards
> Ashish Vijaywargiya
> HotWax Media - est. 1997
> ApacheCon US 2014 Silver Sponsor
> http://na.apachecon.com/sponsor/our-sponsors
>
> On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>>
>> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>>> Hi,
>>>
>>> It's great to see a second Bug Crush effort!
>>>
>>> I have though a question, I see that you (HotWax Media team) only backport bug fixes to the R13 branch.
>>> I guess it's intended, so why?
>> I ask this because I already found myself trying to fix issues in R12 and R11 branches (I know will be soon no longer maintained R11 ) and found 
>> they were already backported in R13
>>> Jacques
>>
>
>

Re: Bug Crush

[Ashish Vijaywargiya <as...@hotwaxmedia.com>]

Hello Jacques,

Thanks for your kind words. We started this event considering the fact 
to provide fixes for trunk and latest release branch which is 13.07. It 
will be of great help if someone from community could pick and back port 
the required changes to Release Branch 12.04. In future if we get time 
we will also be taking care of back porting to R12.04.

We didn't back port changes in R11.04 just because it is very old branch 
and very soon will not be maintained. Thanks.

--
Kind Regards
Ashish Vijaywargiya
HotWax Media - est. 1997
ApacheCon US 2014 Silver Sponsor
http://na.apachecon.com/sponsor/our-sponsors

On Saturday 20 September 2014 05:01 PM, Jacques Le Roux wrote:
>
> Le 20/09/2014 13:28, Jacques Le Roux a écrit :
>> Hi,
>>
>> It's great to see a second Bug Crush effort!
>>
>> I have though a question, I see that you (HotWax Media team) only 
>> backport bug fixes to the R13 branch.
>> I guess it's intended, so why?
> I ask this because I already found myself trying to fix issues in R12 
> and R11 branches (I know will be soon no longer maintained R11 ) and 
> found they were already backported in R13
>> Jacques
>

Re: Bug Crush

[Jacques Le Roux <ja...@les7arts.com>]

Le 20/09/2014 13:28, Jacques Le Roux a écrit :
> Hi,
>
> It's great to see a second Bug Crush effort!
>
> I have though a question, I see that you (HotWax Media team) only backport bug fixes to the R13 branch.
> I guess it's intended, so why?
I ask this because I already found myself trying to fix issues in R12 and R11 branches (I know will be soon no longer maintained R11 ) and found they 
were already backported in R13
> Jacques