Release Strategy and Branch Support (was: Re: Bug Crush)

[Pierre Smits <pi...@gmail.com>]

Jacopo,

Your first suggestion is a bit cumbersome. If an issue affects multiple
versions and it is not fixed in all versions, why not simply keep it open
as long as the release branch it affects is in the maintenance cycle?

Your second suggestion is ambiguous.
Which part of the community are you referring to with respect to decreased
interest?
What if the installed versions amongst our user base is significant
different than you expect? We can suggest the users what to use, but it is
down to migration costs and added value of the newer version how customers
decide.

And what if there is enough interest among the non-committing contributors
to continue to support a release branch, while none of the committers is
willing to? Is the PMC going to invite these non-committing contributors to
be committers as well?

Pierre Smits

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

On Mon, Sep 22, 2014 at 3:51 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> 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
> * 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
>
>
>

Re: Release Strategy and Branch Support (was: Re: Bug Crush)

[Pierre Smits <pi...@gmail.com>]

Jacopo,

Thank you for the elaborate reply.

Hopefully the survey Sharan has put together, will provide the insights
about what OFBiz version are being used at the moment.

But, if to many of the current active community members fill in the survey
as well, we might expect to see a lot of the same answers that renders the
survey useless. E.g. when a multitude of contributors of HWM fill out the
questionnaire, we can expect that they all will state (with negligible
variances) the same versions that they support for HWM customers.

If we do get the response we want, namely feedback of a large and diverse
population of the users (I don't know whether we can validate this),
decisions need to be taken with regards to our release and maintenance
strategy.

And the questions you circumvented in your posting, need to be addressed.

Pierre Smits

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

On Mon, Sep 22, 2014 at 8:02 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> wrote:

>
> On Sep 22, 2014, at 6:42 PM, Pierre Smits <pi...@gmail.com> wrote:
>
> > Jacopo,
> >
> > Your first suggestion is a bit cumbersome. If an issue affects multiple
> > versions and it is not fixed in all versions, why not simply keep it open
> > as long as the release branch it affects is in the maintenance cycle?
>
> I have to provide a "technical" response; I apologize but without this
> information you can't appreciate my proposal.
> The reason is that if we not close the ticket, it will not appear in the
> release notes of the releases of the branches where it has been backported.
>
> >
> > Your second suggestion is ambiguous.
> > Which part of the community are you referring to with respect to
> decreased
> > interest?
> > What if the installed versions amongst our user base is significant
> > different than you expect? We can suggest the users what to use, but it
> is
> > down to migration costs and added value of the newer version how
> customers
> > decide.
>
> Of course we always appreciate when a bug fix is backported to all the
> active release branches.
> Unfortunately we can't impose this rule to the committers (that are
> already donating hours of their free time to the community) or to the
> contributors (that are already donating their contributions).
> I am not saying this is good or bad... it is just the reality of every
> open source project that is not backed up by a company.
> A release branch can only stay active if there are interested parties
> helping it to stay alive, by reporting bugs, contributing patches, testing
> patches and backporting patches from the trunk.
> This is actually not different from the work done on new features in the
> trunk: people interested in them (committers or not) contribute code
> because they either need it or simply for the greater good of the project.
> My proposal is an attempt to try to address the situation when very few
> contributors are backporting patches to an old(ish) release branch: a vote
> in the community would be a warning message saying that the branch is
> currently not well maintained; this would give a chance to users that can
> help (either companies with a development team or individuals with
> technical skills) to step in and become more involved in the project; on
> the other hand, if not enough people show up at least the users will know
> that they have to migrate to a newer release or live with the current
> (dying) branch.
>
> Jacopo
>
>
> >
> > And what if there is enough interest among the non-committing
> contributors
> > to continue to support a release branch, while none of the committers is
> > willing to? Is the PMC going to invite these non-committing contributors
> to
> > be committers as well?
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM <http://www.orrtiz.com>*
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Mon, Sep 22, 2014 at 3:51 PM, Jacopo Cappellato <
> > jacopo.cappellato@hotwaxmedia.com> 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
> >> * 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
> >>
> >>
> >>
>
>

Re: Release Strategy and Branch Support (was: Re: Bug Crush)

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

On Sep 22, 2014, at 6:42 PM, Pierre Smits <pi...@gmail.com> wrote:

> Jacopo,
> 
> Your first suggestion is a bit cumbersome. If an issue affects multiple
> versions and it is not fixed in all versions, why not simply keep it open
> as long as the release branch it affects is in the maintenance cycle?

I have to provide a "technical" response; I apologize but without this information you can't appreciate my proposal.
The reason is that if we not close the ticket, it will not appear in the release notes of the releases of the branches where it has been backported.

> 
> Your second suggestion is ambiguous.
> Which part of the community are you referring to with respect to decreased
> interest?
> What if the installed versions amongst our user base is significant
> different than you expect? We can suggest the users what to use, but it is
> down to migration costs and added value of the newer version how customers
> decide.

Of course we always appreciate when a bug fix is backported to all the active release branches.
Unfortunately we can't impose this rule to the committers (that are already donating hours of their free time to the community) or to the contributors (that are already donating their contributions).
I am not saying this is good or bad... it is just the reality of every open source project that is not backed up by a company.
A release branch can only stay active if there are interested parties helping it to stay alive, by reporting bugs, contributing patches, testing patches and backporting patches from the trunk.
This is actually not different from the work done on new features in the trunk: people interested in them (committers or not) contribute code because they either need it or simply for the greater good of the project.
My proposal is an attempt to try to address the situation when very few contributors are backporting patches to an old(ish) release branch: a vote in the community would be a warning message saying that the branch is currently not well maintained; this would give a chance to users that can help (either companies with a development team or individuals with technical skills) to step in and become more involved in the project; on the other hand, if not enough people show up at least the users will know that they have to migrate to a newer release or live with the current (dying) branch.

Jacopo


> 
> And what if there is enough interest among the non-committing contributors
> to continue to support a release branch, while none of the committers is
> willing to? Is the PMC going to invite these non-committing contributors to
> be committers as well?
> 
> Pierre Smits
> 
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> On Mon, Sep 22, 2014 at 3:51 PM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxmedia.com> 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
>> * 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
>> 
>> 
>> 

Re: Release Strategy and Branch Support

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

Yes and we have started to update those pages.

What is missing that the other projects include, are statements about 
the intended end of the periods during which users can expect new 
features to be added and when there will only be security/severe bug 
fixed and when the version will be officially retired and no code 
changes by the team.


Ron

On 22/09/2014 3:15 PM, Jacopo Cappellato wrote:
> We are maintaining somewhat similar information in these pages:
>
> http://ofbiz.apache.org/download.html
> http://www.apache.org/dist/ofbiz/
>
> Jacopo
>
> On Sep 22, 2014, at 8:31 PM, Ron Wheeler <rw...@artifact-software.com> wrote:
>
>> Here are some examples of End Of Life policy statements for open source products.
>>
>> http://wiki.centos.org/About/Product
>> http://tomcat.apache.org/tomcat-55-eol.html
>> http://www.openoffice.org/development/releases/eol.html
>>
>>
>> http://support.rightscale.com/15-References/End_of_Support_and_End_of_Life_Schedule is a very nice presentation of EOS and EOL dates with definitions.
>>
>> Perhaps the PMC can take up this issue and settle what they want to offer as a "warranty" to users who download a version or have a version installed and are making their upgrade and security calculations for their ERP.
>>
>>
>>
>> Ron
>>
>>
>>
>> On 22/09/2014 12:42 PM, Pierre Smits wrote:
>>> Jacopo,
>>>
>>> Your first suggestion is a bit cumbersome. If an issue affects multiple
>>> versions and it is not fixed in all versions, why not simply keep it open
>>> as long as the release branch it affects is in the maintenance cycle?
>>>
>>> Your second suggestion is ambiguous.
>>> Which part of the community are you referring to with respect to decreased
>>> interest?
>>> What if the installed versions amongst our user base is significant
>>> different than you expect? We can suggest the users what to use, but it is
>>> down to migration costs and added value of the newer version how customers
>>> decide.
>>>
>>> And what if there is enough interest among the non-committing contributors
>>> to continue to support a release branch, while none of the committers is
>>> willing to? Is the PMC going to invite these non-committing contributors to
>>> be committers as well?
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Mon, Sep 22, 2014 at 3:51 PM, Jacopo Cappellato <
>>> jacopo.cappellato@hotwaxmedia.com> 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
>>>> * 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
>>>>
>>>>
>>>>
>>
>> -- 
>> 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: Release Strategy and Branch Support

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

Done, see http://ofbiz.apache.org/download.html

Jacques

Le 23/03/2015 08:31, Jacques Le Roux a écrit :
> Ha just a small change I wrote that we should state in download page that
> *not all bug fixes are backported to all living release branches*
> Should be
> *despite our best effort, not all bug fixes are backported to all living release branches* ;)
>
> Jacques
>
> Le 22/03/2015 14:49, Ron Wheeler a écrit :
>> Great discussion.
>>
>> IMHO, bug fixes are different from enhancements. A fix is a gift to the community (specially if you are fixing something that someone else broke). 
>> Enhancement are usually done to add something that a small group wants and they have to take more responsibility to maintain it and have more of a 
>> role in deciding if it is to be backported.
>>
>> If someone takes the time to fix something, I am not sure that they are also responsible for doing all the backports (as called for in the "no good 
>> deed goes unpunished" clause of the programmers creed.)
>> If the consensus is that a bug fix must be backported, it is not just the responsibility of the person who fixes it in the trunk (or wherever), it 
>> is a community commitment to the integrity of the product.
>>
>> It becomes a blocker to the next release of that branch.
>>
>> In an ERP, there needs to be a bit wider view of a "security patch".
>> If you have a bug that will result in a user company shipping a product without getting paid or manufacturing items to fill a non-existant order 
>> backlog, perhaps that qualifies as a "security release".
>>
>>
>> As long as each decision is made and communicated in a transparent way, I think that most people will be able to live with the process.
>>
>> Ron
>>
>> On 22/03/2015 5:48 AM, Jacques Le Roux wrote:
>>> I was re-reading this thread because I think it's important and we need to clarify 3 things
>>>
>>> 1) how to decide when a branch is no longer supported (vs is alive)
>>> 2) what are the backporting rule
>>> 3) what to show on our OFBiz download page
>>>
>>> In this thread we have already discussed the 2 last points below, but not the 1st.
>>>
>>> 1) EOL date
>>> I don't think we should make a distinction with EOS - End Of Support - as Ron proposed
>>> It seems to me this should be a community decision leading to the creation of a page like http://tomcat.apache.org/tomcat-55-eol.html linked from 
>>> OFBiz download page
>>> So we should decide of this date using a [PROPOSAL] thread that anybody can start. With a lazy consensus no further [VOTE] thread should be 
>>> needed, but that could be also.
>>>
>>> 2) Backporting rule
>>> Jacopo proposed
>>>
>>> A more formal rule would be:
>>> a) commits to the trunk from Jira tickets of type Bugs can and*should*  be backported to all the active releases
>>> b) commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be 
>>> backported to a specific active release
>>>
>>> I like it, because it's simple and clear
>>>
>>> a) I agree with the *should* (and not must) in 1st sentence. Because we can't reasonably force committers to backport all bug fixes. Sometimes 
>>> there are too much conflicts, our volunteer time is limited. There is an exception though: all vulnerability fixes *must* be backported. It's 
>>> obvious but better to state it.
>>> _Note_: when Jacopo wrote that, I then answered: <<Yes, hopefully we (I mean the really concerned persons) will not have to enforce (ie do it 
>>> ourselves) the "should" :/ >> Since this discussion we are doing a better job at this, it's heartening to see these results :)
>>> b) The second rule is clear, a committer should not backport a non bug fix w/o the consent (lasy consensus) of a *reasonable number* of other 
>>> committers.
>>>
>>> 3) Here Jacopo suggested to be as concise as possible,
>>>
>>> in my opinion we could improve (and make more evident) the information we already have in the download page where we already mention a tentative 
>>> end of life; for example now we have:
>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>
>>> I agree, I think a page *like* http://tomcat.apache.org/tomcat-55-eol.html (simplified I guess) linked from the sentences like "(last release of 
>>> the 12.04 series)" would help users to know better. Also I'd like that we clearly state on the download page, that, from our (a) "Backporting 
>>> rule", *not all bug fixes are backported to all living release branches*. Our users have to live with it and engage the effort if they need a 
>>> particular bug fix. With the help of the Jira generated releases logs this is now possible. I wrote also that
>>> <<We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (with a link to wiki from 
>>> the download page). >>
>>> <<By comparing the trunk and releases change logs for instance>> and how to use https://svn.apache.org/viewvc/ then.
>>>
>>> So finally not much is missing :)
>>>
>>> Jacques
>>>
>>> Le 23/10/2014 15:08, Ron Wheeler a écrit :
>>>>
>>>>  I think that many projects that are "important" and are hard to upgrade (user facing or customized at each installation) are fully supported 
>>>> until end of support and between EOS and EOL get fixes for bugs that have security implications where publishing the issue and fix to the current 
>>>> release or trunk will give hackers easy access  to data held in the old version or in some way open companies using that version to serious harm.
>>>>
>>>> It may be somewhat difficult to get people to fix older versions but there may be things that we could do to make this more likely.
>>>> 1) Bugs can not be closed until it is fixed in all of the versions to which it must be applied (according to our EOS and EOL rules). It might be 
>>>> better to generate new issue that specifically addresses the patch to be applied rather than a full description of the symptoms of the original 
>>>> problem which is a main feature of the original report and make this new issue a dependency of the original.
>>>> 2) Open a sub-project for the older releases with different committers who are interested in the older version and are not committing to the trunk.
>>>> This might be a way for someone to get started in OFBiz programming.
>>>> The activity in this sub-project would be a good way to judge the community's interest in maintaining the older release. One would expect that 
>>>> companies running the old version would be interested in supporting this sub-project even if they have no interest in the trunk.
>>>>
>>>> Ron
>>>>
>>>>
>>>> On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
>>>>> Inline
>>>>>
>>>>> Le 23/09/2014 09:26, Jacques Le Roux a écrit :
>>>>>>
>>>>>> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
>>>>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>>>>>>
>>>>>>>> <<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.>>
>>>>>>>>
>>>>>>> A more formal rule would be:
>>>>>>> * commits to the trunk from Jira tickets of type Bugs can and *should* be backported to all the active releases
>>>>>> Yes, hopefully we (I mean the really concerned persons) will not have to enforce (ie do it ourselves) the "should" :/
>>>>>>> * commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be 
>>>>>>> backported to a specific active release
>>>>>> Yes it's already like that and those are only rare exceptions, right way for me
>>>>>>>> <<I think we should make that clear and expose a way to users for them to more
>>>>>>>> "easily" maintain the releases they use.>>
>>>>>>> +1 see below
>>>>>>>
>>>>>>>> As suggested Ron we could also define our own or refer to http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>>>>>> Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the 
>>>>>>> download page where we already mention a tentative end of life; for example now we have:
>>>>>>>
>>>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>>>>>
>>>>>>> But when we specify an end of life, we should also make clear a few things:
>>>>>>> * this is a community goal, and the help from the community is required to meet the goal (i.e. it is not guaranteed)
>>>>>> Yes that's an important point indeed. We begin to get traction with (mostly thanks to the bug crush effort so far) and hopefully it will 
>>>>>> continue :)
>>>>>>> * the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the 
>>>>>>> release branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low 
>>>>>>> interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
>>>>>> The point I'd really want to be highlighted/explained is we don't guarantee that old bugs fixed in trunk are backported. Let's face it, we 
>>>>>> can't guarantee that, we have not real means to enforce it.
>>>>>
>>>>> We have still no mention of that in the download page. I recently backported a number of bug fixes done in the last HWM bug crush in R12.04, but 
>>>>> I (nobody I guess) can't guarantee we will always backport all bug fixes in living releases branches. I don't know how other TLP projects do, 
>>>>> but it seems to me that to be correct/honest with our users we need to clarify that. We should even give a mean, or at least a way, to check 
>>>>> that by themselves. By comparing the trunk and releases change logs for instance? I also suggested below
>>>>> <<We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (maybe a link to wiki 
>>>>> from download page to not clutter this main page).
>>>>> I will think about what you wrote above and see how we can inform our our releases users (I mean a process to follow maybe even something more 
>>>>> automated) >>
>>>>>
>>>>> Jacques
>>>>>
>>>>>>>
>>>>>>>> Now we need to think "technical" and automatize as possible with Jira
>>>>>>> In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the 
>>>>>>> information will be more accurate with new releases).
>>>>>>> The idea is to run a query on Jira with the following constraints:
>>>>>>> project = OFBiz
>>>>>>> type = Bug
>>>>>>> status = not resolved
>>>>>>> version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch 
>>>>>>> (e.g. "Release 12.04.05")
>>>>>>>
>>>>>>> The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known 
>>>>>>> and outstanding.
>>>>>>> For them we will need help from the community (committers and non committers) to fix the bugs or backport existing fixes.
>>>>>>>
>>>>>>> In the download page, we could add two links (to Jira) next to each available release:
>>>>>>> 1) known bugs (links to the above report)
>>>>>>> 2) release notes (link to the release notes available now)
>>>>>>>
>>>>>>> One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version 
>>>>>>> affected" set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add 
>>>>>>> "12.04.06" to affected version).
>>>>>>
>>>>>> This will need a strict observance from committers about versions to fix and fixed. I believe it's indeed the right way, anyway we have no 
>>>>>> others/betters (I mean offered by Jira) .
>>>>>>
>>>>>> We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (maybe a link to wiki from 
>>>>>> download page to not clutter this main page).
>>>>>> I will think about what you wrote above and see how we can inform our our releases users (I mean a process to follow maybe even something more 
>>>>>> automated)
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>>
>>>>>>>> What I have read so far from Jacopo seems a good start to me
>>>>>>> Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information 
>>>>>>> when I started the version refactoring in Jira, and this conversation is helping to refine some points.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

Re: Release Strategy and Branch Support

[Pierre Smits <pi...@gmail.com>]

A simple statement as 'it applies to rX.Y too' or changing the applicable
version of the JIRA is be considered as such. But of course, that may
always be verified.

Best regards,

Pierre Smits

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

On Mon, Mar 23, 2015 at 10:07 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:

