Administrator
|
Hi,
Who added the 15.12.01 unreleased version in Jira and why? Thanks Jacques |
Hi Jacques,
I have added it because it is required as a "Fix for" version for patches that are backported to the 15.12 release. Jacopo On Sat, Mar 19, 2016 at 10:23 PM, Jacques Le Roux < [hidden email]> wrote: > Hi, > > Who added the 15.12.01 unreleased version in Jira and why? > > Thanks > > Jacques > |
Administrator
|
I thought we were only using Upcoming Branch for that. So now the Upcoming Branch is one which is not yet created or is 15.12.01 unreleased version a
duplicate? Jacques Le 20/03/2016 12:29, Jacopo Cappellato a écrit : > Hi Jacques, > > I have added it because it is required as a "Fix for" version for patches > that are backported to the 15.12 release. > > Jacopo > > On Sat, Mar 19, 2016 at 10:23 PM, Jacques Le Roux < > [hidden email]> wrote: > >> Hi, >> >> Who added the 15.12.01 unreleased version in Jira and why? >> >> Thanks >> >> Jacques >> |
Administrator
|
I ask this because not understanding the purpose I removed some in few "Fix Version/s:" fields, thinking it was a duplicate of "Upcoming Branch"
Jacques Le 20/03/2016 14:46, Jacques Le Roux a écrit : > I thought we were only using Upcoming Branch for that. So now the Upcoming Branch is one which is not yet created or is 15.12.01 unreleased version > a duplicate? > > Jacques > > Le 20/03/2016 12:29, Jacopo Cappellato a écrit : >> Hi Jacques, >> >> I have added it because it is required as a "Fix for" version for patches >> that are backported to the 15.12 release. >> >> Jacopo >> >> On Sat, Mar 19, 2016 at 10:23 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >>> Hi, >>> >>> Who added the 15.12.01 unreleased version in Jira and why? >>> >>> Thanks >>> >>> Jacques >>> > |
Jacques, thanks for raising this point that I think is worth of some
clarifications and enhancements to get the best out of the Jira reports. When we backport a patch to the 15.12 branch, the patch will be published in the first release of that branch: and this is why we need the 15.12.01 version and we should set the "fix version" to 15.12.01 rather than 15.12 "Upcoming branch" should be used to mark all the issues that are implemented in the trunk and not backported in the release branches; when, at a later time, we create a new release branch from the trunk, this release branch will of course contain all these enhancements/fixes; at that point we should rename the "Upcoming branch" version into the name of the first (future) release of the new branch and we should create a brand new empty version with the name "Upcoming branch" Frankly speaking, I don't remember if I have done this when I have created the 15.12 branch, but I think it should be good to move some of the tickets accordingly, specifically: * change all the issues with the "fix version" set to "release 15.12" to "15.12.01" * move the issues with the "fix version" set to "upcoming branch", that have been backported to the 15.12 branch, to the "15.12.01" version I hope it makes any sense Jacopo On Sun, Mar 20, 2016 at 8:09 PM, Jacques Le Roux < [hidden email]> wrote: > I ask this because not understanding the purpose I removed some in few > "Fix Version/s:" fields, thinking it was a duplicate of "Upcoming Branch" > > Jacques > > > Le 20/03/2016 14:46, Jacques Le Roux a écrit : > >> I thought we were only using Upcoming Branch for that. So now the >> Upcoming Branch is one which is not yet created or is 15.12.01 unreleased >> version a duplicate? >> >> Jacques >> >> Le 20/03/2016 12:29, Jacopo Cappellato a écrit : >> >>> Hi Jacques, >>> >>> I have added it because it is required as a "Fix for" version for patches >>> that are backported to the 15.12 release. >>> >>> Jacopo >>> >>> On Sat, Mar 19, 2016 at 10:23 PM, Jacques Le Roux < >>> [hidden email]> wrote: >>> >>> Hi, >>>> >>>> Who added the 15.12.01 unreleased version in Jira and why? >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> >> |
Administrator
|
Thanks for your explanation Jacopo, inline...
Le 21/03/2016 15:10, Jacopo Cappellato a écrit : > Jacques, thanks for raising this point that I think is worth of some > clarifications and enhancements to get the best out of the Jira reports. > > When we backport a patch to the 15.12 branch, the patch will be published > in the first release of that branch: and this is why we need the 15.12.01 > version and we should set the "fix version" to 15.12.01 rather than 15.12 Yes, I thought about it afterwards and I could see the reason. So far I tried to remove all not released versions (like 15.12) out of the "fixed versions" field. I used "Upcoming branch" for the not yet released branches. And of course pending next release versions (like 13.07.02) when appropriate (ie when backporting in a supported and already released branch) But if we have 2 unreleased branches (like at the moment 14 and 15) we indeed need to differentiate them. > "Upcoming branch" should be used to mark all the issues that are > implemented in the trunk and not backported in the release branches; OK, I thought we were also using that for backports in not yet released branches. > when, at a later time, we create a new release branch from the trunk, this > release branch will of course contain all these enhancements/fixes; at that > point we should rename the "Upcoming branch" version into the name of the > first (future) release of the new branch and we should create a brand new > empty version with the name "Upcoming branch" You mean rename in the admin side, right? So Jira will automatically relate all the issues with the new name. > Frankly speaking, I don't remember if I have done this when I have created > the 15.12 branch, but I think it should be good to move some of the tickets > accordingly, specifically: > * change all the issues with the "fix version" set to "release 15.12" to > "15.12.01" I expect no issues with the "fix version" set to "release 15.12" Because I monitored that and allowed only "Upcoming branch" or pending next release versions (like 13.07.02) in this field (I just checked, indeed none) > * move the issues with the "fix version" set to "upcoming branch", that > have been backported to the 15.12 branch, to the "15.12.01" version I can "easily" do that for the issues where I removed "15.12.01" from the "Fix Version" field For the others backported since the branch has been created it will be harder. Anyway we will do our best... I also realise we did not use the (Community Day 1 - 2016 ends 28/Mar/16) enough in the recent effort. > I hope it makes any sense Yes thanks! Jacques > > Jacopo > > On Sun, Mar 20, 2016 at 8:09 PM, Jacques Le Roux < > [hidden email]> wrote: > >> I ask this because not understanding the purpose I removed some in few >> "Fix Version/s:" fields, thinking it was a duplicate of "Upcoming Branch" >> >> Jacques >> >> >> Le 20/03/2016 14:46, Jacques Le Roux a écrit : >> >>> I thought we were only using Upcoming Branch for that. So now the >>> Upcoming Branch is one which is not yet created or is 15.12.01 unreleased >>> version a duplicate? >>> >>> Jacques >>> >>> Le 20/03/2016 12:29, Jacopo Cappellato a écrit : >>> >>>> Hi Jacques, >>>> >>>> I have added it because it is required as a "Fix for" version for patches >>>> that are backported to the 15.12 release. >>>> >>>> Jacopo >>>> >>>> On Sat, Mar 19, 2016 at 10:23 PM, Jacques Le Roux < >>>> [hidden email]> wrote: >>>> >>>> Hi, >>>>> Who added the 15.12.01 unreleased version in Jira and why? >>>>> >>>>> Thanks >>>>> >>>>> Jacques >>>>> >>>>> |
Administrator
|
In reply to this post by Jacopo Cappellato-5
Hi Jacopo, inline...
Le 21/03/2016 15:10, Jacopo Cappellato a écrit : > Jacques, thanks for raising this point that I think is worth of some > clarifications and enhancements to get the best out of the Jira reports. [...] > "Upcoming branch" should be used to mark all the issues that are > implemented in the trunk and not backported in the release branches So, apart maybe some very specific cases, could we in others words say it should not be used by bug fixes? About the very specific cases, I wonder when a bug fixes cannot be backported, notably to the last release branch. I see only when a refactoring makes it too much troubles. Which also show that the refactoring was not well done: the bug should have been fixed during the refactoring[1]. Then it's maybe better to backport the refactoring AND the bug fixes on the refactoring... > ; when, at a later time, we create a new release branch from the trunk, this > release branch will of course contain all these enhancements/fixes; at that > point we should rename the "Upcoming branch" version into the name of the > first (future) release of the new branch and we should create a brand new > empty version with the name "Upcoming branch" > > Frankly speaking, I don't remember if I have done this when I have created > the 15.12 branch, but I think it should be good to move some of the tickets > accordingly, specifically: > * change all the issues with the "fix version" set to "release 15.12" to > "15.12.01" I did that and also for the 14.12 to 14.12.01, but Michael's https://issues.apache.org/jira/browse/OFBIZ-6662?jql=project%20%3D%20OFBIZ%20AND%20fixVersion%20%3D%20%22Release%20Branch%2014.12%22%20ORDER%20BY%20updated%20DESC Please Michael :) > * move the issues with the "fix version" set to "upcoming branch", that > have been backported to the 15.12 branch, to the "15.12.01" version Found none :) https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20fixVersion%20%3D%20%22Upcoming%20Branch%22%20AND%20fixVersion%20%3D%20%22Release%20Branch%2015.12%22%20ORDER%20BY%20updated%20DESC Jacques [1] For me refactoring code means to not change its functionality, except when you detect and fix a bug during the refactoring > > I hope it makes any sense > > Jacopo |
Administrator
|
Le 10/04/2016 10:35, Jacques Le Roux a écrit :
> So, apart maybe some very specific cases, could we in others words say it should not be used by bug fixes? > About the very specific cases, I wonder when a bug fixes cannot be backported, notably to the last release branch. > I see only when a refactoring makes it too much troubles. Which also show that the refactoring was not well done: the bug should have been fixed > during the refactoring[1]. I missed at least one case: when you refactor by splitting. Then a bug in a splitted block might not be spotted. I guess there are other cases when refactoring, but I see no other reasons than refactoring I insist on that because I want to update ("set in stone") https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities#OFBizCommittersRolesandResponsibilities-Followingchanges Jacques |
Administrator
|
In reply to this post by Jacques Le Roux
Le 10/04/2016 10:35, Jacques Le Roux a écrit :
> Hi Jacopo, inline... > > Le 21/03/2016 15:10, Jacopo Cappellato a écrit : >> Jacques, thanks for raising this point that I think is worth of some >> clarifications and enhancements to get the best out of the Jira reports. > [...] >> "Upcoming branch" should be used to mark all the issues that are >> implemented in the trunk and not backported in the release branches > > So, apart maybe some very specific cases, could we in others words say it should not be used by bug fixes? > About the very specific cases, I wonder when a bug fixes cannot be backported, notably to the last release branch. > I see only when a refactoring makes it too much troubles. Which also show that the refactoring was not well done: the bug should have been fixed > during the refactoring[1]. > Then it's maybe better to backport the refactoring AND the bug fixes on the refactoring... Hi Jacopo, I think a simple question with an example is better: See https://issues.apache.org/jira/browse/OFBIZ-6915 for upgrading to Tomcat 8. It's a bug fix because there is a disputed vulnerability in Tomcat 7 (CVE-2013-2185 tomcat-7.0.68-jasper.jar) I set the fixed versions as, Upcoming Branch, 15.12.01 because I committed in trunk and R15.12. From what you said I should only set 15.12.01. But then how users will know (in release notes) that the next coming branch has been fixed also? Thanks Jacques |
Hi Jacques,
the idea is that if we fix something in a release, for example 15.12.01 then it is implied that all future releases will be also fixed: 15.12.03, 04 but also 16.xx.xx etc... In fact by policy we always fix in trunk and then backport if needed. Cheers, Jacopo On Wed, Apr 13, 2016 at 12:40 PM, Jacques Le Roux < [hidden email]> wrote: > Le 10/04/2016 10:35, Jacques Le Roux a écrit : > >> Hi Jacopo, inline... >> >> Le 21/03/2016 15:10, Jacopo Cappellato a écrit : >> >>> Jacques, thanks for raising this point that I think is worth of some >>> clarifications and enhancements to get the best out of the Jira reports. >>> >> [...] >> >>> "Upcoming branch" should be used to mark all the issues that are >>> implemented in the trunk and not backported in the release branches >>> >> >> So, apart maybe some very specific cases, could we in others words say it >> should not be used by bug fixes? >> About the very specific cases, I wonder when a bug fixes cannot be >> backported, notably to the last release branch. >> I see only when a refactoring makes it too much troubles. Which also show >> that the refactoring was not well done: the bug should have been fixed >> during the refactoring[1]. >> Then it's maybe better to backport the refactoring AND the bug fixes on >> the refactoring... >> > > Hi Jacopo, > > I think a simple question with an example is better: > > See https://issues.apache.org/jira/browse/OFBIZ-6915 for upgrading to > Tomcat 8. > It's a bug fix because there is a disputed vulnerability in Tomcat 7 > (CVE-2013-2185 tomcat-7.0.68-jasper.jar) > I set the fixed versions as, Upcoming Branch, 15.12.01 because I > committed in trunk and R15.12. > > From what you said I should only set 15.12.01. > But then how users will know (in release notes) that the next coming > branch has been fixed also? > > Thanks > > Jacques > > |
Administrator
|
OK clear, if it works for releasing. I will update the wiki page
Thanks Jacques Le 13/04/2016 19:17, Jacopo Cappellato a écrit : > Hi Jacques, > > the idea is that if we fix something in a release, for example 15.12.01 > then it is implied that all future releases will be also fixed: 15.12.03, > 04 but also 16.xx.xx etc... > In fact by policy we always fix in trunk and then backport if needed. > > Cheers, > > Jacopo > > On Wed, Apr 13, 2016 at 12:40 PM, Jacques Le Roux < > [hidden email]> wrote: > >> Le 10/04/2016 10:35, Jacques Le Roux a écrit : >> >>> Hi Jacopo, inline... >>> >>> Le 21/03/2016 15:10, Jacopo Cappellato a écrit : >>> >>>> Jacques, thanks for raising this point that I think is worth of some >>>> clarifications and enhancements to get the best out of the Jira reports. >>>> >>> [...] >>> >>>> "Upcoming branch" should be used to mark all the issues that are >>>> implemented in the trunk and not backported in the release branches >>>> >>> So, apart maybe some very specific cases, could we in others words say it >>> should not be used by bug fixes? >>> About the very specific cases, I wonder when a bug fixes cannot be >>> backported, notably to the last release branch. >>> I see only when a refactoring makes it too much troubles. Which also show >>> that the refactoring was not well done: the bug should have been fixed >>> during the refactoring[1]. >>> Then it's maybe better to backport the refactoring AND the bug fixes on >>> the refactoring... >>> >> Hi Jacopo, >> >> I think a simple question with an example is better: >> >> See https://issues.apache.org/jira/browse/OFBIZ-6915 for upgrading to >> Tomcat 8. >> It's a bug fix because there is a disputed vulnerability in Tomcat 7 >> (CVE-2013-2185 tomcat-7.0.68-jasper.jar) >> I set the fixed versions as, Upcoming Branch, 15.12.01 because I >> committed in trunk and R15.12. >> >> From what you said I should only set 15.12.01. >> But then how users will know (in release notes) that the next coming >> branch has been fixed also? >> >> Thanks >> >> Jacques >> >> |
Administrator
|
BTW don't we need to remove Upcoming branch from unreleased versions? It's confusing there, I mean. Is it necessary for the releasing process?
Jacques Le 13/04/2016 21:39, Jacques Le Roux a écrit : > OK clear, if it works for releasing. I will update the wiki page > > Thanks > > Jacques > > Le 13/04/2016 19:17, Jacopo Cappellato a écrit : >> Hi Jacques, >> >> the idea is that if we fix something in a release, for example 15.12.01 >> then it is implied that all future releases will be also fixed: 15.12.03, >> 04 but also 16.xx.xx etc... >> In fact by policy we always fix in trunk and then backport if needed. >> >> Cheers, >> >> Jacopo >> >> On Wed, Apr 13, 2016 at 12:40 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >>> Le 10/04/2016 10:35, Jacques Le Roux a écrit : >>> >>>> Hi Jacopo, inline... >>>> >>>> Le 21/03/2016 15:10, Jacopo Cappellato a écrit : >>>> >>>>> Jacques, thanks for raising this point that I think is worth of some >>>>> clarifications and enhancements to get the best out of the Jira reports. >>>>> >>>> [...] >>>> >>>>> "Upcoming branch" should be used to mark all the issues that are >>>>> implemented in the trunk and not backported in the release branches >>>>> >>>> So, apart maybe some very specific cases, could we in others words say it >>>> should not be used by bug fixes? >>>> About the very specific cases, I wonder when a bug fixes cannot be >>>> backported, notably to the last release branch. >>>> I see only when a refactoring makes it too much troubles. Which also show >>>> that the refactoring was not well done: the bug should have been fixed >>>> during the refactoring[1]. >>>> Then it's maybe better to backport the refactoring AND the bug fixes on >>>> the refactoring... >>>> >>> Hi Jacopo, >>> >>> I think a simple question with an example is better: >>> >>> See https://issues.apache.org/jira/browse/OFBIZ-6915 for upgrading to >>> Tomcat 8. >>> It's a bug fix because there is a disputed vulnerability in Tomcat 7 >>> (CVE-2013-2185 tomcat-7.0.68-jasper.jar) >>> I set the fixed versions as, Upcoming Branch, 15.12.01 because I >>> committed in trunk and R15.12. >>> >>> From what you said I should only set 15.12.01. >>> But then how users will know (in release notes) that the next coming >>> branch has been fixed also? >>> >>> Thanks >>> >>> Jacques >>> >>> > |
Administrator
|
In reply to this post by Jacques Le Roux
Done
Le 13/04/2016 21:39, Jacques Le Roux a écrit : > OK clear, if it works for releasing. I will update the wiki page > > Thanks > > Jacques > > Le 13/04/2016 19:17, Jacopo Cappellato a écrit : >> Hi Jacques, >> >> the idea is that if we fix something in a release, for example 15.12.01 >> then it is implied that all future releases will be also fixed: 15.12.03, >> 04 but also 16.xx.xx etc... >> In fact by policy we always fix in trunk and then backport if needed. >> >> Cheers, >> >> Jacopo >> >> On Wed, Apr 13, 2016 at 12:40 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >>> Le 10/04/2016 10:35, Jacques Le Roux a écrit : >>> >>>> Hi Jacopo, inline... >>>> >>>> Le 21/03/2016 15:10, Jacopo Cappellato a écrit : >>>> >>>>> Jacques, thanks for raising this point that I think is worth of some >>>>> clarifications and enhancements to get the best out of the Jira reports. >>>>> >>>> [...] >>>> >>>>> "Upcoming branch" should be used to mark all the issues that are >>>>> implemented in the trunk and not backported in the release branches >>>>> >>>> So, apart maybe some very specific cases, could we in others words say it >>>> should not be used by bug fixes? >>>> About the very specific cases, I wonder when a bug fixes cannot be >>>> backported, notably to the last release branch. >>>> I see only when a refactoring makes it too much troubles. Which also show >>>> that the refactoring was not well done: the bug should have been fixed >>>> during the refactoring[1]. >>>> Then it's maybe better to backport the refactoring AND the bug fixes on >>>> the refactoring... >>>> >>> Hi Jacopo, >>> >>> I think a simple question with an example is better: >>> >>> See https://issues.apache.org/jira/browse/OFBIZ-6915 for upgrading to >>> Tomcat 8. >>> It's a bug fix because there is a disputed vulnerability in Tomcat 7 >>> (CVE-2013-2185 tomcat-7.0.68-jasper.jar) >>> I set the fixed versions as, Upcoming Branch, 15.12.01 because I >>> committed in trunk and R15.12. >>> >>> From what you said I should only set 15.12.01. >>> But then how users will know (in release notes) that the next coming >>> branch has been fixed also? >>> >>> Thanks >>> >>> Jacques >>> >>> > |
Administrator
|
In reply to this post by Jacques Le Roux
Sorry this makes no sense, of course we need for improvements and such.
Actually it's now only a matter of monitoring and educating Jacques Le 13/04/2016 21:51, Jacques Le Roux a écrit : > BTW don't we need to remove Upcoming branch from unreleased versions? It's confusing there, I mean. Is it necessary for the releasing process? > > Jacques > > > Le 13/04/2016 21:39, Jacques Le Roux a écrit : >> OK clear, if it works for releasing. I will update the wiki page >> >> Thanks >> >> Jacques >> >> Le 13/04/2016 19:17, Jacopo Cappellato a écrit : >>> Hi Jacques, >>> >>> the idea is that if we fix something in a release, for example 15.12.01 >>> then it is implied that all future releases will be also fixed: 15.12.03, >>> 04 but also 16.xx.xx etc... >>> In fact by policy we always fix in trunk and then backport if needed. >>> >>> Cheers, >>> >>> Jacopo >>> >>> On Wed, Apr 13, 2016 at 12:40 PM, Jacques Le Roux < >>> [hidden email]> wrote: >>> >>>> Le 10/04/2016 10:35, Jacques Le Roux a écrit : >>>> >>>>> Hi Jacopo, inline... >>>>> >>>>> Le 21/03/2016 15:10, Jacopo Cappellato a écrit : >>>>> >>>>>> Jacques, thanks for raising this point that I think is worth of some >>>>>> clarifications and enhancements to get the best out of the Jira reports. >>>>>> >>>>> [...] >>>>> >>>>>> "Upcoming branch" should be used to mark all the issues that are >>>>>> implemented in the trunk and not backported in the release branches >>>>>> >>>>> So, apart maybe some very specific cases, could we in others words say it >>>>> should not be used by bug fixes? >>>>> About the very specific cases, I wonder when a bug fixes cannot be >>>>> backported, notably to the last release branch. >>>>> I see only when a refactoring makes it too much troubles. Which also show >>>>> that the refactoring was not well done: the bug should have been fixed >>>>> during the refactoring[1]. >>>>> Then it's maybe better to backport the refactoring AND the bug fixes on >>>>> the refactoring... >>>>> >>>> Hi Jacopo, >>>> >>>> I think a simple question with an example is better: >>>> >>>> See https://issues.apache.org/jira/browse/OFBIZ-6915 for upgrading to >>>> Tomcat 8. >>>> It's a bug fix because there is a disputed vulnerability in Tomcat 7 >>>> (CVE-2013-2185 tomcat-7.0.68-jasper.jar) >>>> I set the fixed versions as, Upcoming Branch, 15.12.01 because I >>>> committed in trunk and R15.12. >>>> >>>> From what you said I should only set 15.12.01. >>>> But then how users will know (in release notes) that the next coming >>>> branch has been fixed also? >>>> >>>> Thanks >>>> >>>> Jacques >>>> >>>> >> > |
Free forum by Nabble | Edit this page |