I'm not sure we qualify as a big user, but
FWIW, we are upgrading to a Hadoop based on 2.6.0
(
with our own application of critical bugfix patches that
went in on branch-2 later
) over at Salesforce.
2.7.0 and up are scary because 2.7.0 was tagged as not ready for
production. There's a
On Jun 26, 2015, at 3:35 PM, Andrew Wang andrew.w...@cloudera.com wrote:
Allen, do you still have these concerns? You mentioned having written
scripts to parse CHANGES.txt. I've written scripts for similar tasks, but
what I turned to were git log and JIRA, not CHANGES.txt. I was wondering if
+1 for ditching CHANGES.txt.
I reached out to Allen recently. He wanted to clean up his scripts more
before dropping CHANGES.txt altogether. Should we target 2.8 for this?
I read through our previous threads on this topic, and Allen had some
compatibility concerns about dropping CHANGES.txt
Thanks Tsuyoshi for the comment.
Targeting to 2.7 looks good to me, however, I'd like to maintenance
branch-2.6 also. It's only about a half year since 2.6.0 was released.
I don't want to abandon relatively new branches.
On 6/23/15 16:05, Tsuyoshi Ozawa wrote:
Thank you for clarification,
There's no reason we have to choose 2.6 xor 2.7. If we have willing RMs and
enough PMCs who will vote on releases, there's no reason we can't maintain
both.
However, based on the discussion at Hadoop Summit with Yahoo and Twitter,
their interest is primarily in 2.6, and Daryn mentioned the need
On Tue, Jun 23, 2015 at 10:30 AM, Andrew Wang andrew.w...@cloudera.com
wrote:
There's no reason we have to choose 2.6 xor 2.7. If we have willing RMs and
enough PMCs who will vote on releases, there's no reason we can't maintain
both.
However, based on the discussion at Hadoop Summit with
On Tue, Jun 23, 2015 at 12:30 PM, Andrew Wang andrew.w...@cloudera.com
wrote:
There's no reason we have to choose 2.6 xor 2.7. If we have willing RMs and
enough PMCs who will vote on releases, there's no reason we can't maintain
both.
However, based on the discussion at Hadoop Summit with
Thank you for clarification, Karthik.
I'd also like to work on stable release management with community.
I'm thinking of speedy release against next version - 1 branch for
making community feedback faster (e.g. current next version is 2.8, so
cherry-picking to 2.7 and releasing it are useful
Thanks Allen for reminding me of supporting JDK6. If 2.6 is the target,
any commmiter needs to check a bug fix patch when cherry-picking it.
For trunk, I'm thinking we need to decide what we should do for release
3.x, in another thread. I'm okay to discuss it again.
On 6/23/15 01:19, Allen
Thanks Karthik for the comment.
I'm +1 for your approach to ensure stability.
On 6/22/15 23:50, Karthik Kambatla wrote:
Thanks for starting this thread, Akira.
+1 to more maintenance releases. More stable upstream releases avoids
duplicating cherry-pick work across consumers/vendors, and shows
If 2.6 is the target, someone will have to verify that any
cherry-picked patches actually work with JDK6 since the PMC voted to officially
kill backward compatibility in a minor release. It’s going to be easier and
probably smarter to fix 2.7 if that’s really desired. [1]
+1 for the idea of maintenance releases.
Considering the amount code changes done in trunk and branch-2,
cherry-picking may not be easy and straight forward in all issues.
I would love to help in cherry-picking the fixes and reviewing them.
I would also love to help in release process.
Thanks for starting this thread, Akira.
+1 to more maintenance releases. More stable upstream releases avoids
duplicating cherry-pick work across consumers/vendors, and shows the
maturity of the project to users.
I see value in backporting blocker/critical issues, but have mixed feelings
about
Hi Akira,
Thank you for starting interesting topic. +1 on the idea of More
Maintenance Releases for old branches. It would be good if this
activity is more coupled with Apache Yetus for users.
BTW, I don't know one of committers, who is not PMC, can be a release
manager. Does anyone know about
Hi everyone,
In Hadoop Summit, I joined HDFS BoF and heard from Jason Lowe that
Apache Hadoop developers at Yahoo!, Twitter, and other non-distributors
work very hard to maintenance Hadoop by cherry-picking patches to their
own branches.
I want to share the work with the community. If we
+1 for creating a maintenance release with a more rapid release
cadence and more effort put into stability backports. I think this
would really be great for the project.
Colin
On Mon, Jun 22, 2015 at 2:43 AM, Akira AJISAKA
ajisa...@oss.nttdata.co.jp wrote:
Hi everyone,
In Hadoop Summit, I
More maintenance releases would be excellent.
If y'all are going to make more releases on the 2.6 line, please consider
backporting HADOOP-11710 as without it HBase is unusable on top of HDFS
encryption. It's been inconvenient that the fix is only available in a
non-production release line.
17 matches
Mail list logo
