hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arpit Agarwal <aagar...@hortonworks.com>
Subject Re: migrating private branches to the new git repo
Date Wed, 03 Sep 2014 19:51:43 GMT
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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message