> +1
>
> Especially if the patch is for a bug that has been already committed to
> the trunk and the contributor has prepared it for a specific branch and
> properly tested it.
>
> Jacopo
>
> On Mar 23, 2015, at 9:59 AM, Pierre Smits <pi...@gmail.com> wrote:
>
> > As soon as a  bug fix ticket pertaining to a specific release branch is
> > created in JIRA, the community should put its best effort in to get it
> > resolved. When a that ticket has a patch, the committers should treat it
> > with a higher priority.
> >
> > That doesn't mean that the project is obliged to have it in next release.
> > It means that the project should do its best to have it in the next best
> > release. There are constraints to be considered.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM <http://www.orrtiz.com>*
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Mon, Mar 23, 2015 at 9:46 AM, Jacopo Cappellato <
> > jacopo.cappellato@hotwaxsystems.com> wrote:
> >
> >> I don't see a specific problem here; I mean, this is a community driven
> >> project and all tasks will need a contribution from the community in
> order
> >> to be implemented, including backports.
> >> If something is not backported to release X.Y and someone is interested
> in
> >> it then the person could implement the backport and test it and
> contribute
> >> it to the community with a Jira ticket.
> >>
> >> Jacopo
> >>
> >> On Mar 23, 2015, at 8:31 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com>
> >> wrote:
> >>
> >>> Ha just a small change I wrote that we should state in download page
> that
> >>> *not all bug fixes are backported to all living release branches*
> >>> Should be
> >>> *despite our best effort, not all bug fixes are backported to all
> living
> >> release branches* ;)
> >>>
> >>> Jacques
> >>>
> >>> Le 22/03/2015 14:49, Ron Wheeler a écrit :
> >>>> Great discussion.
> >>>>
> >>>> IMHO, bug fixes are different from enhancements. A fix is a gift to
> the
> >> community (specially if you are fixing something that someone else
> broke).
> >> Enhancement are usually done to add something that a small group wants
> and
> >> they have to take more responsibility to maintain it and have more of a
> >> role in deciding if it is to be backported.
> >>>>
> >>>> If someone takes the time to fix something, I am not sure that they
> are
> >> also responsible for doing all the backports (as called for in the "no
> good
> >> deed goes unpunished" clause of the programmers creed.)
> >>>> If the consensus is that a bug fix must be backported, it is not just
> >> the responsibility of the person who fixes it in the trunk (or
> wherever),
> >> it is a community commitment to the integrity of the product.
> >>>>
> >>>> It becomes a blocker to the next release of that branch.
> >>>>
> >>>> In an ERP, there needs to be a bit wider view of a "security patch".
> >>>> If you have a bug that will result in a user company shipping a
> product
> >> without getting paid or manufacturing items to fill a non-existant order
> >> backlog, perhaps that qualifies as a "security release".
> >>>>
> >>>>
> >>>> As long as each decision is made and communicated in a transparent
> way,
> >> I think that most people will be able to live with the process.
> >>>>
> >>>> Ron
> >>>>
> >>>> On 22/03/2015 5:48 AM, Jacques Le Roux wrote:
> >>>>> I was re-reading this thread because I think it's important and we
> >> need to clarify 3 things
> >>>>>
> >>>>> 1) how to decide when a branch is no longer supported (vs is alive)
> >>>>> 2) what are the backporting rule
> >>>>> 3) what to show on our OFBiz download page
> >>>>>
> >>>>> In this thread we have already discussed the 2 last points below, but
> >> not the 1st.
> >>>>>
> >>>>> 1) EOL date
> >>>>> I don't think we should make a distinction with EOS - End Of Support
> -
> >> as Ron proposed
> >>>>> It seems to me this should be a community decision leading to the
> >> creation of a page like http://tomcat.apache.org/tomcat-55-eol.html
> >> linked from OFBiz download page
> >>>>> So we should decide of this date using a [PROPOSAL] thread that
> >> anybody can start. With a lazy consensus no further [VOTE] thread
> should be
> >> needed, but that could be also.
> >>>>>
> >>>>> 2) Backporting rule
> >>>>> Jacopo proposed
> >>>>>
> >>>>> A more formal rule would be:
> >>>>> a) commits to the trunk from Jira tickets of type Bugs can
> >> and*should*  be backported to all the active releases
> >>>>> b) commits to the trunk from Jira tickets of type different from Bugs
> >> need an explicit approval from the committers group before they can be
> >> backported to a specific active release
> >>>>>
> >>>>> I like it, because it's simple and clear
> >>>>>
> >>>>> a) I agree with the *should* (and not must) in 1st sentence. Because
> >> we can't reasonably force committers to backport all bug fixes.
> Sometimes
> >> there are too much conflicts, our volunteer time is limited. There is an
> >> exception though: all vulnerability fixes *must* be backported. It's
> >> obvious but better to state it.
> >>>>> _Note_: when Jacopo wrote that, I then answered: <<Yes, hopefully we
> >> (I mean the really concerned persons) will not have to enforce (ie do it
> >> ourselves) the "should" :/ >> Since this discussion we are doing a
> better
> >> job at this, it's heartening to see these results :)
> >>>>> b) The second rule is clear, a committer should not backport a non
> bug
> >> fix w/o the consent (lasy consensus) of a *reasonable number* of other
> >> committers.
> >>>>>
> >>>>> 3) Here Jacopo suggested to be as concise as possible,
> >>>>>
> >>>>> in my opinion we could improve (and make more evident) the
> information
> >> we already have in the download page where we already mention a
> tentative
> >> end of life; for example now we have:
> >>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04
> series)
> >>>>>
> >>>>> I agree, I think a page *like*
> >> http://tomcat.apache.org/tomcat-55-eol.html (simplified I guess) linked
> >> from the sentences like "(last release of the 12.04 series)" would help
> >> users to know better. Also I'd like that we clearly state on the
> download
> >> page, that, from our (a) "Backporting rule", *not all bug fixes are
> >> backported to all living release branches*. Our users have to live with
> it
> >> and engage the effort if they need a particular bug fix. With the help
> of
> >> the Jira generated releases logs this is now possible. I wrote also that
> >>>>> <<We should then explain to our releases users how they can use the
> >> Jira changes logs to check and amend what they use (with a link to wiki
> >> from the download page). >>
> >>>>> <<By comparing the trunk and releases change logs for instance>> and
> >> how to use https://svn.apache.org/viewvc/ then.
> >>>>>
> >>>>> So finally not much is missing :)
> >>>>>
> >>>>> Jacques
> >>>>>
> >>>>> Le 23/10/2014 15:08, Ron Wheeler a écrit :
> >>>>>>
> >>>>>> I think that many projects that are "important" and are hard to
> >> upgrade (user facing or customized at each installation) are fully
> >> supported until end of support and between EOS and EOL get fixes for
> bugs
> >> that have security implications where publishing the issue and fix to
> the
> >> current release or trunk will give hackers easy access  to data held in
> the
> >> old version or in some way open companies using that version to serious
> >> harm.
> >>>>>>
> >>>>>> It may be somewhat difficult to get people to fix older versions but
> >> there may be things that we could do to make this more likely.
> >>>>>> 1) Bugs can not be closed until it is fixed in all of the versions
> to
> >> which it must be applied (according to our EOS and EOL rules). It might
> be
> >> better to generate new issue that specifically addresses the patch to be
> >> applied rather than a full description of the symptoms of the original
> >> problem which is a main feature of the original report and make this new
> >> issue a dependency of the original.
> >>>>>> 2) Open a sub-project for the older releases with different
> >> committers who are interested in the older version and are not
> committing
> >> to the trunk.
> >>>>>> This might be a way for someone to get started in OFBiz programming.
> >>>>>> The activity in this sub-project would be a good way to judge the
> >> community's interest in maintaining the older release. One would expect
> >> that companies running the old version would be interested in supporting
> >> this sub-project even if they have no interest in the trunk.
> >>>>>>
> >>>>>> Ron
> >>>>>>
> >>>>>>
> >>>>>> On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
> >>>>>>> Inline
> >>>>>>>
> >>>>>>> Le 23/09/2014 09:26, Jacques Le Roux a écrit :
> >>>>>>>>
> >>>>>>>> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
> >>>>>>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <
> >> jacques.le.roux@les7arts.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> <<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.>>
> >>>>>>>>>>
> >>>>>>>>> A more formal rule would be:
> >>>>>>>>> * commits to the trunk from Jira tickets of type Bugs can and
> >> *should* be backported to all the active releases
> >>>>>>>> Yes, hopefully we (I mean the really concerned persons) will not
> >> have to enforce (ie do it ourselves) the "should" :/
> >>>>>>>>> * commits to the trunk from Jira tickets of type different from
> >> Bugs need an explicit approval from the committers group before they
> can be
> >> backported to a specific active release
> >>>>>>>> Yes it's already like that and those are only rare exceptions,
> >> right way for me
> >>>>>>>>>> <<I think we should make that clear and expose a way to users
> for
> >> them to more
> >>>>>>>>>> "easily" maintain the releases they use.>>
> >>>>>>>>> +1 see below
> >>>>>>>>>
> >>>>>>>>>> As suggested Ron we could also define our own or refer to
> >> http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
> >>>>>>>>> Rather than referring to an external site, in my opinion we could
> >> improve (and make more evident) the information we already have in the
> >> download page where we already mention a tentative end of life; for
> example
> >> now we have:
> >>>>>>>>>
> >>>>>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04
> >> series)
> >>>>>>>>>
> >>>>>>>>> But when we specify an end of life, we should also make clear a
> >> few things:
> >>>>>>>>> * this is a community goal, and the help from the community is
> >> required to meet the goal (i.e. it is not guaranteed)
> >>>>>>>> Yes that's an important point indeed. We begin to get traction
> with
> >> (mostly thanks to the bug crush effort so far) and hopefully it will
> >> continue :)
> >>>>>>>>> * the plan is flexible; for example, if a group of interested
> >> users will show up today telling us that they want to actively maintain
> the
> >> release branch 11.04 even if the scheduled end of life is passed, I
> would
> >> not object to it; the opposite is also true: if we experience low
> >> interest/support (from committers and non committers) in maintaining a
> >> given release branch we could vote to modify its end of life
> >>>>>>>> The point I'd really want to be highlighted/explained is we don't
> >> guarantee that old bugs fixed in trunk are backported. Let's face it, we
> >> can't guarantee that, we have not real means to enforce it.
> >>>>>>>
> >>>>>>> We have still no mention of that in the download page. I recently
> >> backported a number of bug fixes done in the last HWM bug crush in
> R12.04,
> >> but I (nobody I guess) can't guarantee we will always backport all bug
> >> fixes in living releases branches. I don't know how other TLP projects
> do,
> >> but it seems to me that to be correct/honest with our users we need to
> >> clarify that. We should even give a mean, or at least a way, to check
> that
> >> by themselves. By comparing the trunk and releases change logs for
> >> instance? I also suggested below
> >>>>>>> <<We should then explain to our releases users how they can use the
> >> Jira changes logs to check and amend what they use (maybe a link to wiki
> >> from download page to not clutter this main page).
> >>>>>>> I will think about what you wrote above and see how we can inform
> >> our our releases users (I mean a process to follow maybe even something
> >> more automated) >>
> >>>>>>>
> >>>>>>> Jacques
> >>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Now we need to think "technical" and automatize as possible with
> >> Jira
> >>>>>>>>> In my opinion it is possible to easily derive this from Jira,
> >> after the version configuration refactoring I did a few weeks ago
> (however
> >> the information will be more accurate with new releases).
> >>>>>>>>> The idea is to run a query on Jira with the following
> constraints:
> >>>>>>>>> project = OFBiz
> >>>>>>>>> type = Bug
> >>>>>>>>> status = not resolved
> >>>>>>>>> version *affected* = the release branch we are interested in
> (e.g.
> >> "release branch 12.04" OR the current latest release in the same branch
> >> (e.g. "Release 12.04.05")
> >>>>>>>>>
> >>>>>>>>> The result should be a list of bugs affecting the release branch
> >> and/or the latest release in that branch; these are the bugs that are
> known
> >> and outstanding.
> >>>>>>>>> For them we will need help from the community (committers and non
> >> committers) to fix the bugs or backport existing fixes.
> >>>>>>>>>
> >>>>>>>>> In the download page, we could add two links (to Jira) next to
> >> each available release:
> >>>>>>>>> 1) known bugs (links to the above report)
> >>>>>>>>> 2) release notes (link to the release notes available now)
> >>>>>>>>>
> >>>>>>>>> One technicality is the following: when we release a new release
> >> from the branch (e.g. 12.04.06), if there are open tickets with "version
> >> affected" set to the current version (e.g. 12.04.05) then we will have
> to
> >> bulk update all of them by adding also the new version (e.g. add
> "12.04.06"
> >> to affected version).
> >>>>>>>>
> >>>>>>>> This will need a strict observance from committers about versions
> >> to fix and fixed. I believe it's indeed the right way, anyway we have no
> >> others/betters (I mean offered by Jira) .
> >>>>>>>>
> >>>>>>>> We should then explain to our releases users how they can use the
> >> Jira changes logs to check and amend what they use (maybe a link to wiki
> >> from download page to not clutter this main page).
> >>>>>>>> I will think about what you wrote above and see how we can inform
> >> our our releases users (I mean a process to follow maybe even something
> >> more automated)
> >>>>>>>>
> >>>>>>>> Jacques
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> What I have read so far from Jacopo seems a good start to me
> >>>>>>>>> Thank you for confirming that we are on the same page. This is
> >> actually part of the plan I had in mind to maintain better release
> >> information when I started the version refactoring in Jira, and this
> >> conversation is helping to refine some points.
> >>>>>>>>>
> >>>>>>>>> Jacopo
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>

Re: Release Strategy and Branch Support

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

The community as a whole supports OFBiz and its releases.

Jacopo

On Mar 23, 2015, at 3:38 PM, Ron Wheeler <rw...@artifact-software.com> wrote:

> Doe this have an impact on how the OFBiz project defines "supported release". - We support a release but only the parts that we care about!
> 
> Each contributor gets to decide what release they support.
> Do we need to publish a list of committers for each release or is it by module or feature?
> 
> Ron
> 
> On 23/03/2015 5:07 AM, Jacopo Cappellato wrote:
>> +1
>> 
>> Especially if the patch is for a bug that has been already committed to the trunk and the contributor has prepared it for a specific branch and properly tested it.
>> 
>> Jacopo
>> 
>> On Mar 23, 2015, at 9:59 AM, Pierre Smits <pi...@gmail.com> wrote:
>> 
>>> As soon as a  bug fix ticket pertaining to a specific release branch is
>>> created in JIRA, the community should put its best effort in to get it
>>> resolved. When a that ticket has a patch, the committers should treat it
>>> with a higher priority.
>>> 
>>> That doesn't mean that the project is obliged to have it in next release.
>>> It means that the project should do its best to have it in the next best
>>> release. There are constraints to be considered.
>>> 
>>> Best regards,
>>> 
>>> Pierre Smits
>>> 
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>> 
>>> On Mon, Mar 23, 2015 at 9:46 AM, Jacopo Cappellato <
>>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>> 
>>>> I don't see a specific problem here; I mean, this is a community driven
>>>> project and all tasks will need a contribution from the community in order
>>>> to be implemented, including backports.
>>>> If something is not backported to release X.Y and someone is interested in
>>>> it then the person could implement the backport and test it and contribute
>>>> it to the community with a Jira ticket.
>>>> 
>>>> Jacopo
>>>> 
>>>> On Mar 23, 2015, at 8:31 AM, Jacques Le Roux <ja...@les7arts.com>
>>>> wrote:
>>>> 
>>>>> Ha just a small change I wrote that we should state in download page that
>>>>> *not all bug fixes are backported to all living release branches*
>>>>> Should be
>>>>> *despite our best effort, not all bug fixes are backported to all living
>>>> release branches* ;)
>>>>> Jacques
>>>>> 
>>>>> Le 22/03/2015 14:49, Ron Wheeler a écrit :
>>>>>> Great discussion.
>>>>>> 
>>>>>> IMHO, bug fixes are different from enhancements. A fix is a gift to the
>>>> community (specially if you are fixing something that someone else broke).
>>>> Enhancement are usually done to add something that a small group wants and
>>>> they have to take more responsibility to maintain it and have more of a
>>>> role in deciding if it is to be backported.
>>>>>> If someone takes the time to fix something, I am not sure that they are
>>>> also responsible for doing all the backports (as called for in the "no good
>>>> deed goes unpunished" clause of the programmers creed.)
>>>>>> If the consensus is that a bug fix must be backported, it is not just
>>>> the responsibility of the person who fixes it in the trunk (or wherever),
>>>> it is a community commitment to the integrity of the product.
>>>>>> It becomes a blocker to the next release of that branch.
>>>>>> 
>>>>>> In an ERP, there needs to be a bit wider view of a "security patch".
>>>>>> If you have a bug that will result in a user company shipping a product
>>>> without getting paid or manufacturing items to fill a non-existant order
>>>> backlog, perhaps that qualifies as a "security release".
>>>>>> 
>>>>>> As long as each decision is made and communicated in a transparent way,
>>>> I think that most people will be able to live with the process.
>>>>>> Ron
>>>>>> 
>>>>>> On 22/03/2015 5:48 AM, Jacques Le Roux wrote:
>>>>>>> I was re-reading this thread because I think it's important and we
>>>> need to clarify 3 things
>>>>>>> 1) how to decide when a branch is no longer supported (vs is alive)
>>>>>>> 2) what are the backporting rule
>>>>>>> 3) what to show on our OFBiz download page
>>>>>>> 
>>>>>>> In this thread we have already discussed the 2 last points below, but
>>>> not the 1st.
>>>>>>> 1) EOL date
>>>>>>> I don't think we should make a distinction with EOS - End Of Support -
>>>> as Ron proposed
>>>>>>> It seems to me this should be a community decision leading to the
>>>> creation of a page like http://tomcat.apache.org/tomcat-55-eol.html
>>>> linked from OFBiz download page
>>>>>>> So we should decide of this date using a [PROPOSAL] thread that
>>>> anybody can start. With a lazy consensus no further [VOTE] thread should be
>>>> needed, but that could be also.
>>>>>>> 2) Backporting rule
>>>>>>> Jacopo proposed
>>>>>>> 
>>>>>>> A more formal rule would be:
>>>>>>> a) commits to the trunk from Jira tickets of type Bugs can
>>>> and*should*  be backported to all the active releases
>>>>>>> b) commits to the trunk from Jira tickets of type different from Bugs
>>>> need an explicit approval from the committers group before they can be
>>>> backported to a specific active release
>>>>>>> I like it, because it's simple and clear
>>>>>>> 
>>>>>>> a) I agree with the *should* (and not must) in 1st sentence. Because
>>>> we can't reasonably force committers to backport all bug fixes. Sometimes
>>>> there are too much conflicts, our volunteer time is limited. There is an
>>>> exception though: all vulnerability fixes *must* be backported. It's
>>>> obvious but better to state it.
>>>>>>> _Note_: when Jacopo wrote that, I then answered: <<Yes, hopefully we
>>>> (I mean the really concerned persons) will not have to enforce (ie do it
>>>> ourselves) the "should" :/ >> Since this discussion we are doing a better
>>>> job at this, it's heartening to see these results :)
>>>>>>> b) The second rule is clear, a committer should not backport a non bug
>>>> fix w/o the consent (lasy consensus) of a *reasonable number* of other
>>>> committers.
>>>>>>> 3) Here Jacopo suggested to be as concise as possible,
>>>>>>> 
>>>>>>> in my opinion we could improve (and make more evident) the information
>>>> we already have in the download page where we already mention a tentative
>>>> end of life; for example now we have:
>>>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>>>>> 
>>>>>>> I agree, I think a page *like*
>>>> http://tomcat.apache.org/tomcat-55-eol.html (simplified I guess) linked
>>>> from the sentences like "(last release of the 12.04 series)" would help
>>>> users to know better. Also I'd like that we clearly state on the download
>>>> page, that, from our (a) "Backporting rule", *not all bug fixes are
>>>> backported to all living release branches*. Our users have to live with it
>>>> and engage the effort if they need a particular bug fix. With the help of
>>>> the Jira generated releases logs this is now possible. I wrote also that
>>>>>>> <<We should then explain to our releases users how they can use the
>>>> Jira changes logs to check and amend what they use (with a link to wiki
>>>> from the download page). >>
>>>>>>> <<By comparing the trunk and releases change logs for instance>> and
>>>> how to use https://svn.apache.org/viewvc/ then.
>>>>>>> So finally not much is missing :)
>>>>>>> 
>>>>>>> Jacques
>>>>>>> 
>>>>>>> Le 23/10/2014 15:08, Ron Wheeler a écrit :
>>>>>>>> I think that many projects that are "important" and are hard to
>>>> upgrade (user facing or customized at each installation) are fully
>>>> supported until end of support and between EOS and EOL get fixes for bugs
>>>> that have security implications where publishing the issue and fix to the
>>>> current release or trunk will give hackers easy access  to data held in the
>>>> old version or in some way open companies using that version to serious
>>>> harm.
>>>>>>>> It may be somewhat difficult to get people to fix older versions but
>>>> there may be things that we could do to make this more likely.
>>>>>>>> 1) Bugs can not be closed until it is fixed in all of the versions to
>>>> which it must be applied (according to our EOS and EOL rules). It might be
>>>> better to generate new issue that specifically addresses the patch to be
>>>> applied rather than a full description of the symptoms of the original
>>>> problem which is a main feature of the original report and make this new
>>>> issue a dependency of the original.
>>>>>>>> 2) Open a sub-project for the older releases with different
>>>> committers who are interested in the older version and are not committing
>>>> to the trunk.
>>>>>>>> This might be a way for someone to get started in OFBiz programming.
>>>>>>>> The activity in this sub-project would be a good way to judge the
>>>> community's interest in maintaining the older release. One would expect
>>>> that companies running the old version would be interested in supporting
>>>> this sub-project even if they have no interest in the trunk.
>>>>>>>> Ron
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
>>>>>>>>> Inline
>>>>>>>>> 
>>>>>>>>> Le 23/09/2014 09:26, Jacques Le Roux a écrit :
>>>>>>>>>> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
>>>>>>>>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>>> <<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.>>
>>>>>>>>>>> A more formal rule would be:
>>>>>>>>>>> * commits to the trunk from Jira tickets of type Bugs can and
>>>> *should* be backported to all the active releases
>>>>>>>>>> Yes, hopefully we (I mean the really concerned persons) will not
>>>> have to enforce (ie do it ourselves) the "should" :/
>>>>>>>>>>> * commits to the trunk from Jira tickets of type different from
>>>> Bugs need an explicit approval from the committers group before they can be
>>>> backported to a specific active release
>>>>>>>>>> Yes it's already like that and those are only rare exceptions,
>>>> right way for me
>>>>>>>>>>>> <<I think we should make that clear and expose a way to users for
>>>> them to more
>>>>>>>>>>>> "easily" maintain the releases they use.>>
>>>>>>>>>>> +1 see below
>>>>>>>>>>> 
>>>>>>>>>>>> As suggested Ron we could also define our own or refer to
>>>> http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>>>>>>>>>> Rather than referring to an external site, in my opinion we could
>>>> improve (and make more evident) the information we already have in the
>>>> download page where we already mention a tentative end of life; for example
>>>> now we have:
>>>>>>>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04
>>>> series)
>>>>>>>>>>> But when we specify an end of life, we should also make clear a
>>>> few things:
>>>>>>>>>>> * this is a community goal, and the help from the community is
>>>> required to meet the goal (i.e. it is not guaranteed)
>>>>>>>>>> Yes that's an important point indeed. We begin to get traction with
>>>> (mostly thanks to the bug crush effort so far) and hopefully it will
>>>> continue :)
>>>>>>>>>>> * the plan is flexible; for example, if a group of interested
>>>> users will show up today telling us that they want to actively maintain the
>>>> release branch 11.04 even if the scheduled end of life is passed, I would
>>>> not object to it; the opposite is also true: if we experience low
>>>> interest/support (from committers and non committers) in maintaining a
>>>> given release branch we could vote to modify its end of life
>>>>>>>>>> The point I'd really want to be highlighted/explained is we don't
>>>> guarantee that old bugs fixed in trunk are backported. Let's face it, we
>>>> can't guarantee that, we have not real means to enforce it.
>>>>>>>>> We have still no mention of that in the download page. I recently
>>>> backported a number of bug fixes done in the last HWM bug crush in R12.04,
>>>> but I (nobody I guess) can't guarantee we will always backport all bug
>>>> fixes in living releases branches. I don't know how other TLP projects do,
>>>> but it seems to me that to be correct/honest with our users we need to
>>>> clarify that. We should even give a mean, or at least a way, to check that
>>>> by themselves. By comparing the trunk and releases change logs for
>>>> instance? I also suggested below
>>>>>>>>> <<We should then explain to our releases users how they can use the
>>>> Jira changes logs to check and amend what they use (maybe a link to wiki
>>>> from download page to not clutter this main page).
>>>>>>>>> I will think about what you wrote above and see how we can inform
>>>> our our releases users (I mean a process to follow maybe even something
>>>> more automated) >>
>>>>>>>>> Jacques
>>>>>>>>> 
>>>>>>>>>>>> Now we need to think "technical" and automatize as possible with
>>>> Jira
>>>>>>>>>>> In my opinion it is possible to easily derive this from Jira,
>>>> after the version configuration refactoring I did a few weeks ago (however
>>>> the information will be more accurate with new releases).
>>>>>>>>>>> The idea is to run a query on Jira with the following constraints:
>>>>>>>>>>> project = OFBiz
>>>>>>>>>>> type = Bug
>>>>>>>>>>> status = not resolved
>>>>>>>>>>> version *affected* = the release branch we are interested in (e.g.
>>>> "release branch 12.04" OR the current latest release in the same branch
>>>> (e.g. "Release 12.04.05")
>>>>>>>>>>> The result should be a list of bugs affecting the release branch
>>>> and/or the latest release in that branch; these are the bugs that are known
>>>> and outstanding.
>>>>>>>>>>> For them we will need help from the community (committers and non
>>>> committers) to fix the bugs or backport existing fixes.
>>>>>>>>>>> In the download page, we could add two links (to Jira) next to
>>>> each available release:
>>>>>>>>>>> 1) known bugs (links to the above report)
>>>>>>>>>>> 2) release notes (link to the release notes available now)
>>>>>>>>>>> 
>>>>>>>>>>> One technicality is the following: when we release a new release
>>>> from the branch (e.g. 12.04.06), if there are open tickets with "version
>>>> affected" set to the current version (e.g. 12.04.05) then we will have to
>>>> bulk update all of them by adding also the new version (e.g. add "12.04.06"
>>>> to affected version).
>>>>>>>>>> This will need a strict observance from committers about versions
>>>> to fix and fixed. I believe it's indeed the right way, anyway we have no
>>>> others/betters (I mean offered by Jira) .
>>>>>>>>>> We should then explain to our releases users how they can use the
>>>> Jira changes logs to check and amend what they use (maybe a link to wiki
>>>> from download page to not clutter this main page).
>>>>>>>>>> I will think about what you wrote above and see how we can inform
>>>> our our releases users (I mean a process to follow maybe even something
>>>> more automated)
>>>>>>>>>> Jacques
>>>>>>>>>> 
>>>>>>>>>>>> What I have read so far from Jacopo seems a good start to me
>>>>>>>>>>> Thank you for confirming that we are on the same page. This is
>>>> actually part of the plan I had in mind to maintain better release
>>>> information when I started the version refactoring in Jira, and this
>>>> conversation is helping to refine some points.
>>>>>>>>>>> Jacopo
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 

Re: Release Strategy and Branch Support

[Pierre Smits <pi...@gmail.com>]

No, such is not needed. Through consensus regarding code change the project
implicitly state what is in releases. Releases are supported.

Of course, each contributor can decide for himself what he wants to
support. An individual contributor is not the community, hence not the
project.

Best regards,

Pierre Smits

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

On Mon, Mar 23, 2015 at 3:38 PM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:

