Mailing-List: contact yarn-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CAGB5D2aKG5RewQ3tBi5-b=j6nZOsQDoVPkwwdfJOxS=70bkebQ@mail.gmail.com>
References: <CAGB5D2YN=rtVZ6yB7ZDXncv5oY0+6GKguRc=0wo+hMrQQJ6zDA@mail.gmail.com>
 <666A8BE9-1F45-4407-ADD3-84E57931808C@apache.org> <CAGB5D2Z+TAVKRkOC+TGJhe7TbCgHVgm0p=0ySm+ApwcB5KahGQ@mail.gmail.com>
 <73918F59-AC57-485D-B217-C026E168EB2A@apache.org> <CAGB5D2bVG2S6CYxiWfW65yhaLvvYeQ74zMK97v-ESeBRE8gC-w@mail.gmail.com>
 <CADbBEnvy8c01jn00-V=at5ECLCu4-ge=y=C2EVgJp5dw+pw2Hw@mail.gmail.com>
 <CAGB5D2bXwMm8CP5nzPW57EiZUe4wM=RA9L3uyfRGuZbRRpVVWA@mail.gmail.com>
 <553D4F53-FFB3-4BD3-A641-2C95D26E3F99@effectivemachines.com>
 <CAGB5D2bQc5D0jGyfe8EwbdqwhN-BUdLJeyZ2e-vygaxMxn36Yw@mail.gmail.com>
 <7728F953-8A07-4422-AA15-6CBAF8E930E1@effectivemachines.com> <CAGB5D2aKG5RewQ3tBi5-b=j6nZOsQDoVPkwwdfJOxS=70bkebQ@mail.gmail.com>
From: Wangda Tan <wheeleast@gmail.com>
Date: Mon, 25 Jul 2016 17:57:16 -0700
Message-ID: <CAD++eCk=8oz9Rjb-dcOFBLE8TTek9bzOQ6M+XaWwC2bKKpHkVA@mail.gmail.com>
Subject: Re: Setting JIRA fix versions for 3.0.0 releases
To: Andrew Wang <andrew.wang@cloudera.com>
Cc: Allen Wittenauer <aw@effectivemachines.com>,
	"common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>,
	"mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>,
	"yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=94eb2c0af9fc914b3205387f631e
archived-at: Tue, 26 Jul 2016 00:57:57 -0000

--94eb2c0af9fc914b3205387f631e
Content-Type: text/plain; charset=UTF-8

Hi Andrew,
Please wait updating fix version for branch-2 committed tickets before we
get a consensus on this. Updating fix versions for them could bring lots of
troubles for on going two releases (2.7.3 / 2.8.0).

Thanks,
Wangda

On Mon, Jul 25, 2016 at 11:02 AM, Andrew Wang <andrew.wang@cloudera.com>
wrote:

> If I don't hear otherwise, I'd like to go ahead and do the bulk fix version
> update on JIRA for 3.0.0-alpha1, diffing from 2.7.0. Will wait until EOD
> tomorrow in case there's more discussion. If any one is willing to help
> review my script and JIRA queries, that'd also be great.
>
> I can also do the 2.8.0 bulk update (diffing from 2.7.0), since it should
> be a very similar process.
>
> Best,
> Andrew
>
>
> On Fri, Jul 22, 2016 at 9:50 PM, Allen Wittenauer <
> aw@effectivemachines.com>
> wrote:
>
> >
> > > On Jul 22, 2016, at 7:16 PM, Andrew Wang <andrew.wang@cloudera.com>
> > wrote:
> > >
> > > Does this mean you find our current system of listing a JIRA as being
> > fixed in both a 2.6.x and 2.7.x to be confusing?
> >
> >         Nope.  I'm only confused when there isn't a .0 release in the fix
> > line.  When I see 2.6.x and 2.7.x I know that it was back ported to those
> > branches.  If I don't see a .0, I figure it's either a mistake or
> something
> > that was already fixed by another change in that major/minor branch.
> It's
> > almost always the former, however.
> >
> > > FWIW, my usecase is normally not "what is the earliest release that has
> > this fix?" but rather "is this fix in this release?". If it's easy to
> query
> > the latter, you can also determine the former. Some kind of query tool
> > could help here.
> >
> >         It literally becomes a grep if people commit the release data
> into
> > the source tree, the release data is correct, etc:
> >
> > $ mvn install site  -Preleasedocs -Pdocs -DskipTests
> > $ grep issueid
> > hadoop-common-project/hadoop-common/src/site/markdown/release/*/CHANGES*
> >
> >         We should probably update the release process to make sure that
> > *in progress* release data is also committed when a .0 is cut.  That's
> > likely missing. Another choice would be to modify the pom to that runs
> > releasedocmaker to use a range rather than single version, but that gets
> a
> > bit tricky with release dates, how big of a range, etc.  Not impossible,
> > just tricky.  Probably needs to be script that gets run as part of
> > create-release, maybe?
> >
> >         (In reality, I do this grep against my git repo that generates
> the
> > change log data automatically.  This way it is always up-to-date and not
> > dependent upon release data being committed.  But that same grep could be
> > done with a JQL query just as easily.)
> >
> > > For the release notes, am I correct in interpreting this as:
> > >
> > > * diff a.0.0 from the previous x.y.0 release
> > > * diff a.b.0  from the previous a.0.0 or a.b.0 release
> > > * diff a.b.c from the previous a.b.0 or a.b.c release
> >
> >         Pretty much yes.
> >
> > > Ray pointed me at the changelogs of a few other enterprise software
> > products, and this strategy seems pretty common. I like it.
> >
> >         It's extremely common, to the point that putting every fix for
> > every release touched is, at least to me, weird and extremely
> > unconventional.
> >
> > > I realize now that this means a lot more JIRAs will need the 2.8.0 fix
> > version, since they only have 2.6.x and 2.7.x.
> >
> >         Yup.
> >
> > >   This makes the fix rules actually pretty easy:  the lowest a.b.0
> > release and all non-.0 releases.
> > >
> > > I think this needs to be amended to handle the case of multiple major
> > release branches, since we could have something committed for both 2.9.0
> > and 3.1.0. So "lowest a.b.0 release within each major version"?
> >
> >         Yeah, switching to effectively trunk-based development makes the
> > rules harder.  It's one of the reasons why the two big enterprisey
> > companies I worked at prior to working on Hadoop didn't really do
> > trunk-based for the vast majority of projects.  They always cut a branch
> > (or equivalent for that SCM) to delineate a break.   Given the amount of
> > ex-Sun folks involved in the early days of Hadoop, our pre-existing
> > development processes very much reflect that culture.
> >
> > > This was true previously (no releases from trunk, trunk is versioned
> > a.0.0), but now that trunk is essentially a minor release branch, its fix
> > version needs to be treated as such.
> >
> >         Yeah, I misspoke a bit when dealing with a head-of-tree model.
> > 3.0.0-alpha1 will generate different notes than 3.0.0-alpha2, obviously.
> > Every 3.0.0-(label) release is effectively a major version in that case.
> >
> >
> >
>

--94eb2c0af9fc914b3205387f631e--