I always used target version as "I hope to get this patch in by then". :D
On Sep 3, 2014, at 1:07 PM, Arpit Agarwal <aagar...@hortonworks.com> wrote: > Thanks, good to know. > > So in the spirit of simplification can we just eliminate the 'Target > Version' field from Jira? > > > On Wed, Sep 3, 2014 at 1:01 PM, Allen Wittenauer <a...@altiscale.com> wrote: > >> I was doing that too, but I went "to the source": >> >> https://wiki.apache.org/hadoop/HowToCommit says: >> >> "Resolve the issue as fixed, thanking the contributor. Always set the "Fix >> Version" at this point, but please only set a single fix version, the >> earliest release in which the change will appear. Special case- when >> committing to a non-mainline branch (such as branch-0.22 or branch-0.23 >> ATM), please set fix-version to either 2.x.x or 3.x.x appropriately too." >> >> i.e., a fix that will show up in 2.6.0 should be marked as Fix Version = >> 2.6.0 even if that change has been committed to trunk as well. Target >> version doesn't appear to have any documentation around it. (I think it's >> confusing because branch-0.22 was *not* considered a mainline branch even >> though it appears to be by first glance.) >> >> That said, I just yanked all the fix versions that were both 3.0 and 2.6 >> and marked them as 2.6. >> >> >> On Sep 3, 2014, at 12:51 PM, Arpit Agarwal <aagar...@hortonworks.com> >> wrote: >> >>> Allen, I think the correct field you are looking for is 'Target Version'. >>> If a fix is committed to both branch-2 and trunk, the fix version must >>> include both 2.x.0 and 3.0.0. However the target version would be 2.x.0 >> as >>> that is the earliest release that includes the fix. >>> >>> >>> On Wed, Sep 3, 2014 at 12:45 PM, Allen Wittenauer <a...@altiscale.com> >> wrote: >>> >>>> >>>> Figured it out. Basically can only do bulk fix version edits of one >>>> project at a time since the versions are technically different for every >>>> project. >>>> >>>> i.e.,: you can edit all of YARN-xxx, but you can not do YARN-xxx and >>>> HDFS-xxx together. FWIW, there are 372 issues that have a fixVersion >> for >>>> 3.0.0, counting both dupe and non-dupe. The first 200: >>>> >>>> >>>> >> https://issues.apache.org/jira/sr/jira.issueviews:searchrequest-printable/temp/SearchRequest.html?jqlQuery=project+in+%28MAPREDUCE%2C+YARN%2C+HADOOP%2C+HDFS%29+AND+fixVersion+%3D+3.0.0+AND+status+%3D+resolved&tempMax=200 >>>> >>>> Clearly need to filter on 'Fixed' as well, given duplicates and won't >>>> fixed and invalids listed w/a fix version as well. >>>> >>>> On Sep 3, 2014, at 12:10 PM, Allen Wittenauer <a...@altiscale.com> wrote: >>>> >>>>> >>>>> OK, it does, but only under certain conditions. Hmm. >>>>> >>>>> On Sep 3, 2014, at 12:04 PM, Allen Wittenauer <a...@altiscale.com> >> wrote: >>>>> >>>>>> >>>>>> >>>>>> Looks like the web UI doesn't allow for bulk change of Fix Version. >>>>>> >>>>>> *cries* >>>>>> >>>>>> On Sep 3, 2014, at 11:56 AM, Andrew Wang <andrew.w...@cloudera.com> >>>> wrote: >>>>>> >>>>>>> Allen, if you're willing to do the legwork, that'd be great. I feel >> we >>>>>>> should start by getting a JIRA script checked into dev-support that >>>>>>> generates a changelog for a release. We could then use that to make >>>> sure >>>>>>> the various fields are set properly for previous releases, remove >>>>>>> CHANGES.txt once we're confident, and then use said script to >> generate >>>> the >>>>>>> changelog for future releases. >>>>>>> >>>>>>> >>>>>>> On Wed, Sep 3, 2014 at 11:47 AM, Allen Wittenauer <a...@altiscale.com> >>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Sep 3, 2014, at 11:42 AM, Allen Wittenauer <a...@altiscale.com> >>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Sep 3, 2014, at 11:07 AM, Chris Douglas <cdoug...@apache.org> >>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> As long as release notes and incompatible changes are recorded in >>>> each >>>>>>>>>> branch, we gain no accuracy by maintaining this manually. Commit >>>>>>>>>> messages that record the merge revisions instead of the change are >>>>>>>>>> similarly hateful. -C >>>>>>>>> >>>>>>>>> We’ll also need to get much more strict about Fix Version really >> only >>>>>>>> listing the earliest version. Many of list (next release) + >> (trunk), >>>>>>>> myself included, which after looking through some of the commit >> docs, >>>> is >>>>>>>> not correct. >>>>>>>>> >>>>>>>>> I’m going to make it a point to go through JIRA today and fix my >>>>>>>> mistakes in this regard. >>>>>>>> >>>>>>>> >>>>>>>> Or, if we agree, I can bulk change them for everyone too. I think >>>> I’ve >>>>>>>> got the necessary JIRA search to locate dupe fix versions. >>>>>> >>>>> >>>> >>>> >>> >>> -- >>> CONFIDENTIALITY NOTICE >>> NOTICE: This message is intended for the use of the individual or entity >> to >>> which it is addressed and may contain information that is confidential, >>> privileged and exempt from disclosure under applicable law. If the reader >>> of this message is not the intended recipient, you are hereby notified >> that >>> any printing, copying, dissemination, distribution, disclosure or >>> forwarding of this communication is strictly prohibited. If you have >>> received this communication in error, please contact the sender >> immediately >>> and delete it from your system. Thank You. >> >> > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You.
