hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@altiscale.com>
Subject Re: migrating private branches to the new git repo
Date Wed, 03 Sep 2014 20:09:21 GMT

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 <aagarwal@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 <aw@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 <aagarwal@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 <aw@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 <aw@altiscale.com> wrote:
>>>> 
>>>>> 
>>>>> OK, it does, but only under certain conditions. Hmm.
>>>>> 
>>>>> On Sep 3, 2014, at 12:04 PM, Allen Wittenauer <aw@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.wang@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 <aw@altiscale.com>
>>>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> On Sep 3, 2014, at 11:42 AM, Allen Wittenauer <aw@altiscale.com>
>>>> wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Sep 3, 2014, at 11:07 AM, Chris Douglas <cdouglas@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.


Mime
View raw message