You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2014/10/23 14:17:27 UTC
Re: Release Strategy and Branch Support (was: Re: Bug Crush)
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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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