+1 (binding)
- downloaded both source and binary tarballs and verified the signatures
- set up a pseudo-distributed cluster
- ran some simple mapreduce jobs
- checked the basic web UI
Sangjin
On Wed, Jul 27, 2016 at 12:57 PM, John Zhuge wrote:
> +1 (non-binding)
>
> - Build source with Java 1.
Hi Junping, thanks for sharing your thoughts, inline,
On Wed, Jul 27, 2016 at 9:10 AM, 俊平堵 wrote:
> Thanks Vinod for bringing up this topic for discussion. I share the same
> concern here from my previous experience and I doubt some simple rules
> proposed below could make life easier.
>
> > The
>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
>> a.b.c versions, with alpha1 being the a.b.0 release.
>>
>
> Once 3.0.0 GA goes out, a user would want to see the diff from the latest
> 2.x.0 release (say 2.9.0).
>
> Are you suggesting 3.0.0 GA would have c = 5 (say)
+1 (binding)
- Downloaded binary tarball
- verified signatures
- setup pseudo cluster
- ran some of the example jobs, clicked around the UI a bit
- Robert
On Mon, Jul 25, 2016 at 3:28 PM, Jason Lowe
wrote:
> +1 (binding)
> - Verified signatures and digests- Built from source with native supp
Thanks Vinod for bringing up this topic for discussion. I share the same
concern here from my previous experience and I doubt some simple rules
proposed below could make life easier.
> The question now is what we do for the 2.8.0 and 3.0.0-alpha1 fix
versions.
> Allen's historical perspective is t
For more details, see
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/115/
[Jul 26, 2016 1:30:02 PM] (stevel) Revert "HDFS-10668. Fix intermittently
failing UT
[Jul 26, 2016 1:53:37 PM] (kai.zheng) HADOOP-13041. Adding tests for coder
utilities. Contributed by Kai
[Jul 26, 2016 3
Inline.
> 1) Set the fix version for all a.b.c versions, where c > 0.
> 2) For each major release line, set the lowest a.b.0 version.
>
Sounds reasonable.
>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> a.b.c versions, with alpha1 being the a.b.0 release.
>
Once
Hi All
+1 (non-binding)
- Compiled and created tar ball from source
- Tested few MR jobs with node labels
- Verified UI
Thanks
Sunil
On Sat, Jul 23, 2016 at 7:45 AM Vinod Kumar Vavilapalli
wrote:
> Hi all,
>
> I've created a release candidate RC0 for Apache Hadoop 2.7.3.
>
> As discussed before
+1 for the source tarball.
- Compiled and built from the source code
- Deployed a cluster
- Successfully ran some sample jobs.
Thanks,
Jian
> On Jul 27, 2016, at 10:11 AM, Akira Ajisaka
> wrote:
>
> +1 for the source tarball.
>
> - Downloaded source tarball and binary tarball
> - Verified si
Thanks Andrew for sharing your thoughts,
It looks better if we can put multiple versions on the fix version, with
that we can at least do some queries on JIRA to check the issues like "in
branch-2.6.5 but not in branch-2.7.4".
I still have a couple of questions:
*1) How CHANGES.txt (or release n
> I think I understand a bit better, though now I ask how this date is
> different from the release date.
OIC. I also assume that the freezing branch cannot include the changes
between freezing date and the release date. This is for strict
ordering to ensure which is the newer. If we have lots ma
11 matches
Mail list logo