> Doe this have an impact on how the OFBiz project defines "supported
> release". - We support a release but only the parts that we care about!
>
> Each contributor gets to decide what release they support.
> Do we need to publish a list of committers for each release or is it by
> module or feature?
>
> Ron
>
>
> On 23/03/2015 5:07 AM, Jacopo Cappellato wrote:
>
>> +1
>>
>> Especially if the patch is for a bug that has been already committed to
>> the trunk and the contributor has prepared it for a specific branch and
>> properly tested it.
>>
>> Jacopo
>>
>> On Mar 23, 2015, at 9:59 AM, Pierre Smits <pi...@gmail.com> wrote:
>>
>>  As soon as a  bug fix ticket pertaining to a specific release branch is
>>> created in JIRA, the community should put its best effort in to get it
>>> resolved. When a that ticket has a patch, the committers should treat it
>>> with a higher priority.
>>>
>>> That doesn't mean that the project is obliged to have it in next release.
>>> It means that the project should do its best to have it in the next best
>>> release. There are constraints to be considered.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Mon, Mar 23, 2015 at 9:46 AM, Jacopo Cappellato <
>>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>>
>>>  I don't see a specific problem here; I mean, this is a community driven
>>>> project and all tasks will need a contribution from the community in
>>>> order
>>>> to be implemented, including backports.
>>>> If something is not backported to release X.Y and someone is interested
>>>> in
>>>> it then the person could implement the backport and test it and
>>>> contribute
>>>> it to the community with a Jira ticket.
>>>>
>>>> Jacopo
>>>>
>>>> On Mar 23, 2015, at 8:31 AM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com>
>>>> wrote:
>>>>
>>>>  Ha just a small change I wrote that we should state in download page
>>>>> that
>>>>> *not all bug fixes are backported to all living release branches*
>>>>> Should be
>>>>> *despite our best effort, not all bug fixes are backported to all
>>>>> living
>>>>>
>>>> release branches* ;)
>>>>
>>>>> Jacques
>>>>>
>>>>> Le 22/03/2015 14:49, Ron Wheeler a écrit :
>>>>>
>>>>>> Great discussion.
>>>>>>
>>>>>> IMHO, bug fixes are different from enhancements. A fix is a gift to
>>>>>> the
>>>>>>
>>>>> community (specially if you are fixing something that someone else
>>>> broke).
>>>> Enhancement are usually done to add something that a small group wants
>>>> and
>>>> they have to take more responsibility to maintain it and have more of a
>>>> role in deciding if it is to be backported.
>>>>
>>>>> If someone takes the time to fix something, I am not sure that they are
>>>>>>
>>>>> also responsible for doing all the backports (as called for in the "no
>>>> good
>>>> deed goes unpunished" clause of the programmers creed.)
>>>>
>>>>> If the consensus is that a bug fix must be backported, it is not just
>>>>>>
>>>>> the responsibility of the person who fixes it in the trunk (or
>>>> wherever),
>>>> it is a community commitment to the integrity of the product.
>>>>
>>>>> It becomes a blocker to the next release of that branch.
>>>>>>
>>>>>> In an ERP, there needs to be a bit wider view of a "security patch".
>>>>>> If you have a bug that will result in a user company shipping a
>>>>>> product
>>>>>>
>>>>> without getting paid or manufacturing items to fill a non-existant
>>>> order
>>>> backlog, perhaps that qualifies as a "security release".
>>>>
>>>>>
>>>>>> As long as each decision is made and communicated in a transparent
>>>>>> way,
>>>>>>
>>>>> I think that most people will be able to live with the process.
>>>>
>>>>> Ron
>>>>>>
>>>>>> On 22/03/2015 5:48 AM, Jacques Le Roux wrote:
>>>>>>
>>>>>>> I was re-reading this thread because I think it's important and we
>>>>>>>
>>>>>> need to clarify 3 things
>>>>
>>>>> 1) how to decide when a branch is no longer supported (vs is alive)
>>>>>>> 2) what are the backporting rule
>>>>>>> 3) what to show on our OFBiz download page
>>>>>>>
>>>>>>> In this thread we have already discussed the 2 last points below, but
>>>>>>>
>>>>>> not the 1st.
>>>>
>>>>> 1) EOL date
>>>>>>> I don't think we should make a distinction with EOS - End Of Support
>>>>>>> -
>>>>>>>
>>>>>> as Ron proposed
>>>>
>>>>> It seems to me this should be a community decision leading to the
>>>>>>>
>>>>>> creation of a page like http://tomcat.apache.org/tomcat-55-eol.html
>>>> linked from OFBiz download page
>>>>
>>>>> So we should decide of this date using a [PROPOSAL] thread that
>>>>>>>
>>>>>> anybody can start. With a lazy consensus no further [VOTE] thread
>>>> should be
>>>> needed, but that could be also.
>>>>
>>>>> 2) Backporting rule
>>>>>>> Jacopo proposed
>>>>>>>
>>>>>>> A more formal rule would be:
>>>>>>> a) commits to the trunk from Jira tickets of type Bugs can
>>>>>>>
>>>>>> and*should*  be backported to all the active releases
>>>>
>>>>> b) commits to the trunk from Jira tickets of type different from Bugs
>>>>>>>
>>>>>> need an explicit approval from the committers group before they can be
>>>> backported to a specific active release
>>>>
>>>>> I like it, because it's simple and clear
>>>>>>>
>>>>>>> a) I agree with the *should* (and not must) in 1st sentence. Because
>>>>>>>
>>>>>> we can't reasonably force committers to backport all bug fixes.
>>>> Sometimes
>>>> there are too much conflicts, our volunteer time is limited. There is an
>>>> exception though: all vulnerability fixes *must* be backported. It's
>>>> obvious but better to state it.
>>>>
>>>>> _Note_: when Jacopo wrote that, I then answered: <<Yes, hopefully we
>>>>>>>
>>>>>> (I mean the really concerned persons) will not have to enforce (ie do
>>>> it
>>>> ourselves) the "should" :/ >> Since this discussion we are doing a
>>>> better
>>>> job at this, it's heartening to see these results :)
>>>>
>>>>> b) The second rule is clear, a committer should not backport a non bug
>>>>>>>
>>>>>> fix w/o the consent (lasy consensus) of a *reasonable number* of other
>>>> committers.
>>>>
>>>>> 3) Here Jacopo suggested to be as concise as possible,
>>>>>>>
>>>>>>> in my opinion we could improve (and make more evident) the
>>>>>>> information
>>>>>>>
>>>>>> we already have in the download page where we already mention a
>>>> tentative
>>>> end of life; for example now we have:
>>>>
>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>>>>>
>>>>>>> I agree, I think a page *like*
>>>>>>>
>>>>>> http://tomcat.apache.org/tomcat-55-eol.html (simplified I guess)
>>>> linked
>>>> from the sentences like "(last release of the 12.04 series)" would help
>>>> users to know better. Also I'd like that we clearly state on the
>>>> download
>>>> page, that, from our (a) "Backporting rule", *not all bug fixes are
>>>> backported to all living release branches*. Our users have to live with
>>>> it
>>>> and engage the effort if they need a particular bug fix. With the help
>>>> of
>>>> the Jira generated releases logs this is now possible. I wrote also that
>>>>
>>>>> <<We should then explain to our releases users how they can use the
>>>>>>>
>>>>>> Jira changes logs to check and amend what they use (with a link to
>>>> wiki
>>>> from the download page). >>
>>>>
>>>>> <<By comparing the trunk and releases change logs for instance>> and
>>>>>>>
>>>>>> how to use https://svn.apache.org/viewvc/ then.
>>>>
>>>>> So finally not much is missing :)
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> Le 23/10/2014 15:08, Ron Wheeler a écrit :
>>>>>>>
>>>>>>>> I think that many projects that are "important" and are hard to
>>>>>>>>
>>>>>>> upgrade (user facing or customized at each installation) are fully
>>>> supported until end of support and between EOS and EOL get fixes for
>>>> bugs
>>>> that have security implications where publishing the issue and fix to
>>>> the
>>>> current release or trunk will give hackers easy access  to data held in
>>>> the
>>>> old version or in some way open companies using that version to serious
>>>> harm.
>>>>
>>>>> It may be somewhat difficult to get people to fix older versions but
>>>>>>>>
>>>>>>> there may be things that we could do to make this more likely.
>>>>
>>>>> 1) Bugs can not be closed until it is fixed in all of the versions to
>>>>>>>>
>>>>>>> which it must be applied (according to our EOS and EOL rules). It
>>>> might be
>>>> better to generate new issue that specifically addresses the patch to be
>>>> applied rather than a full description of the symptoms of the original
>>>> problem which is a main feature of the original report and make this new
>>>> issue a dependency of the original.
>>>>
>>>>> 2) Open a sub-project for the older releases with different
>>>>>>>>
>>>>>>> committers who are interested in the older version and are not
>>>> committing
>>>> to the trunk.
>>>>
>>>>> This might be a way for someone to get started in OFBiz programming.
>>>>>>>> The activity in this sub-project would be a good way to judge the
>>>>>>>>
>>>>>>> community's interest in maintaining the older release. One would
>>>> expect
>>>> that companies running the old version would be interested in supporting
>>>> this sub-project even if they have no interest in the trunk.
>>>>
>>>>> Ron
>>>>>>>>
>>>>>>>>
>>>>>>>> On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
>>>>>>>>
>>>>>>>>> Inline
>>>>>>>>>
>>>>>>>>> Le 23/09/2014 09:26, Jacques Le Roux a écrit :
>>>>>>>>>
>>>>>>>>>> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
>>>>>>>>>>
>>>>>>>>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <
>>>>>>>>>>>
>>>>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>>> <<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.>>
>>>>
>>>>> A more formal rule would be:
>>>>>>>>>>> * commits to the trunk from Jira tickets of type Bugs can and
>>>>>>>>>>>
>>>>>>>>>> *should* be backported to all the active releases
>>>>
>>>>> Yes, hopefully we (I mean the really concerned persons) will not
>>>>>>>>>>
>>>>>>>>> have to enforce (ie do it ourselves) the "should" :/
>>>>
>>>>> * commits to the trunk from Jira tickets of type different from
>>>>>>>>>>>
>>>>>>>>>> Bugs need an explicit approval from the committers group before
>>>> they can be
>>>> backported to a specific active release
>>>>
>>>>> Yes it's already like that and those are only rare exceptions,
>>>>>>>>>>
>>>>>>>>> right way for me
>>>>
>>>>> <<I think we should make that clear and expose a way to users for
>>>>>>>>>>>>
>>>>>>>>>>> them to more
>>>>
>>>>> "easily" maintain the releases they use.>>
>>>>>>>>>>>>
>>>>>>>>>>> +1 see below
>>>>>>>>>>>
>>>>>>>>>>>  As suggested Ron we could also define our own or refer to
>>>>>>>>>>>>
>>>>>>>>>>> http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>>>
>>>>> Rather than referring to an external site, in my opinion we could
>>>>>>>>>>>
>>>>>>>>>> improve (and make more evident) the information we already have
>>>> in the
>>>> download page where we already mention a tentative end of life; for
>>>> example
>>>> now we have:
>>>>
>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04
>>>>>>>>>>>
>>>>>>>>>> series)
>>>>
>>>>> But when we specify an end of life, we should also make clear a
>>>>>>>>>>>
>>>>>>>>>> few things:
>>>>
>>>>> * this is a community goal, and the help from the community is
>>>>>>>>>>>
>>>>>>>>>> required to meet the goal (i.e. it is not guaranteed)
>>>>
>>>>> Yes that's an important point indeed. We begin to get traction with
>>>>>>>>>>
>>>>>>>>> (mostly thanks to the bug crush effort so far) and hopefully it
>>>> will
>>>> continue :)
>>>>
>>>>> * the plan is flexible; for example, if a group of interested
>>>>>>>>>>>
>>>>>>>>>> users will show up today telling us that they want to actively
>>>> maintain the
>>>> release branch 11.04 even if the scheduled end of life is passed, I
>>>> would
>>>> not object to it; the opposite is also true: if we experience low
>>>> interest/support (from committers and non committers) in maintaining a
>>>> given release branch we could vote to modify its end of life
>>>>
>>>>> The point I'd really want to be highlighted/explained is we don't
>>>>>>>>>>
>>>>>>>>> guarantee that old bugs fixed in trunk are backported. Let's face
>>>> it, we
>>>> can't guarantee that, we have not real means to enforce it.
>>>>
>>>>> We have still no mention of that in the download page. I recently
>>>>>>>>>
>>>>>>>> backported a number of bug fixes done in the last HWM bug crush in
>>>> R12.04,
>>>> but I (nobody I guess) can't guarantee we will always backport all bug
>>>> fixes in living releases branches. I don't know how other TLP projects
>>>> do,
>>>> but it seems to me that to be correct/honest with our users we need to
>>>> clarify that. We should even give a mean, or at least a way, to check
>>>> that
>>>> by themselves. By comparing the trunk and releases change logs for
>>>> instance? I also suggested below
>>>>
>>>>> <<We should then explain to our releases users how they can use the
>>>>>>>>>
>>>>>>>> Jira changes logs to check and amend what they use (maybe a link to
>>>> wiki
>>>> from download page to not clutter this main page).
>>>>
>>>>> I will think about what you wrote above and see how we can inform
>>>>>>>>>
>>>>>>>> our our releases users (I mean a process to follow maybe even
>>>> something
>>>> more automated) >>
>>>>
>>>>> Jacques
>>>>>>>>>
>>>>>>>>>  Now we need to think "technical" and automatize as possible with
>>>>>>>>>>>>
>>>>>>>>>>> Jira
>>>>
>>>>> In my opinion it is possible to easily derive this from Jira,
>>>>>>>>>>>
>>>>>>>>>> after the version configuration refactoring I did a few weeks ago
>>>> (however
>>>> the information will be more accurate with new releases).
>>>>
>>>>> The idea is to run a query on Jira with the following constraints:
>>>>>>>>>>> project = OFBiz
>>>>>>>>>>> type = Bug
>>>>>>>>>>> status = not resolved
>>>>>>>>>>> version *affected* = the release branch we are interested in
>>>>>>>>>>> (e.g.
>>>>>>>>>>>
>>>>>>>>>> "release branch 12.04" OR the current latest release in the same
>>>> branch
>>>> (e.g. "Release 12.04.05")
>>>>
>>>>> The result should be a list of bugs affecting the release branch
>>>>>>>>>>>
>>>>>>>>>> and/or the latest release in that branch; these are the bugs that
>>>> are known
>>>> and outstanding.
>>>>
>>>>> For them we will need help from the community (committers and non
>>>>>>>>>>>
>>>>>>>>>> committers) to fix the bugs or backport existing fixes.
>>>>
>>>>> In the download page, we could add two links (to Jira) next to
>>>>>>>>>>>
>>>>>>>>>> each available release:
>>>>
>>>>> 1) known bugs (links to the above report)
>>>>>>>>>>> 2) release notes (link to the release notes available now)
>>>>>>>>>>>
>>>>>>>>>>> One technicality is the following: when we release a new release
>>>>>>>>>>>
>>>>>>>>>> from the branch (e.g. 12.04.06), if there are open tickets with
>>>> "version
>>>> affected" set to the current version (e.g. 12.04.05) then we will have
>>>> to
>>>> bulk update all of them by adding also the new version (e.g. add
>>>> "12.04.06"
>>>> to affected version).
>>>>
>>>>> This will need a strict observance from committers about versions
>>>>>>>>>>
>>>>>>>>> to fix and fixed. I believe it's indeed the right way, anyway we
>>>> have no
>>>> others/betters (I mean offered by Jira) .
>>>>
>>>>> We should then explain to our releases users how they can use the
>>>>>>>>>>
>>>>>>>>> Jira changes logs to check and amend what they use (maybe a link
>>>> to wiki
>>>> from download page to not clutter this main page).
>>>>
>>>>> I will think about what you wrote above and see how we can inform
>>>>>>>>>>
>>>>>>>>> our our releases users (I mean a process to follow maybe even
>>>> something
>>>> more automated)
>>>>
>>>>> Jacques
>>>>>>>>>>
>>>>>>>>>>  What I have read so far from Jacopo seems a good start to me
>>>>>>>>>>>>
>>>>>>>>>>> Thank you for confirming that we are on the same page. This is
>>>>>>>>>>>
>>>>>>>>>> actually part of the plan I had in mind to maintain better release
>>>> information when I started the version refactoring in Jira, and this
>>>> conversation is helping to refine some points.
>>>>
>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>

Re: Release Strategy and Branch Support

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

Doe this have an impact on how the OFBiz project defines "supported 
release". - We support a release but only the parts that we care about!

Each contributor gets to decide what release they support.
Do we need to publish a list of committers for each release or is it by 
module or feature?

Ron

On 23/03/2015 5:07 AM, Jacopo Cappellato wrote:
> +1
>
> Especially if the patch is for a bug that has been already committed to the trunk and the contributor has prepared it for a specific branch and properly tested it.
>
> Jacopo
>
> On Mar 23, 2015, at 9:59 AM, Pierre Smits <pi...@gmail.com> wrote:
>
>> As soon as a  bug fix ticket pertaining to a specific release branch is
>> created in JIRA, the community should put its best effort in to get it
>> resolved. When a that ticket has a patch, the committers should treat it
>> with a higher priority.
>>
>> That doesn't mean that the project is obliged to have it in next release.
>> It means that the project should do its best to have it in the next best
>> release. There are constraints to be considered.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Mon, Mar 23, 2015 at 9:46 AM, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxsystems.com> wrote:
>>
>>> I don't see a specific problem here; I mean, this is a community driven
>>> project and all tasks will need a contribution from the community in order
>>> to be implemented, including backports.
>>> If something is not backported to release X.Y and someone is interested in
>>> it then the person could implement the backport and test it and contribute
>>> it to the community with a Jira ticket.
>>>
>>> Jacopo
>>>
>>> On Mar 23, 2015, at 8:31 AM, Jacques Le Roux <ja...@les7arts.com>
>>> wrote:
>>>
>>>> Ha just a small change I wrote that we should state in download page that
>>>> *not all bug fixes are backported to all living release branches*
>>>> Should be
>>>> *despite our best effort, not all bug fixes are backported to all living
>>> release branches* ;)
>>>> Jacques
>>>>
>>>> Le 22/03/2015 14:49, Ron Wheeler a écrit :
>>>>> Great discussion.
>>>>>
>>>>> IMHO, bug fixes are different from enhancements. A fix is a gift to the
>>> community (specially if you are fixing something that someone else broke).
>>> Enhancement are usually done to add something that a small group wants and
>>> they have to take more responsibility to maintain it and have more of a
>>> role in deciding if it is to be backported.
>>>>> If someone takes the time to fix something, I am not sure that they are
>>> also responsible for doing all the backports (as called for in the "no good
>>> deed goes unpunished" clause of the programmers creed.)
>>>>> If the consensus is that a bug fix must be backported, it is not just
>>> the responsibility of the person who fixes it in the trunk (or wherever),
>>> it is a community commitment to the integrity of the product.
>>>>> It becomes a blocker to the next release of that branch.
>>>>>
>>>>> In an ERP, there needs to be a bit wider view of a "security patch".
>>>>> If you have a bug that will result in a user company shipping a product
>>> without getting paid or manufacturing items to fill a non-existant order
>>> backlog, perhaps that qualifies as a "security release".
>>>>>
>>>>> As long as each decision is made and communicated in a transparent way,
>>> I think that most people will be able to live with the process.
>>>>> Ron
>>>>>
>>>>> On 22/03/2015 5:48 AM, Jacques Le Roux wrote:
>>>>>> I was re-reading this thread because I think it's important and we
>>> need to clarify 3 things
>>>>>> 1) how to decide when a branch is no longer supported (vs is alive)
>>>>>> 2) what are the backporting rule
>>>>>> 3) what to show on our OFBiz download page
>>>>>>
>>>>>> In this thread we have already discussed the 2 last points below, but
>>> not the 1st.
>>>>>> 1) EOL date
>>>>>> I don't think we should make a distinction with EOS - End Of Support -
>>> as Ron proposed
>>>>>> It seems to me this should be a community decision leading to the
>>> creation of a page like http://tomcat.apache.org/tomcat-55-eol.html
>>> linked from OFBiz download page
>>>>>> So we should decide of this date using a [PROPOSAL] thread that
>>> anybody can start. With a lazy consensus no further [VOTE] thread should be
>>> needed, but that could be also.
>>>>>> 2) Backporting rule
>>>>>> Jacopo proposed
>>>>>>
>>>>>> A more formal rule would be:
>>>>>> a) commits to the trunk from Jira tickets of type Bugs can
>>> and*should*  be backported to all the active releases
>>>>>> b) commits to the trunk from Jira tickets of type different from Bugs
>>> need an explicit approval from the committers group before they can be
>>> backported to a specific active release
>>>>>> I like it, because it's simple and clear
>>>>>>
>>>>>> a) I agree with the *should* (and not must) in 1st sentence. Because
>>> we can't reasonably force committers to backport all bug fixes. Sometimes
>>> there are too much conflicts, our volunteer time is limited. There is an
>>> exception though: all vulnerability fixes *must* be backported. It's
>>> obvious but better to state it.
>>>>>> _Note_: when Jacopo wrote that, I then answered: <<Yes, hopefully we
>>> (I mean the really concerned persons) will not have to enforce (ie do it
>>> ourselves) the "should" :/ >> Since this discussion we are doing a better
>>> job at this, it's heartening to see these results :)
>>>>>> b) The second rule is clear, a committer should not backport a non bug
>>> fix w/o the consent (lasy consensus) of a *reasonable number* of other
>>> committers.
>>>>>> 3) Here Jacopo suggested to be as concise as possible,
>>>>>>
>>>>>> in my opinion we could improve (and make more evident) the information
>>> we already have in the download page where we already mention a tentative
>>> end of life; for example now we have:
>>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>>>>
>>>>>> I agree, I think a page *like*
>>> http://tomcat.apache.org/tomcat-55-eol.html (simplified I guess) linked
>>> from the sentences like "(last release of the 12.04 series)" would help
>>> users to know better. Also I'd like that we clearly state on the download
>>> page, that, from our (a) "Backporting rule", *not all bug fixes are
>>> backported to all living release branches*. Our users have to live with it
>>> and engage the effort if they need a particular bug fix. With the help of
>>> the Jira generated releases logs this is now possible. I wrote also that
>>>>>> <<We should then explain to our releases users how they can use the
>>> Jira changes logs to check and amend what they use (with a link to wiki
>>> from the download page). >>
>>>>>> <<By comparing the trunk and releases change logs for instance>> and
>>> how to use https://svn.apache.org/viewvc/ then.
>>>>>> So finally not much is missing :)
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> Le 23/10/2014 15:08, Ron Wheeler a écrit :
>>>>>>> I think that many projects that are "important" and are hard to
>>> upgrade (user facing or customized at each installation) are fully
>>> supported until end of support and between EOS and EOL get fixes for bugs
>>> that have security implications where publishing the issue and fix to the
>>> current release or trunk will give hackers easy access  to data held in the
>>> old version or in some way open companies using that version to serious
>>> harm.
>>>>>>> It may be somewhat difficult to get people to fix older versions but
>>> there may be things that we could do to make this more likely.
>>>>>>> 1) Bugs can not be closed until it is fixed in all of the versions to
>>> which it must be applied (according to our EOS and EOL rules). It might be
>>> better to generate new issue that specifically addresses the patch to be
>>> applied rather than a full description of the symptoms of the original
>>> problem which is a main feature of the original report and make this new
>>> issue a dependency of the original.
>>>>>>> 2) Open a sub-project for the older releases with different
>>> committers who are interested in the older version and are not committing
>>> to the trunk.
>>>>>>> This might be a way for someone to get started in OFBiz programming.
>>>>>>> The activity in this sub-project would be a good way to judge the
>>> community's interest in maintaining the older release. One would expect
>>> that companies running the old version would be interested in supporting
>>> this sub-project even if they have no interest in the trunk.
>>>>>>> Ron
>>>>>>>
>>>>>>>
>>>>>>> On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
>>>>>>>> Inline
>>>>>>>>
>>>>>>>> Le 23/09/2014 09:26, Jacques Le Roux a écrit :
>>>>>>>>> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
>>>>>>>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>>>> <<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.>>
>>>>>>>>>> A more formal rule would be:
>>>>>>>>>> * commits to the trunk from Jira tickets of type Bugs can and
>>> *should* be backported to all the active releases
>>>>>>>>> Yes, hopefully we (I mean the really concerned persons) will not
>>> have to enforce (ie do it ourselves) the "should" :/
>>>>>>>>>> * commits to the trunk from Jira tickets of type different from
>>> Bugs need an explicit approval from the committers group before they can be
>>> backported to a specific active release
>>>>>>>>> Yes it's already like that and those are only rare exceptions,
>>> right way for me
>>>>>>>>>>> <<I think we should make that clear and expose a way to users for
>>> them to more
>>>>>>>>>>> "easily" maintain the releases they use.>>
>>>>>>>>>> +1 see below
>>>>>>>>>>
>>>>>>>>>>> As suggested Ron we could also define our own or refer to
>>> http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>>>>>>>>> Rather than referring to an external site, in my opinion we could
>>> improve (and make more evident) the information we already have in the
>>> download page where we already mention a tentative end of life; for example
>>> now we have:
>>>>>>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04
>>> series)
>>>>>>>>>> But when we specify an end of life, we should also make clear a
>>> few things:
>>>>>>>>>> * this is a community goal, and the help from the community is
>>> required to meet the goal (i.e. it is not guaranteed)
>>>>>>>>> Yes that's an important point indeed. We begin to get traction with
>>> (mostly thanks to the bug crush effort so far) and hopefully it will
>>> continue :)
>>>>>>>>>> * the plan is flexible; for example, if a group of interested
>>> users will show up today telling us that they want to actively maintain the
>>> release branch 11.04 even if the scheduled end of life is passed, I would
>>> not object to it; the opposite is also true: if we experience low
>>> interest/support (from committers and non committers) in maintaining a
>>> given release branch we could vote to modify its end of life
>>>>>>>>> The point I'd really want to be highlighted/explained is we don't
>>> guarantee that old bugs fixed in trunk are backported. Let's face it, we
>>> can't guarantee that, we have not real means to enforce it.
>>>>>>>> We have still no mention of that in the download page. I recently
>>> backported a number of bug fixes done in the last HWM bug crush in R12.04,
>>> but I (nobody I guess) can't guarantee we will always backport all bug
>>> fixes in living releases branches. I don't know how other TLP projects do,
>>> but it seems to me that to be correct/honest with our users we need to
>>> clarify that. We should even give a mean, or at least a way, to check that
>>> by themselves. By comparing the trunk and releases change logs for
>>> instance? I also suggested below
>>>>>>>> <<We should then explain to our releases users how they can use the
>>> Jira changes logs to check and amend what they use (maybe a link to wiki
>>> from download page to not clutter this main page).
>>>>>>>> I will think about what you wrote above and see how we can inform
>>> our our releases users (I mean a process to follow maybe even something
>>> more automated) >>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>>>> Now we need to think "technical" and automatize as possible with
>>> Jira
>>>>>>>>>> In my opinion it is possible to easily derive this from Jira,
>>> after the version configuration refactoring I did a few weeks ago (however
>>> the information will be more accurate with new releases).
>>>>>>>>>> The idea is to run a query on Jira with the following constraints:
>>>>>>>>>> project = OFBiz
>>>>>>>>>> type = Bug
>>>>>>>>>> status = not resolved
>>>>>>>>>> version *affected* = the release branch we are interested in (e.g.
>>> "release branch 12.04" OR the current latest release in the same branch
>>> (e.g. "Release 12.04.05")
>>>>>>>>>> The result should be a list of bugs affecting the release branch
>>> and/or the latest release in that branch; these are the bugs that are known
>>> and outstanding.
>>>>>>>>>> For them we will need help from the community (committers and non
>>> committers) to fix the bugs or backport existing fixes.
>>>>>>>>>> In the download page, we could add two links (to Jira) next to
>>> each available release:
>>>>>>>>>> 1) known bugs (links to the above report)
>>>>>>>>>> 2) release notes (link to the release notes available now)
>>>>>>>>>>
>>>>>>>>>> One technicality is the following: when we release a new release
>>> from the branch (e.g. 12.04.06), if there are open tickets with "version
>>> affected" set to the current version (e.g. 12.04.05) then we will have to
>>> bulk update all of them by adding also the new version (e.g. add "12.04.06"
>>> to affected version).
>>>>>>>>> This will need a strict observance from committers about versions
>>> to fix and fixed. I believe it's indeed the right way, anyway we have no
>>> others/betters (I mean offered by Jira) .
>>>>>>>>> We should then explain to our releases users how they can use the
>>> Jira changes logs to check and amend what they use (maybe a link to wiki
>>> from download page to not clutter this main page).
>>>>>>>>> I will think about what you wrote above and see how we can inform
>>> our our releases users (I mean a process to follow maybe even something
>>> more automated)
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>>> What I have read so far from Jacopo seems a good start to me
>>>>>>>>>> Thank you for confirming that we are on the same page. This is
>>> actually part of the plan I had in mind to maintain better release
>>> information when I started the version refactoring in Jira, and this
>>> conversation is helping to refine some points.
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>


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

