Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of tucu@cloudera.com designates
 209.85.223.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAFY_u4r96YPer9Xtkh1c5HFdRbPch4vQ9-cJLUZsJP11f6AvmQ@mail.gmail.com>
References: 
 <CAJs-t7PvE+ORDwuav6NPW95fvK2vcxnG5JzB4F+QiSS9g4OeFQ@mail.gmail.com>
 <8BFFEEA2-E037-4C77-82F9-7A6CD63ECA3D@apache.org>
 <DBB4F039-2AD4-432C-B506-C90B1C7553A3@hortonworks.com>
 <CAFY_u4r96YPer9Xtkh1c5HFdRbPch4vQ9-cJLUZsJP11f6AvmQ@mail.gmail.com>
From: Alejandro Abdelnur <tucu@cloudera.com>
Date: Thu, 11 Apr 2013 05:35:43 -0700
Message-ID: 
 <CAJs-t7MGZJHQ1k0XT-21WuhzC841-_pD15jOr9fnb6nW1ZtGxg@mail.gmail.com>
Subject: Re: CHANGES.txt out of sync in the different branches
To: "mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>
Cc: "common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=089e013a286a3da5a004da1508cc

--089e013a286a3da5a004da1508cc
Content-Type: text/plain; charset=ISO-8859-1

Thanks for taking care of this Sid.

Agree that using jira fix versions would be easier as a way to generate the
changes. It would require some proper handling by the committer. For
example, if something is committed to trunk(3.0.0) and branch-2(2.0.5) it
would have fixedVersion 2.0.5, if later it is backported to a soon to be
release 2.0.4, the fixVersion must be updated to 2.0.4. Another scenario is
when you have different release lines, i.e 1.x and 2.x (or 2.0.x and
2.1.x), then the fixVersion should contain each line version.

Still, IMO, much better than dealing with CHANGES.txt in different branches.

Thanks again


On Thu, Apr 11, 2013 at 12:44 AM, Siddharth Seth
<seth.siddharth@gmail.com>wrote:

> I went ahead and committed a couple of changes to trunk and branch-2 to fix
> the MR CHANGES.txt mess.  Alexandro, I believe there's a couple of jiras
> where you were waiting for CHANGES.txt fixes before merging to branch-2.
> Not sure about past discussions, but can we re-visit removing CHANGES.txt
> in favour of jira fix versions.
>
> While we maintain this file, a couple of points to prevent this ...
> - For changes that go into 0.23, the CHANGES.txt entry needs to be included
> under the 2.x line as well since 2.x and 0.23 are on a different release
> schedule.
> - When merging into a branch, please update CHANGES.txt on the src branch
> as well. trunk was out of sync on a lot of CHANGES which have gone into
> 2.0.5.
> - Something going wrong with these files isn't always discovered
> immediately, but adds up fast - so a little extra caution with changes,
> merge-conflicts etc on these files...
>
> There's jiras like MAPREDUCE-4790, for which the fix version on jira is
> trunk-win, but the patch is already in trunk. Does fix version trunk-win
> imply the patch is in trunk as well ?
>
> Thanks
> - Sid
>
>
> On Wed, Apr 3, 2013 at 3:02 PM, Vinod Kumar Vavilapalli <
> vinodkv@hortonworks.com> wrote:
>
> > I started looking at this yesterday, MAPREDUCE CHANGES.txt is completely
> > broken. I'll try to fix it and then send out a note once I am done.
> >
> > Thanks,
> > +Vinod
> >
> > On Apr 1, 2013, at 11:46 PM, Vinod Kumar Vavilapalli wrote:
> >
> > >
> > > I've been looking at YARN and it seems to be fine. I presume common and
> > hdfs too.
> > >
> > > MR clearly has issues. Have to manually fix it. Will do something
> > tomorrow first thing.
> > >
> > > Thanks,
> > > +Vinod Kumar Vavilapalli
> > >
> > > On Apr 1, 2013, at 3:53 PM, Alejandro Abdelnur wrote:
> > >
> > >> while trying to commit MAPREDUCE-5113 to branch-2 I've noticed that
> the
> > >> CHANGES.txt are out of sync. Commit message are on the wrong releases.
> > >>
> > >> I've spent some some time trying to fix it, but I did not find it
> > straight
> > >> forward to do so.
> > >>
> > >> I assume the same may be true for common, hdfs and yarn.
> > >>
> > >> I know why we use CHANGES.txt files has been discussed in the past, so
> > I'll
> > >> not raise a suggestion to get rid of them.
> > >>
> > >> Does anybody has a simple list of steps to fix this ?
> > >>
> > >> Thx
> > >>
> > >> --
> > >> Alejandro
> > >
> >
> >
>


-- 
Alejandro

--089e013a286a3da5a004da1508cc--