I see 18 JIRAs across the sub-projects as of now in 2.6.3. Seems like we will
have a reasonable number of fixes if we start an RC early december.
In the mean while, we should also review 2.7.3 and 2.8.0 blocker / critical
list and see if it makes sense to backport any of those into 2.6.3.
+Vino
Please ignore this reply, was supposed to be a nudge on internal lists.
+Vinod
On Nov 11, 2015, at 1:15 PM, Vinod Vavilapalli
mailto:vino...@hortonworks.com>> wrote:
Started a thread on 2.8.0. Please give feedback etc. I’ll need help from both
the teams to get this done right.
trunk as 3.x instead of pushing 2.8? There are many new
features (EC, Y1197, etc.), and trunk could be the source of several
alpha/beta releases before we fork the 3.x line. -C
On Sat, Sep 26, 2015 at 12:49 PM, Vinod Vavilapalli
mailto:vino...@hortonworks.com>> wrote:
As you may have noted
I’ll let others comment on specific features.
Regarding the 3.x vs 2.x point, as I noted before on other threads, given all
the incompatibilities in trunk it will be ways off before users can run their
production workloads on a 3.x release. Therefore, as I was proposing before, we
should contin
wrote:
With two active sustaining branches (2.6, 2.7), what would you think
of releasing trunk as 3.x instead of pushing 2.8? There are many new
features (EC, Y1197, etc.), and trunk could be the source of several
alpha/beta releases before we fork the 3.x line. -C
On Sat, Sep 26, 2015 at 12:4
Just committed the last of the critical issues. Starting the release process
now.
Thanks
+Vinod
On Nov 3, 2015, at 3:24 PM, Vinod Kumar Vavilapalli
mailto:vino...@hortonworks.com>> wrote:
I’m closing down 2.7.2 now, almost there.
Created a new branch-2.7.2 for the release so that any 2.7.3 pa
@intel.com]
>>> Sent: Tuesday, November 03, 2015 5:41 AM
>>> To: hdfs-dev@hadoop.apache.org
>>> Subject: Re: Erasure coding in branch-2 [Was Re: [VOTE] Merge
>>> HDFS-7285 (erasure coding) branch to trunk]
>>>
>>> +1 for EC to go into 2.
I’m closing down 2.7.2 now, almost there.
Created a new branch-2.7.2 for the release so that any 2.7.3 patches can go
into branch-2.7 directly.
Please reach out to me if you have any questions.
Thanks
+Vinod
On Nov 2, 2015, at 2:15 PM, Vinod Kumar Vavilapalli
mailto:vino...@hortonworks.com>>
Feel free to go ahead and get this in, I am still waiting on a couple of other
JIRAs.
Thanks
+Vinod
On Nov 2, 2015, at 12:24 AM, Wangda Tan
mailto:wheele...@gmail.com>> wrote:
I marked YARN-3136 to 2.7.2-candidate, and I suggest to delay other changes to
2.8.0 release.
Got this count a bit wrong:
- There are 13 tickets marked against 2.7.2 but only committed to 2.8.0
- There are 10 tickets resolved without a patch - duplicates / invalids etc.
- There are 77 patches marked and committed to 2.7.2.
- There are a whole bunch of unresolved tickets in that 112 patc
Yes, I’ve already started looking at 2.8.0, that is exactly how I ended up with
this discussion on the state of EC.
+Vinod
On Nov 2, 2015, at 3:02 PM, Haohui Mai
mailto:ricet...@gmail.com>> wrote:
Is it a good time to start the discussion on the issues of releasing 2.8?
We are down to 4 now (https://issues.apache.org/jira/issues/?filter=12332867),
appreciate help moving forward with them.
Thanks
+Vinod
On Oct 26, 2015, at 11:34 AM, Vinod Kumar Vavilapalli
mailto:vino...@hortonworks.com>> wrote:
Got swamped again.
We already have about 112 patches in 2.7.2 al
Forking the thread. Started looking at the 2.8 list, various features’ status
and arrived here.
While I understand the pervasive nature of EC and a need for a significant
bake-in, moving this to a 3.x release is not a good idea. We will surely get a
2.8 out this year and, as needed, I can even
Just to stress on the following, it is very important that any critical
bug-fixes that we push into 2.8.0 or even trunk, we should consider them for
2.6.3 and 2.7.3 if it makes sense. This is the only way we can avoid extremely
long release cycles like that of 2.6.1.
Also, to clarify a little,
Hi,
I checked 2.6.2-RC0, based on my check-list:
- Signatures and message digests all are good in general.
- The top level full LICENSE, NOTICE and README for the source artifacts are
good - CHANGES.txt for common, hdfs and mapped are correctly located.
- Able to build the tars out of the sou
ill be nice if Ming can
>> chime in.
>> Kihwal
>>
>> From: Tsuyoshi Ozawa
>> To: "common-...@hadoop.apache.org"
>> Cc: Chris Nauroth ; "yarn-...@hadoop.apache.org"
>> ; "hdfs-dev@hadoop.apache.org"
>> ; "
backport not only bug fixes but
> also documentations(I think 2.7.2 includes them). It helps users a lot.
>
> Best,
> - Tsuyoshi
>
> On Tuesday, 27 October 2015, Vinod Vavilapalli
> wrote:
>
>> +1.
>>
>> Thanks
>> +Vinod
>>
>>>
This is done: https://dist.apache.org/repos/dist/release/hadoop/common/KEYS is
updated with Sangjin’s keys now.
Thanks
+Vinod
On Oct 26, 2015, at 2:06 PM, Vinod Kumar Vavilapalli
mailto:vino...@hortonworks.com>> wrote:
I will get his KEYS committed right-away
I was helping Sangjin offline with the release.
We briefly discussed the KEYS problem before, but it missed my attention.
I will get his KEYS committed right-away, the release is testable right away
though.
Regarding the voting period, let’s continue voting for two more days, the
period also h
Got swamped again.
We already have about 112 patches in 2.7.2 already.
There are 15 open tickets in progress. I’ll push progress on them for an RC
towards end of this week.
Thanks
+Vinod
On Sep 25, 2015, at 3:27 PM, Vinod Kumar Vavilapalli
mailto:vino...@apache.org>> wrote:
Hi all,
We relea
+1.
Thanks
+Vinod
> On Jul 16, 2015, at 8:18 AM, Chris Nauroth wrote:
>
> I'd be comfortable with inclusion of any doc-only patch in minor releases.
> There is a lot of value to end users in pushing documentation fixes as
> quickly as possible, and they don't bear the same risk of regressions o
If you see the community discussion thread on 2.8, my proposal was to support
*both* JDK 7 and JDK 8 first. The last time we had discussion about dropping
JDKs it wasn’t fun, so let’s not go there for now.
In terms of runtime support for JDK 8, yes, there is vast evidence that things
already wo
As you may have noted, 2.8.0 got completely derailed what with 2.7.x and the
unusually long 2.6.1 release.
With 2.6.1 out of the way, and two parallel threads in progress for 2.6.2 and
2.7.2, it’s time for us to look back at where we are with Hadoop 2.8.
I’ll do a quick survey of where the indi
The website and mirrors updates came back. Sending out an announcement now.
Thanks
+Vinod
On Sep 23, 2015, at 4:59 PM, Vinod Kumar Vavilapalli
mailto:vino...@hortonworks.com>> wrote:
Done with all the release activities. Waiting for the bits to propagate to all
the mirrors.
Thanks
+Vinod
On
+1. Please take it over, I’ll standby for any help needed.
Thanks
+Vinod
On Sep 24, 2015, at 11:34 AM, Sangjin Lee
mailto:sj...@apache.org>> wrote:
I'd like to volunteer as the release manager for 2.6.2 unless there is an
objection.
Done with all the release activities. Waiting for the bits to propagate to all
the mirrors.
Thanks
+Vinod
On Sep 23, 2015, at 1:18 PM, Vinod Kumar Vavilapalli
mailto:vino...@hortonworks.com>> wrote:
Here’s my +1 to conclude the vote.
With 5 binding +1s (Xuan, Jian, Junping, Karthik, myself),
Here’s my +1 to conclude the vote.
With 5 binding +1s (Xuan, Jian, Junping, Karthik, myself), 8 non-binding +1s
(Wangda, Sanjin, Rohith, Brahma, Mit, Akira, Tsuyoshi, Masatake ), 4
non-committal yes’s (Ted, Eric, Chang, Kuhu), this vote passes.
I’ll push out the bits.
Thanks to everyone who vo
I’ve been out sick for a while, so couldn’t close this in time. Doing so now.
+Vinod
On Sep 16, 2015, at 7:10 PM, Vinod Kumar Vavilapalli
mailto:vino...@apache.org>> wrote:
Hi all,
After a nearly month long [1] toil, with loads of help from Sangjin Lee and
Akira Ajisaka, and 153 (RC0)+7(RC1)
Tx Eric, given the long cycle for 2.6.1, I’ll put MAPREDUCE-6334 into 2.6.2.
Thanks
+Vinod
On Sep 21, 2015, at 11:19 AM, Eric Payne
mailto:eric.payne1...@yahoo.com>> wrote:
Hi Vinod and everyone else who helped on this release!
Thank you very much for going through the work and effort to put t
Thanks for the verification Nick!
Regarding that one issue, we saw this before itself in 2.7 and deemed it to be
a compatible change given the expected usage of the API. The error in your
report is “a client class C is not abstract and does not override abstract
method in ApplicationBaseProtoco
30 matches
Mail list logo
