Re: Next Jira Fix Version after 4.0.0
Hi Laszlo, The next version is 4.1.0 only. AFAIK the target fix version is by practice the one defined in the pom.xml file. https://github.com/apache/hive/blob/master/pom.xml#L24 -Ayush On Fri, 5 Apr 2024 at 20:36, László Bodor wrote: > Now, as Apache Hive 4.0.0 has been released, it's time to find a new Fix > Version to make devs able to pick a valid one when resolving new tickets. > I'm proposing *4.1.0*, which can be bulk-changed later if we decide > otherwise. Any opinions about this? > > Thanks, > Laszlo Bodor > >
Next Jira Fix Version after 4.0.0
Now, as Apache Hive 4.0.0 has been released, it's time to find a new Fix Version to make devs able to pick a valid one when resolving new tickets. I'm proposing *4.1.0*, which can be bulk-changed later if we decide otherwise. Any opinions about this? Thanks, Laszlo Bodor
Re: Fix Version is now mandatory in Jira
Hi Pravin, The fix version for master is 4.1.0 now. It is being tracked under [1] & [2] I have created the version 4.1.0 in Jira, so you should be able to resolve the tickets with it now. -Ayush [1] https://issues.apache.org/jira/browse/HIVE-27928 [2] https://github.com/apache/hive/pull/4914 On Mon, 4 Dec 2023 at 22:57, Pravin sinha wrote: > > Hi Ayush > > Thanks for the update. Given that the branch for 4.0.0 is cut, for > resolving jira in master branch what is the "fix version" decided to be > given? Do we already have a place-holder created for the version next to > 4.0.0? > Asking this anticipating that not everything from master will be cherry > picked to branch-4.0 <https://github.com/apache/hive/tree/branch-4.0>. > > Thanks, > Pravin > > On Thu, Nov 23, 2023 at 8:00 PM Ayush Saxena wrote: > > > Hi All, > > Following INFRA-24974, now for any Hive ticket, it is mandatory to > > provide the Fix Version, if not it won't let you resolve the ticket. > > > > Fix Version is a mandatory column which is used to populate the > > release notes, So, please put the correct fix version while resolving > > the tickets. > > > > If you aren't sure, just check the POM for the hive version in the > > branch where the code was merged. > > > > Let me know if there are any issues. In case the code isn't merged to > > any of the release branches, or if it is an Invalid or Dupe ticket, > > please add Not Applicable as the fix version & resolve. > > > > PS. If you want to give it a try, can try on > > https://issues.apache.org/jira/browse/HIVE-27909, I created that to > > try myself :-) > > > > -Ayush > >
Re: Fix Version is now mandatory in Jira
Hi Ayush Thanks for the update. Given that the branch for 4.0.0 is cut, for resolving jira in master branch what is the "fix version" decided to be given? Do we already have a place-holder created for the version next to 4.0.0? Asking this anticipating that not everything from master will be cherry picked to branch-4.0 <https://github.com/apache/hive/tree/branch-4.0>. Thanks, Pravin On Thu, Nov 23, 2023 at 8:00 PM Ayush Saxena wrote: > Hi All, > Following INFRA-24974, now for any Hive ticket, it is mandatory to > provide the Fix Version, if not it won't let you resolve the ticket. > > Fix Version is a mandatory column which is used to populate the > release notes, So, please put the correct fix version while resolving > the tickets. > > If you aren't sure, just check the POM for the hive version in the > branch where the code was merged. > > Let me know if there are any issues. In case the code isn't merged to > any of the release branches, or if it is an Invalid or Dupe ticket, > please add Not Applicable as the fix version & resolve. > > PS. If you want to give it a try, can try on > https://issues.apache.org/jira/browse/HIVE-27909, I created that to > try myself :-) > > -Ayush >
Fix Version is now mandatory in Jira
Hi All, Following INFRA-24974, now for any Hive ticket, it is mandatory to provide the Fix Version, if not it won't let you resolve the ticket. Fix Version is a mandatory column which is used to populate the release notes, So, please put the correct fix version while resolving the tickets. If you aren't sure, just check the POM for the hive version in the branch where the code was merged. Let me know if there are any issues. In case the code isn't merged to any of the release branches, or if it is an Invalid or Dupe ticket, please add Not Applicable as the fix version & resolve. PS. If you want to give it a try, can try on https://issues.apache.org/jira/browse/HIVE-27909, I created that to try myself :-) -Ayush
[jira] [Created] (HIVE-19944) Investigate and fix version mismatch of GCP
Adam Szita created HIVE-19944: - Summary: Investigate and fix version mismatch of GCP Key: HIVE-19944 URL: https://issues.apache.org/jira/browse/HIVE-19944 Project: Hive Issue Type: Sub-task Reporter: Adam Szita Assignee: Adam Szita We've observed that adding a new image to the ptest GCP project breaks our currently working infrastructure when we try to restart the hive ptest server. This is because upon initialization the project's images are queried and we immediately get an exception for newly added images - they don't have a field that our client thinks should be mandatory to have. I believe there's an upgrade needed on our side for the GCP libs we depend on. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: JIRA "Affects version/s" and "Fix version/s"
I agree, we need to ensure that open BUG type jira have 'Affects Version' and fixed ones need to have 'Fix Version' set. Thanks for link Wei, thats very useful. It would be great if we can make Affects Version mandatory for BUG type jiras. I took a quick look and was confused on how to make the change! Regarding 'Fix Version', it makes to set that only when the bug is being marked fixed. However, it is not clear if enforcing that during that transition of jira is possible. Forcing it to be set before its actually fixed does not help, it only increases the chances of having a wrong Fix Version set, which is probably worse than having no fix version at all. On Thu, Oct 15, 2015 at 8:51 PM, Wei Zheng wrote: > Looks like it's configurable. > > https://confluence.atlassian.com/jira/specifying-field-behavior-185729654.html#SpecifyingFieldBehavior-Makingafieldrequiredoroptional > > Thanks, > Wei > > > > > > > > On 10/15/15, 13:58, "Eugene Koifman" wrote: > >>Can JIRA be made to enforce that these are set to something when the >>ticket is Resolved? >> >> >>On 10/15/15, 9:52 AM, "Xuefu Zhang" wrote: >> >>>Hi folks, >>> >>>I know most of us have done a good job in updating JIRAs with respective >>>"Affects version/s" and "Fix version/s". However, I do see from time to >>>time that these fields are missing in some JIRAs even after those JIRAs >>>are >>>closed. >>> >>>These field are very important in helping users to determine if their >>>versions are affected or fixed. >>> >>>If for some reason either the field is not applicable, please use "n/a" >>>specifically. >>> >>>Please feel free to share your thoughts or comments on this. >>> >>>Thanks, >>>Xuefu >> >>
Re: JIRA "Affects version/s" and "Fix version/s"
Looks like it's configurable. https://confluence.atlassian.com/jira/specifying-field-behavior-185729654.html#SpecifyingFieldBehavior-Makingafieldrequiredoroptional Thanks, Wei On 10/15/15, 13:58, "Eugene Koifman" wrote: >Can JIRA be made to enforce that these are set to something when the >ticket is Resolved? > > >On 10/15/15, 9:52 AM, "Xuefu Zhang" wrote: > >>Hi folks, >> >>I know most of us have done a good job in updating JIRAs with respective >>"Affects version/s" and "Fix version/s". However, I do see from time to >>time that these fields are missing in some JIRAs even after those JIRAs >>are >>closed. >> >>These field are very important in helping users to determine if their >>versions are affected or fixed. >> >>If for some reason either the field is not applicable, please use "n/a" >>specifically. >> >>Please feel free to share your thoughts or comments on this. >> >>Thanks, >>Xuefu > >
Re: JIRA "Affects version/s" and "Fix version/s"
Can JIRA be made to enforce that these are set to something when the ticket is Resolved? On 10/15/15, 9:52 AM, "Xuefu Zhang" wrote: >Hi folks, > >I know most of us have done a good job in updating JIRAs with respective >"Affects version/s" and "Fix version/s". However, I do see from time to >time that these fields are missing in some JIRAs even after those JIRAs >are >closed. > >These field are very important in helping users to determine if their >versions are affected or fixed. > >If for some reason either the field is not applicable, please use "n/a" >specifically. > >Please feel free to share your thoughts or comments on this. > >Thanks, >Xuefu
JIRA "Affects version/s" and "Fix version/s"
Hi folks, I know most of us have done a good job in updating JIRAs with respective "Affects version/s" and "Fix version/s". However, I do see from time to time that these fields are missing in some JIRAs even after those JIRAs are closed. These field are very important in helping users to determine if their versions are affected or fixed. If for some reason either the field is not applicable, please use "n/a" specifically. Please feel free to share your thoughts or comments on this. Thanks, Xuefu
IMPORTANT - fix version
As branch-1 has been created, if the patch is committed to master , please set the fix version to 2.0.0. If the patch is also committed to branch-1, please add 1.3.0 as the fix version. For now, I will do a bulk update to add 2.0.0 to any that has 1.3.0 as the fix version. I am assuming that so far, anything that has gone into 1.3.0 (branch-1) has also gone in to 2.0.0 (master). If something has gone into master only and has 1.3.0 as fix version, we need to correct that (either by 'git cherry-pick' it into branch-1 or removing 1.3.0 from fix version. Thanks, Thejas
Re: Bulk update JIRA fix version
Great! Thanks a lot for the information, Thejas. --Xuefu On Thu, May 28, 2015 at 10:17 AM, Thejas Nair wrote: > Once you update it, I think you should sync with Sushanth and get it > included in the branch-1.2 RELEASE_NOTES.txt file. That way a 1.2.1 > would have it right. > > > > On Thu, May 28, 2015 at 10:16 AM, Thejas Nair > wrote: > > Yes, there is a way to do bulk updates to jira, if you have admin > > privileges in Jira (which you should have). > > Once you search for issues in jira with a criteria, in the search > > result page, you will see a drop down under tools in top right side of > > the page. That has a bulk update option. > > > > Yes, I think we should update the fix version of jiras in a branch, as > > soon as the merge happens. Otherwise its hard to figure out what > > release has the fixes. > > > > > > On Thu, May 28, 2015 at 9:21 AM, Xuefu Zhang > wrote: > >> Hi all, > >> > >> When I check Hive 1.2.0 release notes > >> < > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329345&styleName=Text&projectId=12310843 > >, > >> I found that the JIRA list missed many Hive on spark related JIRAs that > >> were resolved in HIVE 1.2. I guess the problem is that the fix version > of > >> these JIRAs weren't updated when they are merged to trunk. Partly my > bad, > >> but this is probably a general issue happening at the time merging. > Thus, > >> I'm wondering if there is a way to bulk update these JIRAs when they are > >> merged. > >> > >> Thanks, > >> Xuefu >
Re: Bulk update JIRA fix version
Once you update it, I think you should sync with Sushanth and get it included in the branch-1.2 RELEASE_NOTES.txt file. That way a 1.2.1 would have it right. On Thu, May 28, 2015 at 10:16 AM, Thejas Nair wrote: > Yes, there is a way to do bulk updates to jira, if you have admin > privileges in Jira (which you should have). > Once you search for issues in jira with a criteria, in the search > result page, you will see a drop down under tools in top right side of > the page. That has a bulk update option. > > Yes, I think we should update the fix version of jiras in a branch, as > soon as the merge happens. Otherwise its hard to figure out what > release has the fixes. > > > On Thu, May 28, 2015 at 9:21 AM, Xuefu Zhang wrote: >> Hi all, >> >> When I check Hive 1.2.0 release notes >> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329345&styleName=Text&projectId=12310843>, >> I found that the JIRA list missed many Hive on spark related JIRAs that >> were resolved in HIVE 1.2. I guess the problem is that the fix version of >> these JIRAs weren't updated when they are merged to trunk. Partly my bad, >> but this is probably a general issue happening at the time merging. Thus, >> I'm wondering if there is a way to bulk update these JIRAs when they are >> merged. >> >> Thanks, >> Xuefu
Re: Bulk update JIRA fix version
Yes, there is a way to do bulk updates to jira, if you have admin privileges in Jira (which you should have). Once you search for issues in jira with a criteria, in the search result page, you will see a drop down under tools in top right side of the page. That has a bulk update option. Yes, I think we should update the fix version of jiras in a branch, as soon as the merge happens. Otherwise its hard to figure out what release has the fixes. On Thu, May 28, 2015 at 9:21 AM, Xuefu Zhang wrote: > Hi all, > > When I check Hive 1.2.0 release notes > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329345&styleName=Text&projectId=12310843>, > I found that the JIRA list missed many Hive on spark related JIRAs that > were resolved in HIVE 1.2. I guess the problem is that the fix version of > these JIRAs weren't updated when they are merged to trunk. Partly my bad, > but this is probably a general issue happening at the time merging. Thus, > I'm wondering if there is a way to bulk update these JIRAs when they are > merged. > > Thanks, > Xuefu
Bulk update JIRA fix version
Hi all, When I check Hive 1.2.0 release notes <https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329345&styleName=Text&projectId=12310843>, I found that the JIRA list missed many Hive on spark related JIRAs that were resolved in HIVE 1.2. I guess the problem is that the fix version of these JIRAs weren't updated when they are merged to trunk. Partly my bad, but this is probably a general issue happening at the time merging. Thus, I'm wondering if there is a way to bulk update these JIRAs when they are merged. Thanks, Xuefu
Re: Fix version for hbase-metastore branch
D'oh! I'd forgotted about the idea of a doc JIRA. In that case, we don't really need the label. (Less clutter in the label drop-down.) -- Lefty On Fri, Feb 20, 2015 at 8:38 AM, Alan Gates wrote: > TODOC-HBMETA works for me. I'll change that at the same time I fix the > change versions. I'll also open a JIRA for docs on this stuff with links > to the JIRAs that need documentation. > > Alan. > > Lefty Leverenz > February 19, 2015 at 23:01 > Also, what should we use for a documentation label? (HIVE-9606 > <https://issues.apache.org/jira/browse/HIVE-9606> needs one.) > > TODOC labels are proliferating for all the releases and branches, but I > don't think a generic TODOC label would be helpful. So what would be a > good abbreviation for the hbase-metastore branch? Maybe TODOC-HBMETA? > > -- Lefty > > > Alan Gates > February 19, 2015 at 19:12 > Could someone with admin permissions on our JIRA add an > hbase-metastore-branch label? I'll take care of changing all the fix > versions for the few JIRA's we've already committed. Thanks. > > Alan. > > Ashutosh Chauhan > February 19, 2015 at 11:22 > This is what we have been doing for cbo work. e.g. > https://issues.apache.org/jira/browse/HIVE-9581 > > > Thejas Nair > February 19, 2015 at 11:17 > I agree, using a label for fix version makes sense in this case. I believe > that is what had been done for hive-on-spark and hive-on-tez. > > > > Alan Gates > February 19, 2015 at 10:56 > I've been marking JIRAs on this branch as fixed in 1.2, since that's the > next version. But that seems wrong as I doubt this code will be in by > 1.2. What's the usual practice here? It seems it would make sense to make > a label for this branch and mark them as fixed with that label and then > when we actually release this in a version we can update all the JIRAs with > that label. > > Alan. > >
Re: Fix version for hbase-metastore branch
TODOC-HBMETA works for me. I'll change that at the same time I fix the change versions. I'll also open a JIRA for docs on this stuff with links to the JIRAs that need documentation. Alan. Lefty Leverenz <mailto:leftylever...@gmail.com> February 19, 2015 at 23:01 Also, what should we use for a documentation label? (HIVE-9606 <https://issues.apache.org/jira/browse/HIVE-9606> needs one.) TODOC labels are proliferating for all the releases and branches, but I don't think a generic TODOC label would be helpful. So what would be a good abbreviation for the hbase-metastore branch? Maybe TODOC-HBMETA? -- Lefty Alan Gates <mailto:alanfga...@gmail.com> February 19, 2015 at 19:12 Could someone with admin permissions on our JIRA add an hbase-metastore-branch label? I'll take care of changing all the fix versions for the few JIRA's we've already committed. Thanks. Alan. Ashutosh Chauhan <mailto:hashut...@apache.org> February 19, 2015 at 11:22 This is what we have been doing for cbo work. e.g. https://issues.apache.org/jira/browse/HIVE-9581 Thejas Nair <mailto:thejas.n...@gmail.com> February 19, 2015 at 11:17 I agree, using a label for fix version makes sense in this case. I believe that is what had been done for hive-on-spark and hive-on-tez. Alan Gates <mailto:alanfga...@gmail.com> February 19, 2015 at 10:56 I've been marking JIRAs on this branch as fixed in 1.2, since that's the next version. But that seems wrong as I doubt this code will be in by 1.2. What's the usual practice here? It seems it would make sense to make a label for this branch and mark them as fixed with that label and then when we actually release this in a version we can update all the JIRAs with that label. Alan.
Re: Fix version for hbase-metastore branch
TODOC-HBMETA sounds good to me. On Thu, Feb 19, 2015 at 11:01 PM, Lefty Leverenz wrote: > Also, what should we use for a documentation label? (HIVE-9606 > <https://issues.apache.org/jira/browse/HIVE-9606> needs one.) > > TODOC labels are proliferating for all the releases and branches, but I > don't think a generic TODOC label would be helpful. So what would be a > good abbreviation for the hbase-metastore branch? Maybe TODOC-HBMETA? > > -- Lefty > > On Thu, Feb 19, 2015 at 7:12 PM, Alan Gates wrote: > >> Could someone with admin permissions on our JIRA add an >> hbase-metastore-branch label? I'll take care of changing all the fix >> versions for the few JIRA's we've already committed. Thanks. >> >> Alan. >> >> Ashutosh Chauhan >> February 19, 2015 at 11:22 >> This is what we have been doing for cbo work. e.g. >> https://issues.apache.org/jira/browse/HIVE-9581 >> >> >> Thejas Nair >> February 19, 2015 at 11:17 >> I agree, using a label for fix version makes sense in this case. I believe >> that is what had been done for hive-on-spark and hive-on-tez. >> >> >> >> Alan Gates >> February 19, 2015 at 10:56 >> I've been marking JIRAs on this branch as fixed in 1.2, since that's the >> next version. But that seems wrong as I doubt this code will be in by >> 1.2. What's the usual practice here? It seems it would make sense to make >> a label for this branch and mark them as fixed with that label and then >> when we actually release this in a version we can update all the JIRAs with >> that label. >> >> Alan. >> >> >
Re: Fix version for hbase-metastore branch
Done. On Thu, Feb 19, 2015 at 7:12 PM, Alan Gates wrote: > Could someone with admin permissions on our JIRA add an > hbase-metastore-branch label? I'll take care of changing all the fix > versions for the few JIRA's we've already committed. Thanks. > > Alan. > > Ashutosh Chauhan > February 19, 2015 at 11:22 > This is what we have been doing for cbo work. e.g. > https://issues.apache.org/jira/browse/HIVE-9581 > > > Thejas Nair > February 19, 2015 at 11:17 > I agree, using a label for fix version makes sense in this case. I believe > that is what had been done for hive-on-spark and hive-on-tez. > > > > Alan Gates > February 19, 2015 at 10:56 > I've been marking JIRAs on this branch as fixed in 1.2, since that's the > next version. But that seems wrong as I doubt this code will be in by > 1.2. What's the usual practice here? It seems it would make sense to make > a label for this branch and mark them as fixed with that label and then > when we actually release this in a version we can update all the JIRAs with > that label. > > Alan. > >
Re: Fix version for hbase-metastore branch
Also, what should we use for a documentation label? (HIVE-9606 <https://issues.apache.org/jira/browse/HIVE-9606> needs one.) TODOC labels are proliferating for all the releases and branches, but I don't think a generic TODOC label would be helpful. So what would be a good abbreviation for the hbase-metastore branch? Maybe TODOC-HBMETA? -- Lefty On Thu, Feb 19, 2015 at 7:12 PM, Alan Gates wrote: > Could someone with admin permissions on our JIRA add an > hbase-metastore-branch label? I'll take care of changing all the fix > versions for the few JIRA's we've already committed. Thanks. > > Alan. > > Ashutosh Chauhan > February 19, 2015 at 11:22 > This is what we have been doing for cbo work. e.g. > https://issues.apache.org/jira/browse/HIVE-9581 > > > Thejas Nair > February 19, 2015 at 11:17 > I agree, using a label for fix version makes sense in this case. I believe > that is what had been done for hive-on-spark and hive-on-tez. > > > > Alan Gates > February 19, 2015 at 10:56 > I've been marking JIRAs on this branch as fixed in 1.2, since that's the > next version. But that seems wrong as I doubt this code will be in by > 1.2. What's the usual practice here? It seems it would make sense to make > a label for this branch and mark them as fixed with that label and then > when we actually release this in a version we can update all the JIRAs with > that label. > > Alan. > >
Re: Fix version for hbase-metastore branch
Could someone with admin permissions on our JIRA add an hbase-metastore-branch label? I'll take care of changing all the fix versions for the few JIRA's we've already committed. Thanks. Alan. Ashutosh Chauhan <mailto:hashut...@apache.org> February 19, 2015 at 11:22 This is what we have been doing for cbo work. e.g. https://issues.apache.org/jira/browse/HIVE-9581 Thejas Nair <mailto:thejas.n...@gmail.com> February 19, 2015 at 11:17 I agree, using a label for fix version makes sense in this case. I believe that is what had been done for hive-on-spark and hive-on-tez. Alan Gates <mailto:alanfga...@gmail.com> February 19, 2015 at 10:56 I've been marking JIRAs on this branch as fixed in 1.2, since that's the next version. But that seems wrong as I doubt this code will be in by 1.2. What's the usual practice here? It seems it would make sense to make a label for this branch and mark them as fixed with that label and then when we actually release this in a version we can update all the JIRAs with that label. Alan.
Re: Fix version for hbase-metastore branch
This is what we have been doing for cbo work. e.g. https://issues.apache.org/jira/browse/HIVE-9581 On Thu, Feb 19, 2015 at 11:17 AM, Thejas Nair wrote: > I agree, using a label for fix version makes sense in this case. I believe > that is what had been done for hive-on-spark and hive-on-tez. > > > On Thu, Feb 19, 2015 at 10:56 AM, Alan Gates wrote: > > > I've been marking JIRAs on this branch as fixed in 1.2, since that's the > > next version. But that seems wrong as I doubt this code will be in by > > 1.2. What's the usual practice here? It seems it would make sense to > make > > a label for this branch and mark them as fixed with that label and then > > when we actually release this in a version we can update all the JIRAs > with > > that label. > > > > Alan. > > >
Re: Fix version for hbase-metastore branch
Looks like hive-on-tez and hive-on-spark didn't update the fix version after merge to trunk. But I think updating the fix version after merge makes sense. On Thu, Feb 19, 2015 at 11:17 AM, Thejas Nair wrote: > I agree, using a label for fix version makes sense in this case. I believe > that is what had been done for hive-on-spark and hive-on-tez. > > > On Thu, Feb 19, 2015 at 10:56 AM, Alan Gates wrote: > >> I've been marking JIRAs on this branch as fixed in 1.2, since that's the >> next version. But that seems wrong as I doubt this code will be in by >> 1.2. What's the usual practice here? It seems it would make sense to make >> a label for this branch and mark them as fixed with that label and then >> when we actually release this in a version we can update all the JIRAs with >> that label. >> >> Alan. >> > >
Re: Fix version for hbase-metastore branch
I agree, using a label for fix version makes sense in this case. I believe that is what had been done for hive-on-spark and hive-on-tez. On Thu, Feb 19, 2015 at 10:56 AM, Alan Gates wrote: > I've been marking JIRAs on this branch as fixed in 1.2, since that's the > next version. But that seems wrong as I doubt this code will be in by > 1.2. What's the usual practice here? It seems it would make sense to make > a label for this branch and mark them as fixed with that label and then > when we actually release this in a version we can update all the JIRAs with > that label. > > Alan. >
Fix version for hbase-metastore branch
I've been marking JIRAs on this branch as fixed in 1.2, since that's the next version. But that seems wrong as I doubt this code will be in by 1.2. What's the usual practice here? It seems it would make sense to make a label for this branch and mark them as fixed with that label and then when we actually release this in a version we can update all the JIRAs with that label. Alan.
Re: fix version
Thanks for doing all those updates, Ashutosh. -- Lefty On Sun, Mar 23, 2014 at 2:34 PM, Ashutosh Chauhan wrote: > Committers, > Please don't forget to update fix version of jiras when you are committing > patches. > > All, > Sorry about the deluge of emails updating fix version of jiras. That was > me. > > Thanks, > Ashutosh >
fix version
Committers, Please don't forget to update fix version of jiras when you are committing patches. All, Sorry about the deluge of emails updating fix version of jiras. That was me. Thanks, Ashutosh
Re: Please set the 'Fix Version(s)' field when resolving JIRA tickets
Good idea. Here's the ticket: https://issues.apache.org/jira/browse/INFRA-3386 Carl On Mon, Jan 24, 2011 at 1:39 PM, John Sichi wrote: > Should we create an INFRA ticket to require a fix version to be set before > an issue can be marked resolved/fixed? > > JVS > > On Jan 24, 2011, at 1:25 PM, Carl Steinbach wrote: > > > Committers: > > > > Please remember to set the 'Fix Versions(s)' field in JIRA when > > closing tickets. There are currently 116 tickets in JIRA marked > > resolved/fixed with no Fix version set. We need this information in > > order to generate release notes. > > > > Thanks for your help. > > > > Carl > >
Re: Please set the 'Fix Version(s)' field when resolving JIRA tickets
Should we create an INFRA ticket to require a fix version to be set before an issue can be marked resolved/fixed? JVS On Jan 24, 2011, at 1:25 PM, Carl Steinbach wrote: > Committers: > > Please remember to set the 'Fix Versions(s)' field in JIRA when > closing tickets. There are currently 116 tickets in JIRA marked > resolved/fixed with no Fix version set. We need this information in > order to generate release notes. > > Thanks for your help. > > Carl
Please set the 'Fix Version(s)' field when resolving JIRA tickets
Committers: Please remember to set the 'Fix Versions(s)' field in JIRA when closing tickets. There are currently 116 tickets in JIRA marked resolved/fixed with no Fix version set. We need this information in order to generate release notes. Thanks for your help. Carl