Re: Release Strategy and Branch Support

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

+1

Especially if the patch is for a bug that has been already committed to the trunk and the contributor has prepared it for a specific branch and properly tested it.

Jacopo

On Mar 23, 2015, at 9:59 AM, Pierre Smits <pi...@gmail.com> wrote:

> As soon as a  bug fix ticket pertaining to a specific release branch is
> created in JIRA, the community should put its best effort in to get it
> resolved. When a that ticket has a patch, the committers should treat it
> with a higher priority.
> 
> That doesn't mean that the project is obliged to have it in next release.
> It means that the project should do its best to have it in the next best
> release. There are constraints to be considered.
> 
> Best regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> On Mon, Mar 23, 2015 at 9:46 AM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxsystems.com> wrote:
> 
>> I don't see a specific problem here; I mean, this is a community driven
>> project and all tasks will need a contribution from the community in order
>> to be implemented, including backports.
>> If something is not backported to release X.Y and someone is interested in
>> it then the person could implement the backport and test it and contribute
>> it to the community with a Jira ticket.
>> 
>> Jacopo
>> 
>> On Mar 23, 2015, at 8:31 AM, Jacques Le Roux <ja...@les7arts.com>
>> wrote:
>> 
>>> Ha just a small change I wrote that we should state in download page that
>>> *not all bug fixes are backported to all living release branches*
>>> Should be
>>> *despite our best effort, not all bug fixes are backported to all living
>> release branches* ;)
>>> 
>>> Jacques
>>> 
>>> Le 22/03/2015 14:49, Ron Wheeler a écrit :
>>>> Great discussion.
>>>> 
>>>> IMHO, bug fixes are different from enhancements. A fix is a gift to the
>> community (specially if you are fixing something that someone else broke).
>> Enhancement are usually done to add something that a small group wants and
>> they have to take more responsibility to maintain it and have more of a
>> role in deciding if it is to be backported.
>>>> 
>>>> If someone takes the time to fix something, I am not sure that they are
>> also responsible for doing all the backports (as called for in the "no good
>> deed goes unpunished" clause of the programmers creed.)
>>>> If the consensus is that a bug fix must be backported, it is not just
>> the responsibility of the person who fixes it in the trunk (or wherever),
>> it is a community commitment to the integrity of the product.
>>>> 
>>>> It becomes a blocker to the next release of that branch.
>>>> 
>>>> In an ERP, there needs to be a bit wider view of a "security patch".
>>>> If you have a bug that will result in a user company shipping a product
>> without getting paid or manufacturing items to fill a non-existant order
>> backlog, perhaps that qualifies as a "security release".
>>>> 
>>>> 
>>>> As long as each decision is made and communicated in a transparent way,
>> I think that most people will be able to live with the process.
>>>> 
>>>> Ron
>>>> 
>>>> On 22/03/2015 5:48 AM, Jacques Le Roux wrote:
>>>>> I was re-reading this thread because I think it's important and we
>> need to clarify 3 things
>>>>> 
>>>>> 1) how to decide when a branch is no longer supported (vs is alive)
>>>>> 2) what are the backporting rule
>>>>> 3) what to show on our OFBiz download page
>>>>> 
>>>>> In this thread we have already discussed the 2 last points below, but
>> not the 1st.
>>>>> 
>>>>> 1) EOL date
>>>>> I don't think we should make a distinction with EOS - End Of Support -
>> as Ron proposed
>>>>> It seems to me this should be a community decision leading to the
>> creation of a page like http://tomcat.apache.org/tomcat-55-eol.html
>> linked from OFBiz download page
>>>>> So we should decide of this date using a [PROPOSAL] thread that
>> anybody can start. With a lazy consensus no further [VOTE] thread should be
>> needed, but that could be also.
>>>>> 
>>>>> 2) Backporting rule
>>>>> Jacopo proposed
>>>>> 
>>>>> A more formal rule would be:
>>>>> a) commits to the trunk from Jira tickets of type Bugs can
>> and*should*  be backported to all the active releases
>>>>> b) commits to the trunk from Jira tickets of type different from Bugs
>> need an explicit approval from the committers group before they can be
>> backported to a specific active release
>>>>> 
>>>>> I like it, because it's simple and clear
>>>>> 
>>>>> a) I agree with the *should* (and not must) in 1st sentence. Because
>> we can't reasonably force committers to backport all bug fixes. Sometimes
>> there are too much conflicts, our volunteer time is limited. There is an
>> exception though: all vulnerability fixes *must* be backported. It's
>> obvious but better to state it.
>>>>> _Note_: when Jacopo wrote that, I then answered: <<Yes, hopefully we
>> (I mean the really concerned persons) will not have to enforce (ie do it
>> ourselves) the "should" :/ >> Since this discussion we are doing a better
>> job at this, it's heartening to see these results :)
>>>>> b) The second rule is clear, a committer should not backport a non bug
>> fix w/o the consent (lasy consensus) of a *reasonable number* of other
>> committers.
>>>>> 
>>>>> 3) Here Jacopo suggested to be as concise as possible,
>>>>> 
>>>>> in my opinion we could improve (and make more evident) the information
>> we already have in the download page where we already mention a tentative
>> end of life; for example now we have:
>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>>> 
>>>>> I agree, I think a page *like*
>> http://tomcat.apache.org/tomcat-55-eol.html (simplified I guess) linked
>> from the sentences like "(last release of the 12.04 series)" would help
>> users to know better. Also I'd like that we clearly state on the download
>> page, that, from our (a) "Backporting rule", *not all bug fixes are
>> backported to all living release branches*. Our users have to live with it
>> and engage the effort if they need a particular bug fix. With the help of
>> the Jira generated releases logs this is now possible. I wrote also that
>>>>> <<We should then explain to our releases users how they can use the
>> Jira changes logs to check and amend what they use (with a link to wiki
>> from the download page). >>
>>>>> <<By comparing the trunk and releases change logs for instance>> and
>> how to use https://svn.apache.org/viewvc/ then.
>>>>> 
>>>>> So finally not much is missing :)
>>>>> 
>>>>> Jacques
>>>>> 
>>>>> Le 23/10/2014 15:08, Ron Wheeler a écrit :
>>>>>> 
>>>>>> I think that many projects that are "important" and are hard to
>> upgrade (user facing or customized at each installation) are fully
>> supported until end of support and between EOS and EOL get fixes for bugs
>> that have security implications where publishing the issue and fix to the
>> current release or trunk will give hackers easy access  to data held in the
>> old version or in some way open companies using that version to serious
>> harm.
>>>>>> 
>>>>>> It may be somewhat difficult to get people to fix older versions but
>> there may be things that we could do to make this more likely.
>>>>>> 1) Bugs can not be closed until it is fixed in all of the versions to
>> which it must be applied (according to our EOS and EOL rules). It might be
>> better to generate new issue that specifically addresses the patch to be
>> applied rather than a full description of the symptoms of the original
>> problem which is a main feature of the original report and make this new
>> issue a dependency of the original.
>>>>>> 2) Open a sub-project for the older releases with different
>> committers who are interested in the older version and are not committing
>> to the trunk.
>>>>>> This might be a way for someone to get started in OFBiz programming.
>>>>>> The activity in this sub-project would be a good way to judge the
>> community's interest in maintaining the older release. One would expect
>> that companies running the old version would be interested in supporting
>> this sub-project even if they have no interest in the trunk.
>>>>>> 
>>>>>> Ron
>>>>>> 
>>>>>> 
>>>>>> On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
>>>>>>> Inline
>>>>>>> 
>>>>>>> Le 23/09/2014 09:26, Jacques Le Roux a écrit :
>>>>>>>> 
>>>>>>>> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
>>>>>>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>>> 
>>>>>>>>>> <<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.>>
>>>>>>>>>> 
>>>>>>>>> A more formal rule would be:
>>>>>>>>> * commits to the trunk from Jira tickets of type Bugs can and
>> *should* be backported to all the active releases
>>>>>>>> Yes, hopefully we (I mean the really concerned persons) will not
>> have to enforce (ie do it ourselves) the "should" :/
>>>>>>>>> * commits to the trunk from Jira tickets of type different from
>> Bugs need an explicit approval from the committers group before they can be
>> backported to a specific active release
>>>>>>>> Yes it's already like that and those are only rare exceptions,
>> right way for me
>>>>>>>>>> <<I think we should make that clear and expose a way to users for
>> them to more
>>>>>>>>>> "easily" maintain the releases they use.>>
>>>>>>>>> +1 see below
>>>>>>>>> 
>>>>>>>>>> As suggested Ron we could also define our own or refer to
>> http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>>>>>>>> Rather than referring to an external site, in my opinion we could
>> improve (and make more evident) the information we already have in the
>> download page where we already mention a tentative end of life; for example
>> now we have:
>>>>>>>>> 
>>>>>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04
>> series)
>>>>>>>>> 
>>>>>>>>> But when we specify an end of life, we should also make clear a
>> few things:
>>>>>>>>> * this is a community goal, and the help from the community is
>> required to meet the goal (i.e. it is not guaranteed)
>>>>>>>> Yes that's an important point indeed. We begin to get traction with
>> (mostly thanks to the bug crush effort so far) and hopefully it will
>> continue :)
>>>>>>>>> * the plan is flexible; for example, if a group of interested
>> users will show up today telling us that they want to actively maintain the
>> release branch 11.04 even if the scheduled end of life is passed, I would
>> not object to it; the opposite is also true: if we experience low
>> interest/support (from committers and non committers) in maintaining a
>> given release branch we could vote to modify its end of life
>>>>>>>> The point I'd really want to be highlighted/explained is we don't
>> guarantee that old bugs fixed in trunk are backported. Let's face it, we
>> can't guarantee that, we have not real means to enforce it.
>>>>>>> 
>>>>>>> We have still no mention of that in the download page. I recently
>> backported a number of bug fixes done in the last HWM bug crush in R12.04,
>> but I (nobody I guess) can't guarantee we will always backport all bug
>> fixes in living releases branches. I don't know how other TLP projects do,
>> but it seems to me that to be correct/honest with our users we need to
>> clarify that. We should even give a mean, or at least a way, to check that
>> by themselves. By comparing the trunk and releases change logs for
>> instance? I also suggested below
>>>>>>> <<We should then explain to our releases users how they can use the
>> Jira changes logs to check and amend what they use (maybe a link to wiki
>> from download page to not clutter this main page).
>>>>>>> I will think about what you wrote above and see how we can inform
>> our our releases users (I mean a process to follow maybe even something
>> more automated) >>
>>>>>>> 
>>>>>>> Jacques
>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Now we need to think "technical" and automatize as possible with
>> Jira
>>>>>>>>> In my opinion it is possible to easily derive this from Jira,
>> after the version configuration refactoring I did a few weeks ago (however
>> the information will be more accurate with new releases).
>>>>>>>>> The idea is to run a query on Jira with the following constraints:
>>>>>>>>> project = OFBiz
>>>>>>>>> type = Bug
>>>>>>>>> status = not resolved
>>>>>>>>> version *affected* = the release branch we are interested in (e.g.
>> "release branch 12.04" OR the current latest release in the same branch
>> (e.g. "Release 12.04.05")
>>>>>>>>> 
>>>>>>>>> The result should be a list of bugs affecting the release branch
>> and/or the latest release in that branch; these are the bugs that are known
>> and outstanding.
>>>>>>>>> For them we will need help from the community (committers and non
>> committers) to fix the bugs or backport existing fixes.
>>>>>>>>> 
>>>>>>>>> In the download page, we could add two links (to Jira) next to
>> each available release:
>>>>>>>>> 1) known bugs (links to the above report)
>>>>>>>>> 2) release notes (link to the release notes available now)
>>>>>>>>> 
>>>>>>>>> One technicality is the following: when we release a new release
>> from the branch (e.g. 12.04.06), if there are open tickets with "version
>> affected" set to the current version (e.g. 12.04.05) then we will have to
>> bulk update all of them by adding also the new version (e.g. add "12.04.06"
>> to affected version).
>>>>>>>> 
>>>>>>>> This will need a strict observance from committers about versions
>> to fix and fixed. I believe it's indeed the right way, anyway we have no
>> others/betters (I mean offered by Jira) .
>>>>>>>> 
>>>>>>>> We should then explain to our releases users how they can use the
>> Jira changes logs to check and amend what they use (maybe a link to wiki
>> from download page to not clutter this main page).
>>>>>>>> I will think about what you wrote above and see how we can inform
>> our our releases users (I mean a process to follow maybe even something
>> more automated)
>>>>>>>> 
>>>>>>>> Jacques
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> What I have read so far from Jacopo seems a good start to me
>>>>>>>>> Thank you for confirming that we are on the same page. This is
>> actually part of the plan I had in mind to maintain better release
>> information when I started the version refactoring in Jira, and this
>> conversation is helping to refine some points.
>>>>>>>>> 
>>>>>>>>> Jacopo
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>> 

Re: Release Strategy and Branch Support

[Pierre Smits <pi...@gmail.com>]

As soon as a  bug fix ticket pertaining to a specific release branch is
created in JIRA, the community should put its best effort in to get it
resolved. When a that ticket has a patch, the committers should treat it
with a higher priority.

That doesn't mean that the project is obliged to have it in next release.
It means that the project should do its best to have it in the next best
release. There are constraints to be considered.

Best regards,

Pierre Smits

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

On Mon, Mar 23, 2015 at 9:46 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:

