Thanks Karthik for the comment.
Pros:
* (Probably) we can release 2.8.0 earlier.
* New feature in 2.8.0 will be available sooner.
* We can deprecate APIs sooner. After 2.8.0 is released, we can
remove them from trunk.
Cons:
* Maintenance cost becomes higher because # of branches becomes
I also like the idea of having a precommit build in Windows. If only the
pre-commit infrastructure was reliable. If this is a pain, I see little value
making Windows unit test failures release blockers.
Thanks,
Sent from my iPhone
> On Oct 28, 2016, at 8:16 AM, Allen Wittenauer
> wrote:
>
>
For more details, see
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-ppc/140/
No changes
-1 overall
The following subsystems voted -1:
compile unit
The following subsystems voted -1 but
were configured to be filtered/ignored:
cc javac
The following subsystems are con
For more details, see
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/210/
[Oct 29, 2016 8:17:39 AM] (varunsaxena) YARN-5773. RM recovery too slow due to
LeafQueue#activateApplications
[Oct 29, 2016 9:03:57 AM] (Arun Suresh) YARN-5799. Fix Opportunistic Allocation
to set the corr