+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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> >> 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 < >> [email protected]> 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >> >>