> I don't see a specific problem here; I mean, this is a community driven
> project and all tasks will need a contribution from the community in order
> to be implemented, including backports.
> If something is not backported to release X.Y and someone is interested in
> it then the person could implement the backport and test it and contribute
> it to the community with a Jira ticket.
>
> Jacopo
>
> On Mar 23, 2015, at 8:31 AM, Jacques Le Roux <ja...@les7arts.com>
> wrote:
>
> > Ha just a small change I wrote that we should state in download page that
> > *not all bug fixes are backported to all living release branches*
> > Should be
> > *despite our best effort, not all bug fixes are backported to all living
> release branches* ;)
> >
> > Jacques
> >
> > Le 22/03/2015 14:49, Ron Wheeler a écrit :
> >> Great discussion.
> >>
> >> IMHO, bug fixes are different from enhancements. A fix is a gift to the
> community (specially if you are fixing something that someone else broke).
> Enhancement are usually done to add something that a small group wants and
> they have to take more responsibility to maintain it and have more of a
> role in deciding if it is to be backported.
> >>
> >> If someone takes the time to fix something, I am not sure that they are
> also responsible for doing all the backports (as called for in the "no good
> deed goes unpunished" clause of the programmers creed.)
> >> If the consensus is that a bug fix must be backported, it is not just
> the responsibility of the person who fixes it in the trunk (or wherever),
> it is a community commitment to the integrity of the product.
> >>
> >> It becomes a blocker to the next release of that branch.
> >>
> >> In an ERP, there needs to be a bit wider view of a "security patch".
> >> If you have a bug that will result in a user company shipping a product
> without getting paid or manufacturing items to fill a non-existant order
> backlog, perhaps that qualifies as a "security release".
> >>
> >>
> >> As long as each decision is made and communicated in a transparent way,
> I think that most people will be able to live with the process.
> >>
> >> Ron
> >>
> >> On 22/03/2015 5:48 AM, Jacques Le Roux wrote:
> >>> I was re-reading this thread because I think it's important and we
> need to clarify 3 things
> >>>
> >>> 1) how to decide when a branch is no longer supported (vs is alive)
> >>> 2) what are the backporting rule
> >>> 3) what to show on our OFBiz download page
> >>>
> >>> In this thread we have already discussed the 2 last points below, but
> not the 1st.
> >>>
> >>> 1) EOL date
> >>> I don't think we should make a distinction with EOS - End Of Support -
> as Ron proposed
> >>> It seems to me this should be a community decision leading to the
> creation of a page like http://tomcat.apache.org/tomcat-55-eol.html
> linked from OFBiz download page
> >>> So we should decide of this date using a [PROPOSAL] thread that
> anybody can start. With a lazy consensus no further [VOTE] thread should be
> needed, but that could be also.
> >>>
> >>> 2) Backporting rule
> >>> Jacopo proposed
> >>>
> >>> A more formal rule would be:
> >>> a) commits to the trunk from Jira tickets of type Bugs can
> and*should*  be backported to all the active releases
> >>> b) commits to the trunk from Jira tickets of type different from Bugs
> need an explicit approval from the committers group before they can be
> backported to a specific active release
> >>>
> >>> I like it, because it's simple and clear
> >>>
> >>> a) I agree with the *should* (and not must) in 1st sentence. Because
> we can't reasonably force committers to backport all bug fixes. Sometimes
> there are too much conflicts, our volunteer time is limited. There is an
> exception though: all vulnerability fixes *must* be backported. It's
> obvious but better to state it.
> >>> _Note_: when Jacopo wrote that, I then answered: <<Yes, hopefully we
> (I mean the really concerned persons) will not have to enforce (ie do it
> ourselves) the "should" :/ >> Since this discussion we are doing a better
> job at this, it's heartening to see these results :)
> >>> b) The second rule is clear, a committer should not backport a non bug
> fix w/o the consent (lasy consensus) of a *reasonable number* of other
> committers.
> >>>
> >>> 3) Here Jacopo suggested to be as concise as possible,
> >>>
> >>> in my opinion we could improve (and make more evident) the information
> we already have in the download page where we already mention a tentative
> end of life; for example now we have:
> >>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
> >>>
> >>> I agree, I think a page *like*
> http://tomcat.apache.org/tomcat-55-eol.html (simplified I guess) linked
> from the sentences like "(last release of the 12.04 series)" would help
> users to know better. Also I'd like that we clearly state on the download
> page, that, from our (a) "Backporting rule", *not all bug fixes are
> backported to all living release branches*. Our users have to live with it
> and engage the effort if they need a particular bug fix. With the help of
> the Jira generated releases logs this is now possible. I wrote also that
> >>> <<We should then explain to our releases users how they can use the
> Jira changes logs to check and amend what they use (with a link to wiki
> from the download page). >>
> >>> <<By comparing the trunk and releases change logs for instance>> and
> how to use https://svn.apache.org/viewvc/ then.
> >>>
> >>> So finally not much is missing :)
> >>>
> >>> Jacques
> >>>
> >>> Le 23/10/2014 15:08, Ron Wheeler a écrit :
> >>>>
> >>>> I think that many projects that are "important" and are hard to
> upgrade (user facing or customized at each installation) are fully
> supported until end of support and between EOS and EOL get fixes for bugs
> that have security implications where publishing the issue and fix to the
> current release or trunk will give hackers easy access  to data held in the
> old version or in some way open companies using that version to serious
> harm.
> >>>>
> >>>> It may be somewhat difficult to get people to fix older versions but
> there may be things that we could do to make this more likely.
> >>>> 1) Bugs can not be closed until it is fixed in all of the versions to
> which it must be applied (according to our EOS and EOL rules). It might be
> better to generate new issue that specifically addresses the patch to be
> applied rather than a full description of the symptoms of the original
> problem which is a main feature of the original report and make this new
> issue a dependency of the original.
> >>>> 2) Open a sub-project for the older releases with different
> committers who are interested in the older version and are not committing
> to the trunk.
> >>>> This might be a way for someone to get started in OFBiz programming.
> >>>> The activity in this sub-project would be a good way to judge the
> community's interest in maintaining the older release. One would expect
> that companies running the old version would be interested in supporting
> this sub-project even if they have no interest in the trunk.
> >>>>
> >>>> Ron
> >>>>
> >>>>
> >>>> On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
> >>>>> Inline
> >>>>>
> >>>>> Le 23/09/2014 09:26, Jacques Le Roux a écrit :
> >>>>>>
> >>>>>> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
> >>>>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
> >>>>>>>
> >>>>>>>> <<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.>>
> >>>>>>>>
> >>>>>>> A more formal rule would be:
> >>>>>>> * commits to the trunk from Jira tickets of type Bugs can and
> *should* be backported to all the active releases
> >>>>>> Yes, hopefully we (I mean the really concerned persons) will not
> have to enforce (ie do it ourselves) the "should" :/
> >>>>>>> * commits to the trunk from Jira tickets of type different from
> Bugs need an explicit approval from the committers group before they can be
> backported to a specific active release
> >>>>>> Yes it's already like that and those are only rare exceptions,
> right way for me
> >>>>>>>> <<I think we should make that clear and expose a way to users for
> them to more
> >>>>>>>> "easily" maintain the releases they use.>>
> >>>>>>> +1 see below
> >>>>>>>
> >>>>>>>> As suggested Ron we could also define our own or refer to
> http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
> >>>>>>> Rather than referring to an external site, in my opinion we could
> improve (and make more evident) the information we already have in the
> download page where we already mention a tentative end of life; for example
> now we have:
> >>>>>>>
> >>>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04
> series)
> >>>>>>>
> >>>>>>> But when we specify an end of life, we should also make clear a
> few things:
> >>>>>>> * this is a community goal, and the help from the community is
> required to meet the goal (i.e. it is not guaranteed)
> >>>>>> Yes that's an important point indeed. We begin to get traction with
> (mostly thanks to the bug crush effort so far) and hopefully it will
> continue :)
> >>>>>>> * the plan is flexible; for example, if a group of interested
> users will show up today telling us that they want to actively maintain the
> release branch 11.04 even if the scheduled end of life is passed, I would
> not object to it; the opposite is also true: if we experience low
> interest/support (from committers and non committers) in maintaining a
> given release branch we could vote to modify its end of life
> >>>>>> The point I'd really want to be highlighted/explained is we don't
> guarantee that old bugs fixed in trunk are backported. Let's face it, we
> can't guarantee that, we have not real means to enforce it.
> >>>>>
> >>>>> We have still no mention of that in the download page. I recently
> backported a number of bug fixes done in the last HWM bug crush in R12.04,
> but I (nobody I guess) can't guarantee we will always backport all bug
> fixes in living releases branches. I don't know how other TLP projects do,
> but it seems to me that to be correct/honest with our users we need to
> clarify that. We should even give a mean, or at least a way, to check that
> by themselves. By comparing the trunk and releases change logs for
> instance? I also suggested below
> >>>>> <<We should then explain to our releases users how they can use the
> Jira changes logs to check and amend what they use (maybe a link to wiki
> from download page to not clutter this main page).
> >>>>> I will think about what you wrote above and see how we can inform
> our our releases users (I mean a process to follow maybe even something
> more automated) >>
> >>>>>
> >>>>> Jacques
> >>>>>
> >>>>>>>
> >>>>>>>> Now we need to think "technical" and automatize as possible with
> Jira
> >>>>>>> In my opinion it is possible to easily derive this from Jira,
> after the version configuration refactoring I did a few weeks ago (however
> the information will be more accurate with new releases).
> >>>>>>> The idea is to run a query on Jira with the following constraints:
> >>>>>>> project = OFBiz
> >>>>>>> type = Bug
> >>>>>>> status = not resolved
> >>>>>>> version *affected* = the release branch we are interested in (e.g.
> "release branch 12.04" OR the current latest release in the same branch
> (e.g. "Release 12.04.05")
> >>>>>>>
> >>>>>>> The result should be a list of bugs affecting the release branch
> and/or the latest release in that branch; these are the bugs that are known
> and outstanding.
> >>>>>>> For them we will need help from the community (committers and non
> committers) to fix the bugs or backport existing fixes.
> >>>>>>>
> >>>>>>> In the download page, we could add two links (to Jira) next to
> each available release:
> >>>>>>> 1) known bugs (links to the above report)
> >>>>>>> 2) release notes (link to the release notes available now)
> >>>>>>>
> >>>>>>> One technicality is the following: when we release a new release
> from the branch (e.g. 12.04.06), if there are open tickets with "version
> affected" set to the current version (e.g. 12.04.05) then we will have to
> bulk update all of them by adding also the new version (e.g. add "12.04.06"
> to affected version).
> >>>>>>
> >>>>>> This will need a strict observance from committers about versions
> to fix and fixed. I believe it's indeed the right way, anyway we have no
> others/betters (I mean offered by Jira) .
> >>>>>>
> >>>>>> We should then explain to our releases users how they can use the
> Jira changes logs to check and amend what they use (maybe a link to wiki
> from download page to not clutter this main page).
> >>>>>> I will think about what you wrote above and see how we can inform
> our our releases users (I mean a process to follow maybe even something
> more automated)
> >>>>>>
> >>>>>> Jacques
> >>>>>>
> >>>>>>>
> >>>>>>>> What I have read so far from Jacopo seems a good start to me
> >>>>>>> Thank you for confirming that we are on the same page. This is
> actually part of the plan I had in mind to maintain better release
> information when I started the version refactoring in Jira, and this
> conversation is helping to refine some points.
> >>>>>>>
> >>>>>>> Jacopo
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
>
>

Re: Release Strategy and Branch Support

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

I don't see a specific problem here; I mean, this is a community driven project and all tasks will need a contribution from the community in order to be implemented, including backports.
If something is not backported to release X.Y and someone is interested in it then the person could implement the backport and test it and contribute it to the community with a Jira ticket.

Jacopo

On Mar 23, 2015, at 8:31 AM, Jacques Le Roux <ja...@les7arts.com> wrote:

> Ha just a small change I wrote that we should state in download page that
> *not all bug fixes are backported to all living release branches*
> Should be
> *despite our best effort, not all bug fixes are backported to all living release branches* ;)
> 
> Jacques
> 
> Le 22/03/2015 14:49, Ron Wheeler a écrit :
>> Great discussion.
>> 
>> IMHO, bug fixes are different from enhancements. A fix is a gift to the community (specially if you are fixing something that someone else broke). Enhancement are usually done to add something that a small group wants and they have to take more responsibility to maintain it and have more of a role in deciding if it is to be backported.
>> 
>> If someone takes the time to fix something, I am not sure that they are also responsible for doing all the backports (as called for in the "no good deed goes unpunished" clause of the programmers creed.)
>> If the consensus is that a bug fix must be backported, it is not just the responsibility of the person who fixes it in the trunk (or wherever), it is a community commitment to the integrity of the product.
>> 
>> It becomes a blocker to the next release of that branch.
>> 
>> In an ERP, there needs to be a bit wider view of a "security patch".
>> If you have a bug that will result in a user company shipping a product without getting paid or manufacturing items to fill a non-existant order backlog, perhaps that qualifies as a "security release".
>> 
>> 
>> As long as each decision is made and communicated in a transparent way, I think that most people will be able to live with the process.
>> 
>> Ron
>> 
>> On 22/03/2015 5:48 AM, Jacques Le Roux wrote:
>>> I was re-reading this thread because I think it's important and we need to clarify 3 things
>>> 
>>> 1) how to decide when a branch is no longer supported (vs is alive)
>>> 2) what are the backporting rule
>>> 3) what to show on our OFBiz download page
>>> 
>>> In this thread we have already discussed the 2 last points below, but not the 1st.
>>> 
>>> 1) EOL date
>>> I don't think we should make a distinction with EOS - End Of Support - as Ron proposed
>>> It seems to me this should be a community decision leading to the creation of a page like http://tomcat.apache.org/tomcat-55-eol.html linked from OFBiz download page
>>> So we should decide of this date using a [PROPOSAL] thread that anybody can start. With a lazy consensus no further [VOTE] thread should be needed, but that could be also.
>>> 
>>> 2) Backporting rule
>>> Jacopo proposed
>>> 
>>> A more formal rule would be:
>>> a) commits to the trunk from Jira tickets of type Bugs can and*should*  be backported to all the active releases
>>> b) commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be backported to a specific active release
>>> 
>>> I like it, because it's simple and clear
>>> 
>>> a) I agree with the *should* (and not must) in 1st sentence. Because we can't reasonably force committers to backport all bug fixes. Sometimes there are too much conflicts, our volunteer time is limited. There is an exception though: all vulnerability fixes *must* be backported. It's obvious but better to state it.
>>> _Note_: when Jacopo wrote that, I then answered: <<Yes, hopefully we (I mean the really concerned persons) will not have to enforce (ie do it ourselves) the "should" :/ >> Since this discussion we are doing a better job at this, it's heartening to see these results :)
>>> b) The second rule is clear, a committer should not backport a non bug fix w/o the consent (lasy consensus) of a *reasonable number* of other committers.
>>> 
>>> 3) Here Jacopo suggested to be as concise as possible,
>>> 
>>> in my opinion we could improve (and make more evident) the information we already have in the download page where we already mention a tentative end of life; for example now we have:
>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>> 
>>> I agree, I think a page *like* http://tomcat.apache.org/tomcat-55-eol.html (simplified I guess) linked from the sentences like "(last release of the 12.04 series)" would help users to know better. Also I'd like that we clearly state on the download page, that, from our (a) "Backporting rule", *not all bug fixes are backported to all living release branches*. Our users have to live with it and engage the effort if they need a particular bug fix. With the help of the Jira generated releases logs this is now possible. I wrote also that
>>> <<We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (with a link to wiki from the download page). >>
>>> <<By comparing the trunk and releases change logs for instance>> and how to use https://svn.apache.org/viewvc/ then.
>>> 
>>> So finally not much is missing :)
>>> 
>>> Jacques
>>> 
>>> Le 23/10/2014 15:08, Ron Wheeler a écrit :
>>>> 
>>>> I think that many projects that are "important" and are hard to upgrade (user facing or customized at each installation) are fully supported until end of support and between EOS and EOL get fixes for bugs that have security implications where publishing the issue and fix to the current release or trunk will give hackers easy access  to data held in the old version or in some way open companies using that version to serious harm.
>>>> 
>>>> It may be somewhat difficult to get people to fix older versions but there may be things that we could do to make this more likely.
>>>> 1) Bugs can not be closed until it is fixed in all of the versions to which it must be applied (according to our EOS and EOL rules). It might be better to generate new issue that specifically addresses the patch to be applied rather than a full description of the symptoms of the original problem which is a main feature of the original report and make this new issue a dependency of the original.
>>>> 2) Open a sub-project for the older releases with different committers who are interested in the older version and are not committing to the trunk.
>>>> This might be a way for someone to get started in OFBiz programming.
>>>> The activity in this sub-project would be a good way to judge the community's interest in maintaining the older release. One would expect that companies running the old version would be interested in supporting this sub-project even if they have no interest in the trunk.
>>>> 
>>>> Ron
>>>> 
>>>> 
>>>> On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
>>>>> Inline
>>>>> 
>>>>> Le 23/09/2014 09:26, Jacques Le Roux a écrit :
>>>>>> 
>>>>>> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
>>>>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>>>>>> 
>>>>>>>> <<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.>>
>>>>>>>> 
>>>>>>> A more formal rule would be:
>>>>>>> * commits to the trunk from Jira tickets of type Bugs can and *should* be backported to all the active releases
>>>>>> Yes, hopefully we (I mean the really concerned persons) will not have to enforce (ie do it ourselves) the "should" :/
>>>>>>> * commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be backported to a specific active release
>>>>>> Yes it's already like that and those are only rare exceptions, right way for me
>>>>>>>> <<I think we should make that clear and expose a way to users for them to more
>>>>>>>> "easily" maintain the releases they use.>>
>>>>>>> +1 see below
>>>>>>> 
>>>>>>>> As suggested Ron we could also define our own or refer to http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>>>>>> Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download page where we already mention a tentative end of life; for example now we have:
>>>>>>> 
>>>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>>>>> 
>>>>>>> But when we specify an end of life, we should also make clear a few things:
>>>>>>> * this is a community goal, and the help from the community is required to meet the goal (i.e. it is not guaranteed)
>>>>>> Yes that's an important point indeed. We begin to get traction with (mostly thanks to the bug crush effort so far) and hopefully it will continue :)
>>>>>>> * the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
>>>>>> The point I'd really want to be highlighted/explained is we don't guarantee that old bugs fixed in trunk are backported. Let's face it, we can't guarantee that, we have not real means to enforce it.
>>>>> 
>>>>> We have still no mention of that in the download page. I recently backported a number of bug fixes done in the last HWM bug crush in R12.04, but I (nobody I guess) can't guarantee we will always backport all bug fixes in living releases branches. I don't know how other TLP projects do, but it seems to me that to be correct/honest with our users we need to clarify that. We should even give a mean, or at least a way, to check that by themselves. By comparing the trunk and releases change logs for instance? I also suggested below
>>>>> <<We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (maybe a link to wiki from download page to not clutter this main page).
>>>>> I will think about what you wrote above and see how we can inform our our releases users (I mean a process to follow maybe even something more automated) >>
>>>>> 
>>>>> Jacques
>>>>> 
>>>>>>> 
>>>>>>>> Now we need to think "technical" and automatize as possible with Jira
>>>>>>> In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the information will be more accurate with new releases).
>>>>>>> The idea is to run a query on Jira with the following constraints:
>>>>>>> project = OFBiz
>>>>>>> type = Bug
>>>>>>> status = not resolved
>>>>>>> version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g. "Release 12.04.05")
>>>>>>> 
>>>>>>> The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and outstanding.
>>>>>>> For them we will need help from the community (committers and non committers) to fix the bugs or backport existing fixes.
>>>>>>> 
>>>>>>> In the download page, we could add two links (to Jira) next to each available release:
>>>>>>> 1) known bugs (links to the above report)
>>>>>>> 2) release notes (link to the release notes available now)
>>>>>>> 
>>>>>>> One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version affected" set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add "12.04.06" to affected version).
>>>>>> 
>>>>>> This will need a strict observance from committers about versions to fix and fixed. I believe it's indeed the right way, anyway we have no others/betters (I mean offered by Jira) .
>>>>>> 
>>>>>> We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (maybe a link to wiki from download page to not clutter this main page).
>>>>>> I will think about what you wrote above and see how we can inform our our releases users (I mean a process to follow maybe even something more automated)
>>>>>> 
>>>>>> Jacques
>>>>>> 
>>>>>>> 
>>>>>>>> What I have read so far from Jacopo seems a good start to me
>>>>>>> Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information when I started the version refactoring in Jira, and this conversation is helping to refine some points.
>>>>>>> 
>>>>>>> Jacopo
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 

Re: Release Strategy and Branch Support

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

Ha just a small change I wrote that we should state in download page that
*not all bug fixes are backported to all living release branches*
Should be
*despite our best effort, not all bug fixes are backported to all living release branches* ;)

Jacques

Le 22/03/2015 14:49, Ron Wheeler a écrit :
> Great discussion.
>
> IMHO, bug fixes are different from enhancements. A fix is a gift to the community (specially if you are fixing something that someone else broke). 
> Enhancement are usually done to add something that a small group wants and they have to take more responsibility to maintain it and have more of a 
> role in deciding if it is to be backported.
>
> If someone takes the time to fix something, I am not sure that they are also responsible for doing all the backports (as called for in the "no good 
> deed goes unpunished" clause of the programmers creed.)
> If the consensus is that a bug fix must be backported, it is not just the responsibility of the person who fixes it in the trunk (or wherever), it 
> is a community commitment to the integrity of the product.
>
> It becomes a blocker to the next release of that branch.
>
> In an ERP, there needs to be a bit wider view of a "security patch".
> If you have a bug that will result in a user company shipping a product without getting paid or manufacturing items to fill a non-existant order 
> backlog, perhaps that qualifies as a "security release".
>
>
> As long as each decision is made and communicated in a transparent way, I think that most people will be able to live with the process.
>
> Ron
>
> On 22/03/2015 5:48 AM, Jacques Le Roux wrote:
>> I was re-reading this thread because I think it's important and we need to clarify 3 things
>>
>> 1) how to decide when a branch is no longer supported (vs is alive)
>> 2) what are the backporting rule
>> 3) what to show on our OFBiz download page
>>
>> In this thread we have already discussed the 2 last points below, but not the 1st.
>>
>> 1) EOL date
>> I don't think we should make a distinction with EOS - End Of Support - as Ron proposed
>> It seems to me this should be a community decision leading to the creation of a page like http://tomcat.apache.org/tomcat-55-eol.html linked from 
>> OFBiz download page
>> So we should decide of this date using a [PROPOSAL] thread that anybody can start. With a lazy consensus no further [VOTE] thread should be needed, 
>> but that could be also.
>>
>> 2) Backporting rule
>> Jacopo proposed
>>
>> A more formal rule would be:
>> a) commits to the trunk from Jira tickets of type Bugs can and*should*  be backported to all the active releases
>> b) commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be 
>> backported to a specific active release
>>
>> I like it, because it's simple and clear
>>
>> a) I agree with the *should* (and not must) in 1st sentence. Because we can't reasonably force committers to backport all bug fixes. Sometimes 
>> there are too much conflicts, our volunteer time is limited. There is an exception though: all vulnerability fixes *must* be backported. It's 
>> obvious but better to state it.
>> _Note_: when Jacopo wrote that, I then answered: <<Yes, hopefully we (I mean the really concerned persons) will not have to enforce (ie do it 
>> ourselves) the "should" :/ >> Since this discussion we are doing a better job at this, it's heartening to see these results :)
>> b) The second rule is clear, a committer should not backport a non bug fix w/o the consent (lasy consensus) of a *reasonable number* of other 
>> committers.
>>
>> 3) Here Jacopo suggested to be as concise as possible,
>>
>> in my opinion we could improve (and make more evident) the information we already have in the download page where we already mention a tentative 
>> end of life; for example now we have:
>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>
>> I agree, I think a page *like* http://tomcat.apache.org/tomcat-55-eol.html (simplified I guess) linked from the sentences like "(last release of 
>> the 12.04 series)" would help users to know better. Also I'd like that we clearly state on the download page, that, from our (a) "Backporting 
>> rule", *not all bug fixes are backported to all living release branches*. Our users have to live with it and engage the effort if they need a 
>> particular bug fix. With the help of the Jira generated releases logs this is now possible. I wrote also that
>> <<We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (with a link to wiki from 
>> the download page). >>
>> <<By comparing the trunk and releases change logs for instance>> and how to use https://svn.apache.org/viewvc/ then.
>>
>> So finally not much is missing :)
>>
>> Jacques
>>
>> Le 23/10/2014 15:08, Ron Wheeler a écrit :
>>>
>>>  I think that many projects that are "important" and are hard to upgrade (user facing or customized at each installation) are fully supported 
>>> until end of support and between EOS and EOL get fixes for bugs that have security implications where publishing the issue and fix to the current 
>>> release or trunk will give hackers easy access  to data held in the old version or in some way open companies using that version to serious harm.
>>>
>>> It may be somewhat difficult to get people to fix older versions but there may be things that we could do to make this more likely.
>>> 1) Bugs can not be closed until it is fixed in all of the versions to which it must be applied (according to our EOS and EOL rules). It might be 
>>> better to generate new issue that specifically addresses the patch to be applied rather than a full description of the symptoms of the original 
>>> problem which is a main feature of the original report and make this new issue a dependency of the original.
>>> 2) Open a sub-project for the older releases with different committers who are interested in the older version and are not committing to the trunk.
>>> This might be a way for someone to get started in OFBiz programming.
>>> The activity in this sub-project would be a good way to judge the community's interest in maintaining the older release. One would expect that 
>>> companies running the old version would be interested in supporting this sub-project even if they have no interest in the trunk.
>>>
>>> Ron
>>>
>>>
>>> On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
>>>> Inline
>>>>
>>>> Le 23/09/2014 09:26, Jacques Le Roux a écrit :
>>>>>
>>>>> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
>>>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>>>>>
>>>>>>> <<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.>>
>>>>>>>
>>>>>> A more formal rule would be:
>>>>>> * commits to the trunk from Jira tickets of type Bugs can and *should* be backported to all the active releases
>>>>> Yes, hopefully we (I mean the really concerned persons) will not have to enforce (ie do it ourselves) the "should" :/
>>>>>> * commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be 
>>>>>> backported to a specific active release
>>>>> Yes it's already like that and those are only rare exceptions, right way for me
>>>>>>> <<I think we should make that clear and expose a way to users for them to more
>>>>>>> "easily" maintain the releases they use.>>
>>>>>> +1 see below
>>>>>>
>>>>>>> As suggested Ron we could also define our own or refer to http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>>>>> Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the 
>>>>>> download page where we already mention a tentative end of life; for example now we have:
>>>>>>
>>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>>>>
>>>>>> But when we specify an end of life, we should also make clear a few things:
>>>>>> * this is a community goal, and the help from the community is required to meet the goal (i.e. it is not guaranteed)
>>>>> Yes that's an important point indeed. We begin to get traction with (mostly thanks to the bug crush effort so far) and hopefully it will 
>>>>> continue :)
>>>>>> * the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the 
>>>>>> release branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low 
>>>>>> interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
>>>>> The point I'd really want to be highlighted/explained is we don't guarantee that old bugs fixed in trunk are backported. Let's face it, we can't 
>>>>> guarantee that, we have not real means to enforce it.
>>>>
>>>> We have still no mention of that in the download page. I recently backported a number of bug fixes done in the last HWM bug crush in R12.04, but 
>>>> I (nobody I guess) can't guarantee we will always backport all bug fixes in living releases branches. I don't know how other TLP projects do, but 
>>>> it seems to me that to be correct/honest with our users we need to clarify that. We should even give a mean, or at least a way, to check that by 
>>>> themselves. By comparing the trunk and releases change logs for instance? I also suggested below
>>>> <<We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (maybe a link to wiki from 
>>>> download page to not clutter this main page).
>>>> I will think about what you wrote above and see how we can inform our our releases users (I mean a process to follow maybe even something more 
>>>> automated) >>
>>>>
>>>> Jacques
>>>>
>>>>>>
>>>>>>> Now we need to think "technical" and automatize as possible with Jira
>>>>>> In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the 
>>>>>> information will be more accurate with new releases).
>>>>>> The idea is to run a query on Jira with the following constraints:
>>>>>> project = OFBiz
>>>>>> type = Bug
>>>>>> status = not resolved
>>>>>> version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch 
>>>>>> (e.g. "Release 12.04.05")
>>>>>>
>>>>>> The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known 
>>>>>> and outstanding.
>>>>>> For them we will need help from the community (committers and non committers) to fix the bugs or backport existing fixes.
>>>>>>
>>>>>> In the download page, we could add two links (to Jira) next to each available release:
>>>>>> 1) known bugs (links to the above report)
>>>>>> 2) release notes (link to the release notes available now)
>>>>>>
>>>>>> One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version 
>>>>>> affected" set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add 
>>>>>> "12.04.06" to affected version).
>>>>>
>>>>> This will need a strict observance from committers about versions to fix and fixed. I believe it's indeed the right way, anyway we have no 
>>>>> others/betters (I mean offered by Jira) .
>>>>>
>>>>> We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (maybe a link to wiki from 
>>>>> download page to not clutter this main page).
>>>>> I will think about what you wrote above and see how we can inform our our releases users (I mean a process to follow maybe even something more 
>>>>> automated)
>>>>>
>>>>> Jacques
>>>>>
>>>>>>
>>>>>>> What I have read so far from Jacopo seems a good start to me
>>>>>> Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information 
>>>>>> when I started the version refactoring in Jira, and this conversation is helping to refine some points.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>

