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.
