hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: Setting JIRA fix versions for 3.0.0 releases
Date Thu, 21 Jul 2016 22:58:18 GMT
Thanks for the input Vinod, inline:

> Similarly the list of features we are enabling in this alpha would be good
> - may be update the Roadmap wiki. Things like classpath-isolation which
> were part of the original 3.x roadmap are still not done.
> I already updated the website release notes at HADOOP-13383. I can update
the Roadmap wiki and break out what's new in alpha1 too, thanks for the

> > * Community bandwidth isn't zero-sum. This particularly applies to
> people working on features that are only present in trunk, like EC, shell
> script rewrite, etc.
> A bunch of us are going to be busy with finishing 2.8.0. It isn’t
> zero-sum, but it predicates those of us involved with 2.8.0 from looking at
> it, even though we are very interested in doing so.
> There's a plan for more 3.0.0 alphas, so there's still time to help out
before things settle down for beta. If 2.8.0 is ready to go, it should
happen before even alpha2.

> Obviously, I am not making the case that this issue won’t happen ever. In
> fact, this already happened with the parallel 2.6.x and 2.7.x releases. And
> we precisely avoided major confusion there by lining up 2.7.2 behind 2.6.3
> etc.

Could you clarify how lining up releases differently avoids the fix version

What we've been doing is something like "one fix version per active release
line". Since we've revived 3.x as a release line, it seems like a lot of
JIRAs need 3.x fix versions now.

As an aside, I honestly don't know how to interpret the fix version
instructions on the HowToCommit wiki. They don't seem to match up with what
we actually do in practice.


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