Re: Release Strategy and Branch Support

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

Great discussion.

IMHO, bug fixes are different from enhancements. A fix is a gift to the 
community (specially if you are fixing something that someone else 
broke). Enhancement are usually done to add something that a small group 
wants and they have to take more responsibility to maintain it and have 
more of a role in deciding if it is to be backported.

If someone takes the time to fix something, I am not sure that they are 
also responsible for doing all the backports (as called for in the "no 
good deed goes unpunished" clause of the programmers creed.)
If the consensus is that a bug fix must be backported, it is not just 
the responsibility of the person who fixes it in the trunk (or 
wherever), it is a community commitment to the integrity of the product.

It becomes a blocker to the next release of that branch.

In an ERP, there needs to be a bit wider view of a "security patch".
If you have a bug that will result in a user company shipping a product 
without getting paid or manufacturing items to fill a non-existant order 
backlog, perhaps that qualifies as a "security release".


As long as each decision is made and communicated in a transparent way, 
I think that most people will be able to live with the process.

Ron

On 22/03/2015 5:48 AM, Jacques Le Roux wrote:
> I was re-reading this thread because I think it's important and we 
> need to clarify 3 things
>
> 1) how to decide when a branch is no longer supported (vs is alive)
> 2) what are the backporting rule
> 3) what to show on our OFBiz download page
>
> In this thread we have already discussed the 2 last points below, but 
> not the 1st.
>
> 1) EOL date
> I don't think we should make a distinction with EOS - End Of Support - 
> as Ron proposed
> It seems to me this should be a community decision leading to the 
> creation of a page like http://tomcat.apache.org/tomcat-55-eol.html 
> linked from OFBiz download page
> So we should decide of this date using a [PROPOSAL] thread that 
> anybody can start. With a lazy consensus no further [VOTE] thread 
> should be needed, but that could be also.
>
> 2) Backporting rule
> Jacopo proposed
>
> A more formal rule would be:
> a) commits to the trunk from Jira tickets of type Bugs can 
> and*should*  be backported to all the active releases
> b) commits to the trunk from Jira tickets of type different from Bugs 
> need an explicit approval from the committers group before they can be 
> backported to a specific active release
>
> I like it, because it's simple and clear
>
> a) I agree with the *should* (and not must) in 1st sentence. Because 
> we can't reasonably force committers to backport all bug fixes. 
> Sometimes there are too much conflicts, our volunteer time is limited. 
> There is an exception though: all vulnerability fixes *must* be 
> backported. It's obvious but better to state it.
> _Note_: when Jacopo wrote that, I then answered: <<Yes, hopefully we 
> (I mean the really concerned persons) will not have to enforce (ie do 
> it ourselves) the "should" :/ >> Since this discussion we are doing a 
> better job at this, it's heartening to see these results :)
> b) The second rule is clear, a committer should not backport a non bug 
> fix w/o the consent (lasy consensus) of a *reasonable number* of other 
> committers.
>
> 3) Here Jacopo suggested to be as concise as possible,
>
> in my opinion we could improve (and make more evident) the information 
> we already have in the download page where we already mention a 
> tentative end of life; for example now we have:
> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>
> I agree, I think a page *like* 
> http://tomcat.apache.org/tomcat-55-eol.html (simplified I guess) 
> linked from the sentences like "(last release of the 12.04 series)" 
> would help users to know better. Also I'd like that we clearly state 
> on the download page, that, from our (a) "Backporting rule", *not all 
> bug fixes are backported to all living release branches*. Our users 
> have to live with it and engage the effort if they need a particular 
> bug fix. With the help of the Jira generated releases logs this is now 
> possible.  I wrote also that
> <<We should then explain to our releases users how they can use the 
> Jira changes logs to check and amend what they use (with a link to 
> wiki from the download page). >>
> <<By comparing the trunk and releases change logs for instance>> and 
> how to use https://svn.apache.org/viewvc/ then.
>
> So finally not much is missing :)
>
> Jacques
>
> Le 23/10/2014 15:08, Ron Wheeler a écrit :
>>
>>  I think that many projects that are "important" and are hard to 
>> upgrade (user facing or customized at each installation) are fully 
>> supported until end of support and between EOS and EOL get fixes for 
>> bugs that have security implications where publishing the issue and 
>> fix to the current release or trunk will give hackers easy access  to 
>> data held in the old version or in some way open companies using that 
>> version to serious harm.
>>
>> It may be somewhat difficult to get people to fix older versions but 
>> there may be things that we could do to make this more likely.
>> 1) Bugs can not be closed until it is fixed in all of the versions to 
>> which it must be applied (according to our EOS and EOL rules). It 
>> might be better to generate new issue that specifically addresses the 
>> patch to be applied rather than a full description of the symptoms of 
>> the original problem which is a main feature of the original report 
>> and make this new issue a dependency of the original.
>> 2) Open a sub-project for the older releases with different 
>> committers who are interested in the older version and are not 
>> committing to the trunk.
>> This might be a way for someone to get started in OFBiz programming.
>> The activity in this sub-project would be a good way to judge the 
>> community's interest in maintaining the older release. One would 
>> expect that companies running the old version would be interested in 
>> supporting this sub-project even if they have no interest in the trunk.
>>
>> Ron
>>
>>
>> On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
>>> Inline
>>>
>>> Le 23/09/2014 09:26, Jacques Le Roux a écrit :
>>>>
>>>> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
>>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux 
>>>>> <ja...@les7arts.com> wrote:
>>>>>
>>>>>> <<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.>>
>>>>>>
>>>>> A more formal rule would be:
>>>>> * commits to the trunk from Jira tickets of type Bugs can and 
>>>>> *should* be backported to all the active releases
>>>> Yes, hopefully we (I mean the really concerned persons) will not 
>>>> have to enforce (ie do it ourselves) the "should" :/
>>>>> * commits to the trunk from Jira tickets of type different from 
>>>>> Bugs need an explicit approval from the committers group before 
>>>>> they can be backported to a specific active release
>>>> Yes it's already like that and those are only rare exceptions, 
>>>> right way for me
>>>>>> <<I think we should make that clear and expose a way to users for 
>>>>>> them to more
>>>>>> "easily" maintain the releases they use.>>
>>>>> +1 see below
>>>>>
>>>>>> As suggested Ron we could also define our own or refer to 
>>>>>> http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>>>> Rather than referring to an external site, in my opinion we could 
>>>>> improve (and make more evident) the information we already have in 
>>>>> the download page where we already mention a tentative end of 
>>>>> life; for example now we have:
>>>>>
>>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 
>>>>> series)
>>>>>
>>>>> But when we specify an end of life, we should also make clear a 
>>>>> few things:
>>>>> * this is a community goal, and the help from the community is 
>>>>> required to meet the goal (i.e. it is not guaranteed)
>>>> Yes that's an important point indeed. We begin to get traction with 
>>>> (mostly thanks to the bug crush effort so far) and hopefully it 
>>>> will continue :)
>>>>> * the plan is flexible; for example, if a group of interested 
>>>>> users will show up today telling us that they want to actively 
>>>>> maintain the release branch 11.04 even if the scheduled end of 
>>>>> life is passed, I would not object to it; the opposite is also 
>>>>> true: if we experience low interest/support (from committers and 
>>>>> non committers) in maintaining a given release branch we could 
>>>>> vote to modify its end of life
>>>> The point I'd really want to be highlighted/explained is we don't 
>>>> guarantee that old bugs fixed in trunk are backported. Let's face 
>>>> it, we can't guarantee that, we have not real means to enforce it.
>>>
>>> We have still no mention of that in the download page. I recently 
>>> backported a number of bug fixes done in the last HWM bug crush in 
>>> R12.04, but I (nobody I guess) can't guarantee we will always 
>>> backport all bug fixes in living releases branches. I don't know how 
>>> other TLP projects do, but it seems to me that to be correct/honest 
>>> with our users we need to clarify that. We should even give a mean, 
>>> or at least a way, to check that by themselves. By comparing the 
>>> trunk and releases change logs for instance? I also suggested below
>>> <<We should then explain to our releases users how they can use the 
>>> Jira changes logs to check and amend what they use (maybe a link to 
>>> wiki from download page to not clutter this main page).
>>> I will think about what you wrote above and see how we can inform 
>>> our our releases users (I mean a process to follow maybe even 
>>> something more automated) >>
>>>
>>> Jacques
>>>
>>>>>
>>>>>> Now we need to think "technical" and automatize as possible with 
>>>>>> Jira
>>>>> In my opinion it is possible to easily derive this from Jira, 
>>>>> after the version configuration refactoring I did a few weeks ago 
>>>>> (however the information will be more accurate with new releases).
>>>>> The idea is to run a query on Jira with the following constraints:
>>>>> project = OFBiz
>>>>> type = Bug
>>>>> status = not resolved
>>>>> version *affected* = the release branch we are interested in (e.g. 
>>>>> "release branch 12.04" OR the current latest release in the same 
>>>>> branch (e.g. "Release 12.04.05")
>>>>>
>>>>> The result should be a list of bugs affecting the release branch 
>>>>> and/or the latest release in that branch; these are the bugs that 
>>>>> are known and outstanding.
>>>>> For them we will need help from the community (committers and non 
>>>>> committers) to fix the bugs or backport existing fixes.
>>>>>
>>>>> In the download page, we could add two links (to Jira) next to 
>>>>> each available release:
>>>>> 1) known bugs (links to the above report)
>>>>> 2) release notes (link to the release notes available now)
>>>>>
>>>>> One technicality is the following: when we release a new release 
>>>>> from the branch (e.g. 12.04.06), if there are open tickets with 
>>>>> "version affected" set to the current version (e.g. 12.04.05) then 
>>>>> we will have to bulk update all of them by adding also the new 
>>>>> version (e.g. add "12.04.06" to affected version).
>>>>
>>>> This will need a strict observance from committers about versions 
>>>> to fix and fixed. I believe it's indeed the right way, anyway we 
>>>> have no others/betters (I mean offered by Jira) .
>>>>
>>>> We should then explain to our releases users how they can use the 
>>>> Jira changes logs to check and amend what they use (maybe a link to 
>>>> wiki from download page to not clutter this main page).
>>>> I will think about what you wrote above and see how we can inform 
>>>> our our releases users (I mean a process to follow maybe even 
>>>> something more automated)
>>>>
>>>> Jacques
>>>>
>>>>>
>>>>>> What I have read so far from Jacopo seems a good start to me
>>>>> Thank you for confirming that we are on the same page. This is 
>>>>> actually part of the plan I had in mind to maintain better release 
>>>>> information when I started the version refactoring in Jira, and 
>>>>> this conversation is helping to refine some points.
>>>>>
>>>>> Jacopo
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>


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

Re: Release Strategy and Branch Support

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

I was re-reading this thread because I think it's important and we need to clarify 3 things

1) how to decide when a branch is no longer supported (vs is alive)
2) what are the backporting rule
3) what to show on our OFBiz download page

In this thread we have already discussed the 2 last points below, but not the 1st.

1) EOL date
I don't think we should make a distinction with EOS - End Of Support - as Ron proposed
It seems to me this should be a community decision leading to the creation of a page like http://tomcat.apache.org/tomcat-55-eol.html linked from 
OFBiz download page
So we should decide of this date using a [PROPOSAL] thread that anybody can start. With a lazy consensus no further [VOTE] thread should be needed, 
but that could be also.

2) Backporting rule
Jacopo proposed

A more formal rule would be:
a) commits to the trunk from Jira tickets of type Bugs can and*should*  be backported to all the active releases
b) commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be backported to a specific active release

I like it, because it's simple and clear

a) I agree with the *should* (and not must) in 1st sentence. Because we can't reasonably force committers to backport all bug fixes. Sometimes there 
are too much conflicts, our volunteer time is limited. There is an exception though: all vulnerability fixes *must* be backported. It's obvious but 
better to state it.
_Note_: when Jacopo wrote that, I then answered: <<Yes, hopefully we (I mean the really concerned persons) will not have to enforce (ie do it 
ourselves) the "should" :/ >> Since this discussion we are doing a better job at this, it's heartening to see these results :)
b) The second rule is clear, a committer should not backport a non bug fix w/o the consent (lasy consensus) of a *reasonable number* of other committers.

3) Here Jacopo suggested to be as concise as possible,

in my opinion we could improve (and make more evident) the information we already have in the download page where we already mention a tentative end of life; for example now we have:
• April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)

I agree, I think a page *like* http://tomcat.apache.org/tomcat-55-eol.html (simplified I guess) linked from the sentences like "(last release of the 
12.04 series)" would help users to know better. Also I'd like that we clearly state on the download page, that, from our (a) "Backporting rule", *not 
all bug fixes are backported to all living release branches*. Our users have to live with it and engage the effort if they need a particular bug fix. 
With the help of the Jira generated releases logs this is now possible.  I wrote also that
<<We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (with a link to wiki from the 
download page). >>
<<By comparing the trunk and releases change logs for instance>> and how to use https://svn.apache.org/viewvc/ then.

So finally not much is missing :)

Jacques

Le 23/10/2014 15:08, Ron Wheeler a écrit :
>
>  I think that many projects that are "important" and are hard to upgrade (user facing or customized at each installation) are fully supported until 
> end of support and between EOS and EOL get fixes for bugs that have security implications where publishing the issue and fix to the current release 
> or trunk will give hackers easy access  to data held in the old version or in some way open companies using that version to serious harm.
>
> It may be somewhat difficult to get people to fix older versions but there may be things that we could do to make this more likely.
> 1) Bugs can not be closed until it is fixed in all of the versions to which it must be applied (according to our EOS and EOL rules). It might be 
> better to generate new issue that specifically addresses the patch to be applied rather than a full description of the symptoms of the original 
> problem which is a main feature of the original report and make this new issue a dependency of the original.
> 2) Open a sub-project for the older releases with different committers who are interested in the older version and are not committing to the trunk.
> This might be a way for someone to get started in OFBiz programming.
> The activity in this sub-project would be a good way to judge the community's interest in maintaining the older release. One would expect that 
> companies running the old version would be interested in supporting this sub-project even if they have no interest in the trunk.
>
> Ron
>
>
> On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
>> Inline
>>
>> Le 23/09/2014 09:26, Jacques Le Roux a écrit :
>>>
>>> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>>>
>>>>> <<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.>>
>>>>>
>>>> A more formal rule would be:
>>>> * commits to the trunk from Jira tickets of type Bugs can and *should* be backported to all the active releases
>>> Yes, hopefully we (I mean the really concerned persons) will not have to enforce (ie do it ourselves) the "should" :/
>>>> * commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be 
>>>> backported to a specific active release
>>> Yes it's already like that and those are only rare exceptions, right way for me
>>>>> <<I think we should make that clear and expose a way to users for them to more
>>>>> "easily" maintain the releases they use.>>
>>>> +1 see below
>>>>
>>>>> As suggested Ron we could also define our own or refer to http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>>> Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download 
>>>> page where we already mention a tentative end of life; for example now we have:
>>>>
>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>>
>>>> But when we specify an end of life, we should also make clear a few things:
>>>> * this is a community goal, and the help from the community is required to meet the goal (i.e. it is not guaranteed)
>>> Yes that's an important point indeed. We begin to get traction with (mostly thanks to the bug crush effort so far) and hopefully it will continue :)
>>>> * the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release 
>>>> branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low 
>>>> interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
>>> The point I'd really want to be highlighted/explained is we don't guarantee that old bugs fixed in trunk are backported. Let's face it, we can't 
>>> guarantee that, we have not real means to enforce it.
>>
>> We have still no mention of that in the download page. I recently backported a number of bug fixes done in the last HWM bug crush in R12.04, but I 
>> (nobody I guess) can't guarantee we will always backport all bug fixes in living releases branches. I don't know how other TLP projects do, but it 
>> seems to me that to be correct/honest with our users we need to clarify that. We should even give a mean, or at least a way, to check that by 
>> themselves. By comparing the trunk and releases change logs for instance? I also suggested below
>> <<We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (maybe a link to wiki from 
>> download page to not clutter this main page).
>> I will think about what you wrote above and see how we can inform our our releases users (I mean a process to follow maybe even something more 
>> automated) >>
>>
>> Jacques
>>
>>>>
>>>>> Now we need to think "technical" and automatize as possible with Jira
>>>> In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the 
>>>> information will be more accurate with new releases).
>>>> The idea is to run a query on Jira with the following constraints:
>>>> project = OFBiz
>>>> type = Bug
>>>> status = not resolved
>>>> version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g. 
>>>> "Release 12.04.05")
>>>>
>>>> The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and 
>>>> outstanding.
>>>> For them we will need help from the community (committers and non committers) to fix the bugs or backport existing fixes.
>>>>
>>>> In the download page, we could add two links (to Jira) next to each available release:
>>>> 1) known bugs (links to the above report)
>>>> 2) release notes (link to the release notes available now)
>>>>
>>>> One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version 
>>>> affected" set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add 
>>>> "12.04.06" to affected version).
>>>
>>> This will need a strict observance from committers about versions to fix and fixed. I believe it's indeed the right way, anyway we have no 
>>> others/betters (I mean offered by Jira) .
>>>
>>> We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (maybe a link to wiki from 
>>> download page to not clutter this main page).
>>> I will think about what you wrote above and see how we can inform our our releases users (I mean a process to follow maybe even something more 
>>> automated)
>>>
>>> Jacques
>>>
>>>>
>>>>> What I have read so far from Jacopo seems a good start to me
>>>> Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information 
>>>> when I started the version refactoring in Jira, and this conversation is helping to refine some points.
>>>>
>>>> Jacopo
>>>>
>>>
>>>
>>
>
>

Re: Release Strategy and Branch Support

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

  I think that many projects that are "important" and are hard to 
upgrade (user facing or customized at each installation) are fully 
supported until end of support and between EOS and EOL get fixes for 
bugs that have security implications where publishing the issue and fix 
to the current release or trunk will give hackers easy access  to data 
held in the old version or in some way open companies using that version 
to serious harm.

It may be somewhat difficult to get people to fix older versions but 
there may be things that we could do to make this more likely.
1) Bugs can not be closed until it is fixed in all of the versions to 
which it must be applied (according to our EOS and EOL rules). It might 
be better to generate new issue that specifically addresses the patch to 
be applied rather than a full description of the symptoms of the 
original problem which is a main feature of the original report and make 
this new issue a dependency of the original.
2) Open a sub-project for the older releases with different committers 
who are interested in the older version and are not committing to the trunk.
This might be a way for someone to get started in OFBiz programming.
The activity in this sub-project would be a good way to judge the 
community's interest in maintaining the older release. One would expect 
that companies running the old version would be interested in supporting 
this sub-project even if they have no interest in the trunk.

Ron


