The community as a whole supports OFBiz and its releases. Jacopo
On Mar 23, 2015, at 3:38 PM, Ron Wheeler <[email protected]> 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 <[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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 >
