ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Le Roux <jacques.le.r...@les7arts.com>
Subject Re: Release Strategy and Branch Support
Date Mon, 23 Mar 2015 07:31:36 GMT
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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>

Mime
View raw message