On 23/10/2014 8:17 AM, Jacques Le Roux wrote:
> Inline
>
> Le 23/09/2014 09:26, Jacques Le Roux a écrit :
>>
>> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux 
>>> <ja...@les7arts.com> wrote:
>>>
>>>> <<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.>>
>>>>
>>> A more formal rule would be:
>>> * commits to the trunk from Jira tickets of type Bugs can and 
>>> *should* be backported to all the active releases
>> Yes, hopefully we (I mean the really concerned persons) will not have 
>> to enforce (ie do it ourselves) the "should" :/
>>> * commits to the trunk from Jira tickets of type different from Bugs 
>>> need an explicit approval from the committers group before they can 
>>> be backported to a specific active release
>> Yes it's already like that and those are only rare exceptions, right 
>> way for me
>>>> <<I think we should make that clear and expose a way to users for 
>>>> them to more
>>>> "easily" maintain the releases they use.>>
>>> +1 see below
>>>
>>>> As suggested Ron we could also define our own or refer to 
>>>> http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>> Rather than referring to an external site, in my opinion we could 
>>> improve (and make more evident) the information we already have in 
>>> the download page where we already mention a tentative end of life; 
>>> for example now we have:
>>>
>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>
>>> But when we specify an end of life, we should also make clear a few 
>>> things:
>>> * this is a community goal, and the help from the community is 
>>> required to meet the goal (i.e. it is not guaranteed)
>> Yes that's an important point indeed. We begin to get traction with 
>> (mostly thanks to the bug crush effort so far) and hopefully it will 
>> continue :)
>>> * the plan is flexible; for example, if a group of interested users 
>>> will show up today telling us that they want to actively maintain 
>>> the release branch 11.04 even if the scheduled end of life is 
>>> passed, I would not object to it; the opposite is also true: if we 
>>> experience low interest/support (from committers and non committers) 
>>> in maintaining a given release branch we could vote to modify its 
>>> end of life
>> The point I'd really want to be highlighted/explained is we don't 
>> guarantee that old bugs fixed in trunk are backported. Let's face it, 
>> we can't guarantee that, we have not real means to enforce it.
>
> We have still no mention of that in the download page. I recently 
> backported a number of bug fixes done in the last HWM bug crush in 
> R12.04, but I (nobody I guess) can't guarantee we will always backport 
> all bug fixes in living releases branches.  I don't know how other TLP 
> projects do, but it seems to me that to be correct/honest with our 
> users we need to clarify that. We should even give a mean, or at least 
> a way, to check that by themselves. By comparing the trunk and 
> releases change logs for instance? I also suggested below
> <<We should then explain to our releases users how they can use the 
> Jira changes logs to check and amend what they use (maybe a link to 
> wiki from download page to not clutter this main page).
> I will think about what you wrote above and see how we can inform our 
> our releases users (I mean a process to follow maybe even something 
> more automated) >>
>
> Jacques
>
>>>
>>>> Now we need to think "technical" and automatize as possible with Jira
>>> In my opinion it is possible to easily derive this from Jira, after 
>>> the version configuration refactoring I did a few weeks ago (however 
>>> the information will be more accurate with new releases).
>>> The idea is to run a query on Jira with the following constraints:
>>> project = OFBiz
>>> type = Bug
>>> status = not resolved
>>> version *affected* = the release branch we are interested in (e.g. 
>>> "release branch 12.04" OR the current latest release in the same 
>>> branch (e.g. "Release 12.04.05")
>>>
>>> The result should be a list of bugs affecting the release branch 
>>> and/or the latest release in that branch; these are the bugs that 
>>> are known and outstanding.
>>> For them we will need help from the community (committers and non 
>>> committers) to fix the bugs or backport existing fixes.
>>>
>>> In the download page, we could add two links (to Jira) next to each 
>>> available release:
>>> 1) known bugs (links to the above report)
>>> 2) release notes (link to the release notes available now)
>>>
>>> One technicality is the following: when we release a new release 
>>> from the branch (e.g. 12.04.06), if there are open tickets with 
>>> "version affected" set to the current version (e.g. 12.04.05) then 
>>> we will have to bulk update all of them by adding also the new 
>>> version (e.g. add "12.04.06" to affected version).
>>
>> This will need a strict observance from committers about versions to 
>> fix and fixed. I believe it's indeed the right way, anyway we have no 
>> others/betters (I mean offered by Jira) .
>>
>> We should then explain to our releases users how they can use the 
>> Jira changes logs to check and amend what they use (maybe a link to 
>> wiki from download page to not clutter this main page).
>> I will think about what you wrote above and see how we can inform our 
>> our releases users (I mean a process to follow maybe even something 
>> more automated)
>>
>> Jacques
>>
>>>
>>>> What I have read so far from Jacopo seems a good start to me
>>> Thank you for confirming that we are on the same page. This is 
>>> actually part of the plan I had in mind to maintain better release 
>>> information when I started the version refactoring in Jira, and this 
>>> conversation is helping to refine some points.
>>>
>>> Jacopo
>>>
>>
>>
>


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

Re: Release Strategy and Branch Support (was: Re: Bug Crush)

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

Inline

Le 23/09/2014 09:26, Jacques Le Roux a écrit :
>
> Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>
>>> <<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.>>
>>>
>> A more formal rule would be:
>> * commits to the trunk from Jira tickets of type Bugs can and *should* be backported to all the active releases
> Yes, hopefully we (I mean the really concerned persons) will not have to enforce (ie do it ourselves) the "should" :/
>> * commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be 
>> backported to a specific active release
> Yes it's already like that and those are only rare exceptions, right way for me
>>> <<I think we should make that clear and expose a way to users for them to more
>>> "easily" maintain the releases they use.>>
>> +1 see below
>>
>>> As suggested Ron we could also define our own or refer to http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>> Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download 
>> page where we already mention a tentative end of life; for example now we have:
>>
>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>
>> But when we specify an end of life, we should also make clear a few things:
>> * this is a community goal, and the help from the community is required to meet the goal (i.e. it is not guaranteed)
> Yes that's an important point indeed. We begin to get traction with (mostly thanks to the bug crush effort so far) and hopefully it will continue :)
>> * the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release 
>> branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low 
>> interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
> The point I'd really want to be highlighted/explained is we don't guarantee that old bugs fixed in trunk are backported. Let's face it, we can't 
> guarantee that, we have not real means to enforce it.

We have still no mention of that in the download page. I recently backported a number of bug fixes done in the last HWM bug crush in R12.04, but I 
(nobody I guess) can't guarantee we will always backport all bug fixes in living releases branches.  I don't know how other TLP projects do, but it 
seems to me that to be correct/honest with our users we need to clarify that. We should even give a mean, or at least a way, to check that by 
themselves. By comparing the trunk and releases change logs for instance? I also suggested below
<<We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (maybe a link to wiki from 
download page to not clutter this main page).
I will think about what you wrote above and see how we can inform our our releases users (I mean a process to follow maybe even something more 
automated) >>

Jacques

>>
>>> Now we need to think "technical" and automatize as possible with Jira
>> In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the 
>> information will be more accurate with new releases).
>> The idea is to run a query on Jira with the following constraints:
>> project = OFBiz
>> type = Bug
>> status = not resolved
>> version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g. 
>> "Release 12.04.05")
>>
>> The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and 
>> outstanding.
>> For them we will need help from the community (committers and non committers) to fix the bugs or backport existing fixes.
>>
>> In the download page, we could add two links (to Jira) next to each available release:
>> 1) known bugs (links to the above report)
>> 2) release notes (link to the release notes available now)
>>
>> One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version affected" 
>> set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add "12.04.06" to 
>> affected version).
>
> This will need a strict observance from committers about versions to fix and fixed. I believe it's indeed the right way, anyway we have no 
> others/betters (I mean offered by Jira) .
>
> We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (maybe a link to wiki from 
> download page to not clutter this main page).
> I will think about what you wrote above and see how we can inform our our releases users (I mean a process to follow maybe even something more 
> automated)
>
> Jacques
>
>>
>>> What I have read so far from Jacopo seems a good start to me
>> Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information when 
>> I started the version refactoring in Jira, and this conversation is helping to refine some points.
>>
>> Jacopo
>>
>
>

Re: Release Strategy and Branch Support (was: Re: Bug Crush)

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

Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>> <<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.>>
>>
> A more formal rule would be:
> * commits to the trunk from Jira tickets of type Bugs can and *should* be backported to all the active releases
Yes, hopefully we (I mean the really concerned persons) will not have to enforce (ie do it ourselves) the "should" :/
> * commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be backported to a specific active release
Yes it's already like that and those are only rare exceptions, right way for me
>> <<I think we should make that clear and expose a way to users for them to more
>> "easily" maintain the releases they use.>>
> +1 see below
>
>> As suggested Ron we could also define our own or refer to http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
> Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download page where we already mention a tentative end of life; for example now we have:
>
> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>
> But when we specify an end of life, we should also make clear a few things:
> * this is a community goal, and the help from the community is required to meet the goal (i.e. it is not guaranteed)
Yes that's an important point indeed. We begin to get traction with (mostly thanks to the bug crush effort so far) and hopefully it will continue :)
> * the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
The point I'd really want to be highlighted/explained is we don't guarantee that old bugs fixed in trunk are backported. Let's face it, we can't 
guarantee that, we have not real means to enforce it.
>
>> Now we need to think "technical" and automatize as possible with Jira
> In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the information will be more accurate with new releases).
> The idea is to run a query on Jira with the following constraints:
> project = OFBiz
> type = Bug
> status = not resolved
> version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g. "Release 12.04.05")
>
> The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and outstanding.
> For them we will need help from the community (committers and non committers) to fix the bugs or backport existing fixes.
>
> In the download page, we could add two links (to Jira) next to each available release:
> 1) known bugs (links to the above report)
> 2) release notes (link to the release notes available now)
>
> One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version affected" set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add "12.04.06" to affected version).

This will need a strict observance from committers about versions to fix and fixed. I believe it's indeed the right way, anyway we have no 
others/betters (I mean offered by Jira) .

We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (maybe a link to wiki from 
download page to not clutter this main page).
I will think about what you wrote above and see how we can inform our our releases users (I mean a process to follow maybe even something more automated)

Jacques

>
>> What I have read so far from Jacopo seems a good start to me
> Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information when I started the version refactoring in Jira, and this conversation is helping to refine some points.
>
> Jacopo
>

Re: Release Strategy and Branch Support

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

Ron, I will be brief about this one. I think somebody already kinda answered about the PMC role in another thread.

For me, and it's a widely shared view at the ASF, the PMC roles should be very limited. We should, as much as possible, open discussion to the community.
Voting for new committers, PMC member and discussing about vulnerabilities are a few which can't obviously be open, but the others should (I missed 
some?).

Despite its name the Project Management Committee is not "managing" the project, it's more a shepherd.
So don't expect the PMC to lead the project, it's not its role. Everybody can start something, but then better to be sure you will support this thing...
To start something the best place is this dev ML

You said
 >I think that some of the participants underestimate the strength of a well-run open source project in attracting good people and getting great 
effort from volunteers.
You're absolutely right, the recent rejuvenation of the project shows it!

Jacques

Le 24/09/2014 17:21, Ron Wheeler a écrit :
> Good points.
>
> What I see as missing in the on-going discussion, is an understanding of the role of leadership in consensus building.
>
> There has been a bit of talk about "forcing" and "enforcement".
> The PMC needs to meet regularly to agree on policies and plans that everyone in the PMC thinks is the best way to run the project and produce a high 
> quality product in which users will be comfortable to invest.
>
> Once the memebers of the PMC and the contributors agree on a plan that involves work, the expectation, in an open source project, is that the team 
> members will take on the tasks that need to be done.
> Clearly, some people will have changes in their ordinary workload that prevents them from living up to their agreed commitment and you have to hope 
> that they have enough professionalism to help turn over their tasks to others and that others will step up to take on the tasks.
> People who routinely fail to do the tasks to which  they have committed during the planning phase will drift down the meritocracy.
> Those who step up to perform extra tasks will move up the ladder.
> Companies who require the release may also step up to the plate if the PMC needs additional resources and makes this known.
>
> As many have pointed out, the PMC does not have the traditional management tool of the "Goldern Rule" but this is not a very effective tool in a 
> world where most of your staff can get a pretty good increase in gold by switching jobs.
> The chair of the PMC and the senior "executives" are restricted to concepts like leadership, recognition, mutual respect and the other more 
> effective tools that good managers use in any company that is successful in software development and is able to retain staff.
>
> I think that some of the participants underestimate the strength of a well-run open source project in attracting good people and getting great 
> effort from volunteers.
> Certainly the recent Bug Crush is an impressive display of people and companies being willing to step up to the plate to complete a well-defined and 
> well-communicated task.
>
> The PMC needs to be very transparent about decisions that affect the community.
> To me, important ones are functionality roadmap changes, release roadmap changes, resource requirements and the intermediate term product vision.
>
> The PMC should be meeting to discuss important proposed code changes (framework API changes, major functionality, whatever the PMC thinks is 
> appropriate).
> The proponents should present their case in a way that covers the major issues that will affect the PMC and the product such as integration, 
> features, technology base, maintenance load, etc.
> The PMC and the proposing team should agree on a target release with some deadlines which the proposing team must achieve in order to be included in 
> the target release.
> A written policy and process would probably be helpful.
> Community involvement in the process needs to be focused on key issues and marketing issues in general.
>
> This is just a suggestion about how I would handle this
> The PMC can do what it wants but it needs to be transparent about the process so people don't waste a lot of time and get pissed off at last minute 
> rejection of their ideas.
> They should know ASAP how the PMC views their idea - great for inclusion into the core functionality, could be official OFBiz extension, is more 
> suitable as private extension that the PMC will not warranty, bad idea that would not integrate well with OFBiz for business or technical reasons, etc.
>
> The PMC and community should also clearly understand and dispassionately discuss the projected increase in complexity (dev and user), risk of 
> reduction of reliability, increased cost of on-going maintenance, strength of the team making the proposal for on-going maintenance, delay this 
> would cause in getting a release delivered, etc.
>
> I hope that these ideas help.
>
> Ron
>
> On 23/09/2014 5:26 PM, Jacques Le Roux wrote:
>> Hi Ron,
>>
>> You suggestions are often great, let's see now if the users community if sufficiently interested to help the OFBiz de team in achieving all this....
>>
>> Remember that the Apache way is more about flexiliby and lazy consensus[1]... In other words, as volunteers, we must adapt are the daily reality we 
>> all face...
>>
>> For the sake of OFBiz history, I must say that, not all but at least a good part of the applications at least, has been built in a process of 
>> agglomeration. Contributors (committers or not) work for a client, or their own needs, and decide to give their work to the community. If the 
>> quality is correct and the work is worth it, it's integrated by a committer (with the help of all volunteers). It's not the PMC nor any other group 
>> which really decides of what should be there or not. It's more individual decisions, filtered of course by everybody for the benefit of the 
>> community. Anyone can raise a hand and say his word, that's how it works actually, and it seems you are already aware of that :)
>>
>> I don't say we can't improve, but I doubt that more rules (enforced? how?) would help.
>>
>> For instance, sometimes I even wonder about this page https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
>> Even if I still think it's helpful, is it not a bit frightening for a new comers (it's just an exampled not really a question ;)
>>
>> More answers inline...
>>
>> Jacques
>> [1] http://www.apache.org/foundation/voting.html#LazyConsensus
>>
>> Le 23/09/2014 07:40, Ron Wheeler a écrit :
>>> I think that having a discussion about the policy followed by regular (annual or semi-annual) discussions on the roadmap with the PMC and the user 
>>> community will have a couple of effects
>>> - fewer surprises caused by users showing up at the last minute with requests to extend the EOL or EOS (End-Of-Sales->no longer on the download 
>>> page and no longer recommended for new uers) dates.
>>> - more commitment from the user community to help with maintenance or to support sub-projects financially or with resources.
>>>
>>>
>>> I have not been here long enough to know how the PMC decides on what features will be in a new release or how investigation of new sub-projects 
>>> such as the Workflow project, get accepted as "good" ideas or rejected as "out-of-scope" or insufficiently supported by the community.
>>> Is there a formal procedure that I would have to follow to get my favorite feature included in 14.XX??
>> Nope as barely explained above
>>>
>>> How does the PMC close off the 14.XX spec?
>> When it's ready :D By lazy consensus (anybody can raises a hand, but he must be in tune with what happens)
>>> I assume that there is a process that involves the PMS and contributors who will be providing the resources and the user-community that determines 
>>> the pluses and minuses of the proposed change.
>> Nope, we try to avoid "'paper work" as much as possible
>>>
>>> What are the current new features that are being considered for the 2014.XX feature freeze?
>>> Is this discussion documented somewhere?
>> Nope, but Jira can give you more than a hint 
>> https://issues.apache.org/jira/browse/OFBIZ/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel
>> This the way we are recently going and it's a huge progress in comparison of what we had before (almost nothing and despite you see: OFBiz is there)
>>>
>>> The people doing the investigation of the Workflow  engine presumably need to know when they have to get their proposal finished to make it into 
>>> the 2014 feature freeze.
>> Obviously, this does not depend on us (OFBiz dev team) but them (to be ready and ask to wait if necessary)
>>>
>>> Are their guidelines about how the form and content of this proposal (features, dependent software , integration issues, resources required, 
>>> estimated time to deliver)?
>> Nope, would you suggest something?
>>
>> Jacques
>>>
>>> Ron
>>>
>>>
>>> On 23/09/2014 12:35 AM, Jacopo Cappellato wrote:
>>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>>>
>>>>> <<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.>>
>>>>>
>>>> A more formal rule would be:
>>>> * commits to the trunk from Jira tickets of type Bugs can and *should* be backported to all the active releases
>>>> * commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be 
>>>> backported to a specific active release
>>>>
>>>>> <<I think we should make that clear and expose a way to users for them to more
>>>>> "easily" maintain the releases they use.>>
>>>> +1 see below
>>>>
>>>>> As suggested Ron we could also define our own or refer to http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>>> Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download 
>>>> page where we already mention a tentative end of life; for example now we have:
>>>>
>>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>>
>>>> But when we specify an end of life, we should also make clear a few things:
>>>> * this is a community goal, and the help from the community is required to meet the goal (i.e. it is not guaranteed)
>>>> * the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release 
>>>> branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low 
>>>> interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
>>>>
>>>>> Now we need to think "technical" and automatize as possible with Jira
>>>> In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the 
>>>> information will be more accurate with new releases).
>>>> The idea is to run a query on Jira with the following constraints:
>>>> project = OFBiz
>>>> type = Bug
>>>> status = not resolved
>>>> version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g. 
>>>> "Release 12.04.05")
>>>>
>>>> The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and 
>>>> outstanding.
>>>> For them we will need help from the community (committers and non committers) to fix the bugs or backport existing fixes.
>>>>
>>>> In the download page, we could add two links (to Jira) next to each available release:
>>>> 1) known bugs (links to the above report)
>>>> 2) release notes (link to the release notes available now)
>>>>
>>>> One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version 
>>>> affected" set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add 
>>>> "12.04.06" to affected version).
>>>>
>>>>> What I have read so far from Jacopo seems a good start to me
>>>> Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information 
>>>> when I started the version refactoring in Jira, and this conversation is helping to refine some points.
>>>>
>>>> Jacopo
>>>
>>>
>>
>
>

Re: Release Strategy and Branch Support

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

Good points.

What I see as missing in the on-going discussion, is an understanding of 
the role of leadership in consensus building.

There has been a bit of talk about "forcing" and "enforcement".
The PMC needs to meet regularly to agree on policies and plans that 
everyone in the PMC thinks is the best way to run the project and 
produce a high quality product in which users will be comfortable to invest.

Once the memebers of the PMC and the contributors agree on a plan that 
involves work, the expectation, in an open source project, is that the 
team members will take on the tasks that need to be done.
Clearly, some people will have changes in their ordinary workload that 
prevents them from living up to their agreed commitment and you have to 
hope that they have enough professionalism to help turn over their tasks 
to others and that others will step up to take on the tasks.
People who routinely fail to do the tasks to which  they have committed 
during the planning phase will drift down the meritocracy.
Those who step up to perform extra tasks will move up the ladder.
Companies who require the release may also step up to the plate if the 
PMC needs additional resources and makes this known.

As many have pointed out, the PMC does not have the traditional 
management tool of the "Goldern Rule" but this is not a very effective 
tool in a world where most of your staff can get a pretty good increase 
in gold by switching jobs.
The chair of the PMC and the senior "executives" are restricted to 
concepts like leadership, recognition, mutual respect and the other more 
effective tools that good managers use in any company that is successful 
in software development and is able to retain staff.

I think that some of the participants underestimate the strength of a 
well-run open source project in attracting good people and getting great 
effort from volunteers.
Certainly the recent Bug Crush is an impressive display of people and 
companies being willing to step up to the plate to complete a 
well-defined and well-communicated task.

The PMC needs to be very transparent about decisions that affect the 
community.
To me, important ones are functionality roadmap changes, release roadmap 
changes, resource requirements and the intermediate term product vision.

The PMC should be meeting to discuss important proposed code changes 
(framework API changes, major functionality, whatever the PMC thinks is 
appropriate).
The proponents should present their case in a way that covers the major 
issues that will affect the PMC and the product such as integration, 
features, technology base, maintenance load, etc.
The PMC and the proposing team should agree on a target release with 
some deadlines which the proposing team must achieve in order to be 
included in the target release.
A written policy and process would probably be helpful.
Community involvement in the process needs to be focused on key issues 
and marketing issues in general.

This is just a suggestion about how I would handle this
The PMC can do what it wants but it needs to be transparent about the 
process so people don't waste a lot of time and get pissed off at last 
minute rejection of their ideas.
They should know ASAP how the PMC views their idea - great for inclusion 
into the core functionality, could be official OFBiz extension, is more 
suitable as private extension that the PMC will not warranty, bad idea 
that would not integrate well with OFBiz for business or technical 
reasons, etc.

The PMC and community should also clearly understand and dispassionately 
discuss the projected increase in complexity (dev and user), risk of 
reduction of reliability, increased cost of on-going maintenance, 
strength of the team making the proposal for on-going maintenance, delay 
this would cause in getting a release delivered, etc.

I hope that these ideas help.

Ron

