Ajoy Bhatia created HADOOP-12246:
Summary: Apache Hadoop should be listed under "big-data" and
"hadoop" categories
Key: HADOOP-12246
URL: https://issues.apache.org/jira/browse/HADOOP-12246
Project: Ha
[
https://issues.apache.org/jira/browse/HADOOP-9882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Casile reopened HADOOP-9882:
-
I now have an opposite-ish problem I think. I followed all of the directions,
but now my protoc is
Gera Shegalov created HADOOP-12245:
--
Summary: References to misspelled REMAINING_QUATA in
FileSystemShell.md
Key: HADOOP-12245
URL: https://issues.apache.org/jira/browse/HADOOP-12245
Project: Hadoop
Allen Wittenauer created HADOOP-12244:
-
Summary: recover broken rebase?
Key: HADOOP-12244
URL: https://issues.apache.org/jira/browse/HADOOP-12244
Project: Hadoop Common
Issue Type: Sub-ta
Kengo Seki created HADOOP-12243:
---
Summary: Grep command used in test-patch and smart-apply-patch
should be GNU's one, not POSIX
Key: HADOOP-12243
URL: https://issues.apache.org/jira/browse/HADOOP-12243
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 or
incompatibilities as code changes.
--Chris Nauroth
On 7/16/15, 12:38 AM, "
On Jul 15, 2015, at 11:22 PM, Bruno P. Kinoshita
wrote:
>
> Good points. This layer between Jenkins and the unit tests seems useful.
Thanks!
We think so too! It’s why we’re working on pulling the code out of
Hadoop to make it more generalized for lots of different projects.
On Thu, Jul 16, 2015 at 10:42 AM, Sean Busbey wrote:
> On Thu, Jul 16, 2015 at 9:17 AM, Karthik Kambatla
> wrote:
>
> > On Thu, Jul 16, 2015 at 4:59 AM, Steve Loughran
> > wrote:
> >
> >
> > > -any change to the signature of an API, including exception types &
> text
> > > -changes to wire form
On Thu, Jul 16, 2015 at 9:17 AM, Karthik Kambatla
wrote:
> On Thu, Jul 16, 2015 at 4:59 AM, Steve Loughran
> wrote:
>
>
> > -any change to the signature of an API, including exception types & text
> > -changes to wire formats
> >
>
> These two should hold for minor releases also, no?
>
>
At the
On Thu, Jul 16, 2015 at 4:59 AM, Steve Loughran
wrote:
>
> 1. I agree that the bar for patches going in should be very high: there's
> always the risk of some subtle regression. The more patches, the higher the
> risk, the more traumatic the update
>
> 2. I like the idea of having a list of propo
+1 for steve's suggestion.
I agree completely that everything should be finalized before committing in.
-Vinay
On Jul 16, 2015 2:29 PM, "Steve Loughran" wrote:
>
> 1. I agree that the bar for patches going in should be very high: there's
> always the risk of some subtle regression. The more patc
1. I agree that the bar for patches going in should be very high: there's
always the risk of some subtle regression. The more patches, the higher the
risk, the more traumatic the update
2. I like the idea of having a list of proposed candidate patches, all of which
can be reviewed and discusse
Hi,
thank you for starting the discussion about 2.7.2 release.
> The focus obviously is to have blocker issues [2], bug-fixes and *no*
features / improvements.
I've committed YARN-3170, which is an improvement of documentation. I
thought documentation pages which can be fit into branch-2.7 can b
13 matches
Mail list logo
