My humble feeling is almost the same regarding the urgent need of a 3.0 alpha release.
Considering EC, shell-script rewriting and etc. are significant changes and there are interested users that want to evaluate EC storage method, an alpha 3.0 release will definitely help a lot allowing users to try the new features and then expose critical bugs or gaps. This may take quite some time, and should be very important to build confidence preparing for a solid 3.0 release. I understand Vinod's concern and the need of lining up the release efforts, so if it's to work on multiple 2.x releases it should be avoided. Mentioning 3.0 alpha, it's different and the best would be to allow parallel going to speed up EC and the like, meanwhile any 2.x release won't be in a hurry pushed by 3.0 release. Thanks for any consideration. Regards, Kai -----Original Message----- From: Andrew Wang [mailto:andrew.w...@cloudera.com] Sent: Friday, July 22, 2016 3:33 AM To: Vinod Kumar Vavilapalli <vino...@apache.org> Cc: common-dev@hadoop.apache.org; mapreduce-...@hadoop.apache.org; yarn-...@hadoop.apache.org Subject: Re: Setting JIRA fix versions for 3.0.0 releases I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible for downstreams to test incompat changes and new features without a release artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for an RC besides possibly this fix version issue. I'm not too worried about splitting community bandwidth, for the following reasons: * 3.0.0-alpha1 is very explicitly an alpha, which means no quality or compatibility guarantees. It needs less vetting than a 2.x release. * Given that 3.0.0 is still in alpha, there aren't many true showstopper bugs. Most blockers I see are also apply to both 2.x as well as 3.0.0. * 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. Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still have the issue of things committed for 2.9.0 that will be appearing for the first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs, it's only incrementally more work to also fix up 2.8 and other unreleased versions too. Best, Andrew On Thu, Jul 21, 2016 at 11:53 AM, Vinod Kumar Vavilapalli < vino...@apache.org> wrote: > The L & N fixes just went out, I’m working to push out 2.7.3 - running > into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0. > > Like I requested before in one of the 3.x threads, can we just line up > 3.0.0-alpha1 right behind 2.8.0? > > That simplifies most of this confusion, we can avoid splitting the > bandwidth from the community on fixing blockers / vetting these > concurrent releases. Waiting a little more for 3.0.0 alpha to avoid > most of this is worth it, IMO. > > Thanks > +Vinod > > > On Jul 21, 2016, at 11:34 AM, Andrew Wang <andrew.w...@cloudera.com> > wrote: > > > > Hi all, > > > > Since we're planning to spin releases off of both branch-2 and > > trunk, the changelog for 3.0.0-alpha1 based on JIRA information > > isn't accurate. This is because historically, we've only set 2.x fix > > versions, and 2.8.0 and > > 2.9.0 and etc have not been released. So there's a whole bunch of > > changes which will show up for the first time in 3.0.0-alpha1. > > > > I think I can write a script to (carefully) add 3.0.0-alpha1 to > > these JIRAs, but I figured I'd give a heads up here in case anyone > > felt differently. I can also update the HowToCommit page to match. > > > > Thanks, > > Andrew > > --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