On 23/09/2014 5:26 PM, Jacques Le Roux wrote:
> Hi Ron,
>
> You suggestions are often great, let's see now if the users community 
> if sufficiently interested to help the OFBiz de team in achieving all 
> this....
>
> Remember that the Apache way is more about flexiliby and lazy 
> consensus[1]... In other words, as volunteers, we must adapt are the 
> daily reality we all face...
>
> For the sake of OFBiz history, I must say that, not all but at least a 
> good part of the applications at least, has been built in a process of 
> agglomeration. Contributors (committers or not) work for a client, or 
> their own needs, and decide to give their work to the community. If 
> the quality is correct and the work is worth it, it's integrated by a 
> committer (with the help of all volunteers). It's not the PMC nor any 
> other group which really decides of what should be there or not. It's 
> more individual decisions, filtered of course by everybody for the 
> benefit of the community. Anyone can raise a hand and say his word, 
> that's how it works actually, and it seems you are already aware of 
> that :)
>
> I don't say we can't improve, but I doubt that more rules (enforced? 
> how?) would help.
>
> For instance, sometimes I even wonder about this page 
> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
> Even if I still think it's helpful, is it not a bit frightening for a 
> new comers (it's just an exampled not really a question ;)
>
> More answers inline...
>
> Jacques
> [1] http://www.apache.org/foundation/voting.html#LazyConsensus
>
> Le 23/09/2014 07:40, Ron Wheeler a écrit :
>> I think that having a discussion about the policy followed by regular 
>> (annual or semi-annual) discussions on the roadmap with the PMC and 
>> the user community will have a couple of effects
>> - fewer surprises caused by users showing up at the last minute with 
>> requests to extend the EOL or EOS (End-Of-Sales->no longer on the 
>> download page and no longer recommended for new uers) dates.
>> - more commitment from the user community to help with maintenance or 
>> to support sub-projects financially or with resources.
>>
>>
>> I have not been here long enough to know how the PMC decides on what 
>> features will be in a new release or how investigation of new 
>> sub-projects such as the Workflow project, get accepted as "good" 
>> ideas or rejected as "out-of-scope" or insufficiently supported by 
>> the community.
>> Is there a formal procedure that I would have to follow to get my 
>> favorite feature included in 14.XX??
> Nope as barely explained above
>>
>> How does the PMC close off the 14.XX spec?
> When it's ready :D By lazy consensus (anybody can raises a hand, but 
> he must be in tune with what happens)
>> I assume that there is a process that involves the PMS and 
>> contributors who will be providing the resources and the 
>> user-community that determines the pluses and minuses of the proposed 
>> change.
> Nope, we try to avoid "'paper work" as much as possible
>>
>> What are the current new features that are being considered for the 
>> 2014.XX feature freeze?
>> Is this discussion documented somewhere?
> Nope, but Jira can give you more than a hint 
> https://issues.apache.org/jira/browse/OFBIZ/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel
> This the way we are recently going and it's a huge progress in 
> comparison of what we had before (almost nothing and despite you see: 
> OFBiz is there)
>>
>> The people doing the investigation of the Workflow  engine presumably 
>> need to know when they have to get their proposal finished to make it 
>> into the 2014 feature freeze.
> Obviously, this does not depend on us (OFBiz dev team) but them (to be 
> ready and ask to wait if necessary)
>>
>> Are their guidelines about how the form and content of this proposal 
>> (features, dependent software , integration issues, resources 
>> required, estimated time to deliver)?
> Nope, would you suggest something?
>
> Jacques
>>
>> Ron
>>
>>
>> On 23/09/2014 12:35 AM, Jacopo Cappellato wrote:
>>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux 
>>> <ja...@les7arts.com> wrote:
>>>
>>>> <<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.>>
>>>>
>>> A more formal rule would be:
>>> * commits to the trunk from Jira tickets of type Bugs can and 
>>> *should* be backported to all the active releases
>>> * commits to the trunk from Jira tickets of type different from Bugs 
>>> need an explicit approval from the committers group before they can 
>>> be backported to a specific active release
>>>
>>>> <<I think we should make that clear and expose a way to users for 
>>>> them to more
>>>> "easily" maintain the releases they use.>>
>>> +1 see below
>>>
>>>> As suggested Ron we could also define our own or refer to 
>>>> http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>>> Rather than referring to an external site, in my opinion we could 
>>> improve (and make more evident) the information we already have in 
>>> the download page where we already mention a tentative end of life; 
>>> for example now we have:
>>>
>>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>>
>>> But when we specify an end of life, we should also make clear a few 
>>> things:
>>> * this is a community goal, and the help from the community is 
>>> required to meet the goal (i.e. it is not guaranteed)
>>> * the plan is flexible; for example, if a group of interested users 
>>> will show up today telling us that they want to actively maintain 
>>> the release branch 11.04 even if the scheduled end of life is 
>>> passed, I would not object to it; the opposite is also true: if we 
>>> experience low interest/support (from committers and non committers) 
>>> in maintaining a given release branch we could vote to modify its 
>>> end of life
>>>
>>>> Now we need to think "technical" and automatize as possible with Jira
>>> In my opinion it is possible to easily derive this from Jira, after 
>>> the version configuration refactoring I did a few weeks ago (however 
>>> the information will be more accurate with new releases).
>>> The idea is to run a query on Jira with the following constraints:
>>> project = OFBiz
>>> type = Bug
>>> status = not resolved
>>> version *affected* = the release branch we are interested in (e.g. 
>>> "release branch 12.04" OR the current latest release in the same 
>>> branch (e.g. "Release 12.04.05")
>>>
>>> The result should be a list of bugs affecting the release branch 
>>> and/or the latest release in that branch; these are the bugs that 
>>> are known and outstanding.
>>> For them we will need help from the community (committers and non 
>>> committers) to fix the bugs or backport existing fixes.
>>>
>>> In the download page, we could add two links (to Jira) next to each 
>>> available release:
>>> 1) known bugs (links to the above report)
>>> 2) release notes (link to the release notes available now)
>>>
>>> One technicality is the following: when we release a new release 
>>> from the branch (e.g. 12.04.06), if there are open tickets with 
>>> "version affected" set to the current version (e.g. 12.04.05) then 
>>> we will have to bulk update all of them by adding also the new 
>>> version (e.g. add "12.04.06" to affected version).
>>>
>>>> What I have read so far from Jacopo seems a good start to me
>>> Thank you for confirming that we are on the same page. This is 
>>> actually part of the plan I had in mind to maintain better release 
>>> information when I started the version refactoring in Jira, and this 
>>> conversation is helping to refine some points.
>>>
>>> Jacopo
>>
>>
>


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

Re: Release Strategy and Branch Support

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

Hi Ron,

You suggestions are often great, let's see now if the users community if sufficiently interested to help the OFBiz de team in achieving all this....

Remember that the Apache way is more about flexiliby and lazy consensus[1]... In other words, as volunteers, we must adapt are the daily reality we 
all face...

For the sake of OFBiz history, I must say that, not all but at least a good part of the applications at least, has been built in a process of 
agglomeration. Contributors (committers or not) work for a client, or their own needs, and decide to give their work to the community. If the quality 
is correct and the work is worth it, it's integrated by a committer (with the help of all volunteers). It's not the PMC nor any other group which 
really decides of what should be there or not. It's more individual decisions, filtered of course by everybody for the benefit of the community. 
Anyone can raise a hand and say his word, that's how it works actually, and it seems you are already aware of that :)

I don't say we can't improve, but I doubt that more rules (enforced? how?) would help.

For instance, sometimes I even wonder about this page https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
Even if I still think it's helpful, is it not a bit frightening for a new comers (it's just an exampled not really a question ;)

More answers inline...

Jacques
[1] http://www.apache.org/foundation/voting.html#LazyConsensus

Le 23/09/2014 07:40, Ron Wheeler a écrit :
> I think that having a discussion about the policy followed by regular (annual or semi-annual) discussions on the roadmap with the PMC and the user 
> community will have a couple of effects
> - fewer surprises caused by users showing up at the last minute with requests to extend the EOL or EOS (End-Of-Sales->no longer on the download page 
> and no longer recommended for new uers) dates.
> - more commitment from the user community to help with maintenance or to support sub-projects financially or with resources.
>
>
> I have not been here long enough to know how the PMC decides on what features will be in a new release or how investigation of new sub-projects such 
> as the Workflow project, get accepted as "good" ideas or rejected as "out-of-scope" or insufficiently supported by the community.
> Is there a formal procedure that I would have to follow to get my favorite feature included in 14.XX??
Nope as barely explained above
>
> How does the PMC close off the 14.XX spec?
When it's ready :D By lazy consensus (anybody can raises a hand, but he must be in tune with what happens)
> I assume that there is a process that involves the PMS and contributors who will be providing the resources and the user-community that determines 
> the pluses and minuses of the proposed change.
Nope, we try to avoid "'paper work" as much as possible
>
> What are the current new features that are being considered for the 2014.XX feature freeze?
> Is this discussion documented somewhere?
Nope, but Jira can give you more than a hint 
https://issues.apache.org/jira/browse/OFBIZ/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel
This the way we are recently going and it's a huge progress in comparison of what we had before (almost nothing and despite you see: OFBiz is there)
>
> The people doing the investigation of the Workflow  engine presumably need to know when they have to get their proposal finished to make it into the 
> 2014 feature freeze.
Obviously, this does not depend on us (OFBiz dev team) but them (to be ready and ask to wait if necessary)
>
> Are their guidelines about how the form and content of this proposal (features, dependent software , integration issues, resources required, 
> estimated time to deliver)?
Nope, would you suggest something?

Jacques
>
> Ron
>
>
> On 23/09/2014 12:35 AM, Jacopo Cappellato wrote:
>> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>
>>> <<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.>>
>>>
>> A more formal rule would be:
>> * commits to the trunk from Jira tickets of type Bugs can and *should* be backported to all the active releases
>> * commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be 
>> backported to a specific active release
>>
>>> <<I think we should make that clear and expose a way to users for them to more
>>> "easily" maintain the releases they use.>>
>> +1 see below
>>
>>> As suggested Ron we could also define our own or refer to http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>> Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download 
>> page where we already mention a tentative end of life; for example now we have:
>>
>> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>>
>> But when we specify an end of life, we should also make clear a few things:
>> * this is a community goal, and the help from the community is required to meet the goal (i.e. it is not guaranteed)
>> * the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release 
>> branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low 
>> interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
>>
>>> Now we need to think "technical" and automatize as possible with Jira
>> In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the 
>> information will be more accurate with new releases).
>> The idea is to run a query on Jira with the following constraints:
>> project = OFBiz
>> type = Bug
>> status = not resolved
>> version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g. 
>> "Release 12.04.05")
>>
>> The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and 
>> outstanding.
>> For them we will need help from the community (committers and non committers) to fix the bugs or backport existing fixes.
>>
>> In the download page, we could add two links (to Jira) next to each available release:
>> 1) known bugs (links to the above report)
>> 2) release notes (link to the release notes available now)
>>
>> One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version affected" 
>> set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add "12.04.06" to 
>> affected version).
>>
>>> What I have read so far from Jacopo seems a good start to me
>> Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information when 
>> I started the version refactoring in Jira, and this conversation is helping to refine some points.
>>
>> Jacopo
>
>

Re: Release Strategy and Branch Support

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

I think that having a discussion about the policy followed by regular 
(annual or semi-annual) discussions on the roadmap with the PMC and the 
user community will have a couple of effects
- fewer surprises caused by users showing up at the last minute with 
requests to extend the EOL or EOS (End-Of-Sales->no longer on the 
download page and no longer recommended for new uers) dates.
- more commitment from the user community to help with maintenance or to 
support sub-projects financially or with resources.


I have not been here long enough to know how the PMC decides on what 
features will be in a new release or how investigation of new 
sub-projects such as the Workflow project, get accepted as "good" ideas 
or rejected as "out-of-scope" or insufficiently supported by the community.
Is there a formal procedure that I would have to follow to get my 
favorite feature included in 14.XX??

How does the PMC close off the 14.XX spec?
I assume that there is a process that involves the PMS and contributors 
who will be providing the resources and the user-community that 
determines the pluses and minuses of the proposed change.

What are the current new features that are being considered for the 
2014.XX feature freeze?
Is this discussion documented somewhere?

The people doing the investigation of the Workflow  engine presumably 
need to know when they have to get their proposal finished to make it 
into the 2014 feature freeze.

Are their guidelines about how the form and content of this proposal 
(features, dependent software , integration issues, resources required, 
estimated time to deliver)?

Ron


On 23/09/2014 12:35 AM, Jacopo Cappellato wrote:
> On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>> <<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.>>
>>
> A more formal rule would be:
> * commits to the trunk from Jira tickets of type Bugs can and *should* be backported to all the active releases
> * commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be backported to a specific active release
>
>> <<I think we should make that clear and expose a way to users for them to more
>> "easily" maintain the releases they use.>>
> +1 see below
>
>> As suggested Ron we could also define our own or refer to http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
> Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download page where we already mention a tentative end of life; for example now we have:
>
> • April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)
>
> But when we specify an end of life, we should also make clear a few things:
> * this is a community goal, and the help from the community is required to meet the goal (i.e. it is not guaranteed)
> * the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
>
>> Now we need to think "technical" and automatize as possible with Jira
> In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the information will be more accurate with new releases).
> The idea is to run a query on Jira with the following constraints:
> project = OFBiz
> type = Bug
> status = not resolved
> version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g. "Release 12.04.05")
>
> The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and outstanding.
> For them we will need help from the community (committers and non committers) to fix the bugs or backport existing fixes.
>
> In the download page, we could add two links (to Jira) next to each available release:
> 1) known bugs (links to the above report)
> 2) release notes (link to the release notes available now)
>
> One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version affected" set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add "12.04.06" to affected version).
>
>> What I have read so far from Jacopo seems a good start to me
> Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information when I started the version refactoring in Jira, and this conversation is helping to refine some points.
>
> Jacopo


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

Re: Release Strategy and Branch Support (was: Re: Bug Crush)

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

On Sep 22, 2014, at 9:58 PM, Jacques Le Roux <ja...@les7arts.com> wrote:

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

A more formal rule would be:
* commits to the trunk from Jira tickets of type Bugs can and *should* be backported to all the active releases
* commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be backported to a specific active release

> <<I think we should make that clear and expose a way to users for them to more
> "easily" maintain the releases they use.>>

+1 see below

> 
> As suggested Ron we could also define our own or refer to http://en.wikipedia.org/wiki/End-of-life_%28product%29 and

Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download page where we already mention a tentative end of life; for example now we have:

• April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)

But when we specify an end of life, we should also make clear a few things:
* this is a community goal, and the help from the community is required to meet the goal (i.e. it is not guaranteed)
* the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life

> 
> Now we need to think "technical" and automatize as possible with Jira

In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the information will be more accurate with new releases).
The idea is to run a query on Jira with the following constraints:
project = OFBiz
type = Bug
status = not resolved
version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g. "Release 12.04.05")

The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and outstanding.
For them we will need help from the community (committers and non committers) to fix the bugs or backport existing fixes.

In the download page, we could add two links (to Jira) next to each available release:
1) known bugs (links to the above report)
2) release notes (link to the release notes available now)

One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version affected" set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add "12.04.06" to affected version).

> What I have read so far from Jacopo seems a good start to me

Thank you for confirming that we are on the same page. This is actually part of the plan I had in mind to maintain better release information when I started the version refactoring in Jira, and this conversation is helping to refine some points.

Jacopo

Re: Release Strategy and Branch Support

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

I don't think that we are a long way off having a clear statement of policy.
The PMC needs to meet on this and hash out the policy in a general way 
and then apply this to 11.04, 12.04 and 13.07.

The PMC may feel the need to draw in more users and contributors into 
the discussion.
The current vagueness about the intentions of the team about the future 
makes it hard for anyone to adopt OFBiz as an end-user product.

The Integrators may not feel this is an issue for their customers since 
they probably have internal policies about their EOL intentions that 
they can communicate to their clients to give a clear picture about when 
the client will be forced to face a future upgrade.

Once the team decides that 12.04  (current release) will only get 
security fixes after Dec 2014??? and will not get any fixes after Dec 
2015???,  then everyone running 12.04 will know that they have a project 
to budget in 2015.
If you decide that 13.07 will be supported until Dec 2017???, then 
system managers/IT managers will know that their initial implementation 
is protected until that date.

The team will know which issues to create in the JIRA each time a 
problem is identified and know what work has to be done in order to 
properly support the community.

As Adrian points out, no one individual contributor can be forced to fix 
any particular bug but their will be some peer pressure to maintain 
one's "merit" reputation by fixing related bugs or at least documenting 
the fix in one release so that someone else can fix it in another.

It may be that people will actually want to help out on fixing 12.04 by 
porting the bugs fixed in 13.07 if they are actually running it.

It may also be a good way for new contributors to learn the framework 
and code by backporting bug fixes.
Probably more relevant for porting trunk fixes back to 13.07 once 13.07 
actually becomes the official stable release rather than the defacto 
stable release.

Ron

On 22/09/2014 3:58 PM, Jacques Le Roux wrote:
> OK I began this convo. Inline...
>
> Le 22/09/2014 21:15, Jacopo Cappellato a écrit :
>> We are maintaining somewhat similar information in these pages:
>>
>> http://ofbiz.apache.org/download.html
>
> This is where we should be more specific and explain things better as 
> I kinda suggested in one of my message 
> http://markmail.org/message/pos2gnyj47uxsn5s
> Excerpts:
> <<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 think we should make that clear and expose a way to users for them 
> to more
> "easily" maintain the releases they use.>>
>
> As suggested Ron we could also define our own or refer to 
> http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
>
> Now we need to think "technical" and automatize as possible with Jira
> What I have read so far from Jacopo seems a good start to me
>
> Jacques
>
>> http://www.apache.org/dist/ofbiz/
>>
>> Jacopo
>>
>> On Sep 22, 2014, at 8:31 PM, Ron Wheeler 
>> <rw...@artifact-software.com> wrote:
>>
>>> Here are some examples of End Of Life policy statements for open 
>>> source products.
>>>
>>> http://wiki.centos.org/About/Product
>>> http://tomcat.apache.org/tomcat-55-eol.html
>>> http://www.openoffice.org/development/releases/eol.html
>>>
>>>
>>> http://support.rightscale.com/15-References/End_of_Support_and_End_of_Life_Schedule 
>>> is a very nice presentation of EOS and EOL dates with definitions.
>>>
>>> Perhaps the PMC can take up this issue and settle what they want to 
>>> offer as a "warranty" to users who download a version or have a 
>>> version installed and are making their upgrade and security 
>>> calculations for their ERP.
>>>
>>>
>>>
>>> Ron
>>>
>>>
>>>
>>> On 22/09/2014 12:42 PM, Pierre Smits wrote:
>>>> Jacopo,
>>>>
>>>> Your first suggestion is a bit cumbersome. If an issue affects 
>>>> multiple
>>>> versions and it is not fixed in all versions, why not simply keep 
>>>> it open
>>>> as long as the release branch it affects is in the maintenance cycle?
>>>>
>>>> Your second suggestion is ambiguous.
>>>> Which part of the community are you referring to with respect to 
>>>> decreased
>>>> interest?
>>>> What if the installed versions amongst our user base is significant
>>>> different than you expect? We can suggest the users what to use, 
>>>> but it is
>>>> down to migration costs and added value of the newer version how 
>>>> customers
>>>> decide.
>>>>
>>>> And what if there is enough interest among the non-committing 
>>>> contributors
>>>> to continue to support a release branch, while none of the 
>>>> committers is
>>>> willing to? Is the PMC going to invite these non-committing 
>>>> contributors to
>>>> be committers as well?
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>> On Mon, Sep 22, 2014 at 3:51 PM, Jacopo Cappellato <
>>>> jacopo.cappellato@hotwaxmedia.com> 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
>>>>> * 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
>>>>>
>>>>>
>>>>>
>>>
>>> -- 
>>> 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: Release Strategy and Branch Support (was: Re: Bug Crush)

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

OK I began this convo. Inline...

Le 22/09/2014 21:15, Jacopo Cappellato a écrit :
> We are maintaining somewhat similar information in these pages:
>
> http://ofbiz.apache.org/download.html

This is where we should be more specific and explain things better as I kinda suggested in one of my message http://markmail.org/message/pos2gnyj47uxsn5s
Excerpts:
<<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 think we should make that clear and expose a way to users for them to more
"easily" maintain the releases they use.>>

As suggested Ron we could also define our own or refer to http://en.wikipedia.org/wiki/End-of-life_%28product%29 and

Now we need to think "technical" and automatize as possible with Jira
What I have read so far from Jacopo seems a good start to me

Jacques

> http://www.apache.org/dist/ofbiz/
>
> Jacopo
>
> On Sep 22, 2014, at 8:31 PM, Ron Wheeler <rw...@artifact-software.com> wrote:
>
>> Here are some examples of End Of Life policy statements for open source products.
>>
>> http://wiki.centos.org/About/Product
>> http://tomcat.apache.org/tomcat-55-eol.html
>> http://www.openoffice.org/development/releases/eol.html
>>
>>
>> http://support.rightscale.com/15-References/End_of_Support_and_End_of_Life_Schedule is a very nice presentation of EOS and EOL dates with definitions.
>>
>> Perhaps the PMC can take up this issue and settle what they want to offer as a "warranty" to users who download a version or have a version installed and are making their upgrade and security calculations for their ERP.
>>
>>
>>
>> Ron
>>
>>
>>
>> On 22/09/2014 12:42 PM, Pierre Smits wrote:
>>> Jacopo,
>>>
>>> Your first suggestion is a bit cumbersome. If an issue affects multiple
>>> versions and it is not fixed in all versions, why not simply keep it open
>>> as long as the release branch it affects is in the maintenance cycle?
>>>
>>> Your second suggestion is ambiguous.
>>> Which part of the community are you referring to with respect to decreased
>>> interest?
>>> What if the installed versions amongst our user base is significant
>>> different than you expect? We can suggest the users what to use, but it is
>>> down to migration costs and added value of the newer version how customers
>>> decide.
>>>
>>> And what if there is enough interest among the non-committing contributors
>>> to continue to support a release branch, while none of the committers is
>>> willing to? Is the PMC going to invite these non-committing contributors to
>>> be committers as well?
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Mon, Sep 22, 2014 at 3:51 PM, Jacopo Cappellato <
>>> jacopo.cappellato@hotwaxmedia.com> 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
>>>> * 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
>>>>
>>>>
>>>>
>>
>> -- 
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>
>

Re: Release Strategy and Branch Support (was: Re: Bug Crush)

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

We are maintaining somewhat similar information in these pages:

http://ofbiz.apache.org/download.html
http://www.apache.org/dist/ofbiz/

Jacopo

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

> Here are some examples of End Of Life policy statements for open source products.
> 
> http://wiki.centos.org/About/Product
> http://tomcat.apache.org/tomcat-55-eol.html
> http://www.openoffice.org/development/releases/eol.html
> 
> 
> http://support.rightscale.com/15-References/End_of_Support_and_End_of_Life_Schedule is a very nice presentation of EOS and EOL dates with definitions.
> 
> Perhaps the PMC can take up this issue and settle what they want to offer as a "warranty" to users who download a version or have a version installed and are making their upgrade and security calculations for their ERP.
> 
> 
> 
> Ron
> 
> 
> 
> On 22/09/2014 12:42 PM, Pierre Smits wrote:
>> Jacopo,
>> 
>> Your first suggestion is a bit cumbersome. If an issue affects multiple
>> versions and it is not fixed in all versions, why not simply keep it open
>> as long as the release branch it affects is in the maintenance cycle?
>> 
>> Your second suggestion is ambiguous.
>> Which part of the community are you referring to with respect to decreased
>> interest?
>> What if the installed versions amongst our user base is significant
>> different than you expect? We can suggest the users what to use, but it is
>> down to migration costs and added value of the newer version how customers
>> decide.
>> 
>> And what if there is enough interest among the non-committing contributors
>> to continue to support a release branch, while none of the committers is
>> willing to? Is the PMC going to invite these non-committing contributors to
>> be committers as well?
>> 
>> Pierre Smits
>> 
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>> 
>> On Mon, Sep 22, 2014 at 3:51 PM, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxmedia.com> 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
>>> * 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
>>> 
>>> 
>>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 

Re: Release Strategy and Branch Support (was: Re: Bug Crush)

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

Here are some examples of End Of Life policy statements for open source 
products.

http://wiki.centos.org/About/Product
http://tomcat.apache.org/tomcat-55-eol.html
http://www.openoffice.org/development/releases/eol.html


http://support.rightscale.com/15-References/End_of_Support_and_End_of_Life_Schedule 
is a very nice presentation of EOS and EOL dates with definitions.

Perhaps the PMC can take up this issue and settle what they want to 
offer as a "warranty" to users who download a version or have a version 
installed and are making their upgrade and security calculations for 
their ERP.



Ron



On 22/09/2014 12:42 PM, Pierre Smits wrote:
> Jacopo,
>
> Your first suggestion is a bit cumbersome. If an issue affects multiple
> versions and it is not fixed in all versions, why not simply keep it open
> as long as the release branch it affects is in the maintenance cycle?
>
> Your second suggestion is ambiguous.
> Which part of the community are you referring to with respect to decreased
> interest?
> What if the installed versions amongst our user base is significant
> different than you expect? We can suggest the users what to use, but it is
> down to migration costs and added value of the newer version how customers
> decide.
>
> And what if there is enough interest among the non-committing contributors
> to continue to support a release branch, while none of the committers is
> willing to? Is the PMC going to invite these non-committing contributors to
> be committers as well?
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Sep 22, 2014 at 3:51 PM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxmedia.com> 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
>> * 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
>>
>>
>>


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