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 "ma
On Jun 26, 2015, at 3:35 PM, Andrew Wang 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
> this is a relic from
>
> +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
On Tue, Jun 23, 2015 at 12:30 PM, Andrew Wang
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 Yahoo and Twitter,
> t
On Tue, Jun 23, 2015 at 10:30 AM, Andrew Wang
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 Yahoo and Twitter,
> t
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 to
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, Karth
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 Wi
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
Thank you for clarification, Karthik.
I'd also like to work on stable release management with community.
I'm thinking of speedy release against 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 work for users).
I
+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
wrote:
> Hi everyone,
>
> In Hadoop Summit, I joined HDFS BoF and heard
+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.
Regards
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]
Frank
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 do
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.
-Sea
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 th
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 can
17 matches
Mail list logo
