-1 for the record.
This is a great plan for 2.1, which I would gladly support, but not for
2.0.5.
I do not see how the previous vote could have been confusing,
as it contained a direct quotation of the relative clause of Bylaws.
Arun, the format of this vote remains confusing.
What is the action
Chris,
I find you are contradicting yourself within this message and with some
other of yours.
But I want to address only one thing here
> This has exposed a bug in our bylaws, which we can fix.
This could be a bug, and we may need to fix it. But until then it is a
bylaw,
which is the only rule
I am out of the office until 06/10/2013.
I am out of the office until 06/10/2013.
For any issues please contact Dispatcher:dispatcherdb...@us.ibm.com
Thanks.
Prabhat Pandey
Note: This is an automated response to your message "Re: [VOTE] - Release
2.0.5-beta" sent on 05/21/2013 0:27:51.
This
Jason Lowe created HADOOP-9583:
--
Summary: test-patch gives +1 despite build failure when running
tests
Key: HADOOP-9583
URL: https://issues.apache.org/jira/browse/HADOOP-9583
Project: Hadoop Common
Hi Folks
My name is Steve Watt and I am presently working on enabling glusterfs to be
used as a Hadoop FileSystem. Most of the work thus far has involved developing
a Hadoop FileSystem plugin for glusterfs. I'm getting to the point where the
plugin is becoming stable and I've been trying to und
Giridharan Kesavan created HADOOP-9584:
--
Summary: fix findbugs warnings
Key: HADOOP-9584
URL: https://issues.apache.org/jira/browse/HADOOP-9584
Project: Hadoop Common
Issue Type: Bug
Giridharan Kesavan created HADOOP-9585:
--
Summary: unit test failure
:org.apache.hadoop.fs.TestFsShellReturnCode.testChgrp
Key: HADOOP-9585
URL: https://issues.apache.org/jira/browse/HADOOP-9585
P
Giridharan Kesavan created HADOOP-9586:
--
Summary: unit test failure:
org.apache.hadoop.hdfs.TestFileCreation.testFileCreationSetLocalInterface
Key: HADOOP-9586
URL: https://issues.apache.org/jira/browse/HADOO
Giridharan Kesavan created HADOOP-9587:
--
Summary: unit test failure:
org.apache.hadoop.hdfs.server.balancer.TestBalancerWithNodeGroup.testBalancerWithRackLocality
Key: HADOOP-9587
URL: https://issues.apache.o
Giridharan Kesavan created HADOOP-9588:
--
Summary: unit test failure:
org.apache.hadoop.io.compress.TestCodec.testGzipLongOverflow
Key: HADOOP-9588
URL: https://issues.apache.org/jira/browse/HADOOP-9588
Hi all,
This has been a side topic in several email threads recently. Currently we
have an ambiguity. We have a tradition in the dev community that any
committer can create a branch, and propose release candidates from it. Yet
the Hadoop bylaws say that releases have to be planned in advance, th
I've now started a separate discussion thread in common-dev@, titled
"[PROPOSAL] change in bylaws to remove Release Plan vote". If it achieves
consensus, I'll put it to a vote to so change the bylaws.
Best,
--Matt
On Sat, May 18, 2013 at 4:22 PM, Chris Douglas wrote:
> The "release plan" vote
+1million
I completely agree with Chris D's separate email too about not
vote'ing about intentions, and voting on actual artifacts.
The fact of the matter at the ASF is that any PMC member; heck any
contributor can roll a release candidate. If that candidate receives
at least 3 PMC member +1s (to
Jian He created HADOOP-9589:
---
Summary: Extra master key is created when
AbstractDelegationTokenSecretManager is started
Key: HADOOP-9589
URL: https://issues.apache.org/jira/browse/HADOOP-9589
Project: Hadoo
+1
Thanks for taking care of this, Matt. -C
On Tue, May 21, 2013 at 2:10 PM, Matt Foley wrote:
> Hi all,
> This has been a side topic in several email threads recently. Currently we
> have an ambiguity. We have a tradition in the dev community that any
> committer can create a branch, and prop
+1
I've always found the Release Plan votes a bit bizarre, and the fact that
we've gone through many releases that did not have a corresponding Release
Plan vote suggest to me that we should just scrap them.
--
Aaron T. Myers
Software Engineer, Cloudera
On Tue, May 21, 2013 at 5:37 PM, Chris D
+1
On Tue, May 21, 2013 at 2:10 PM, Matt Foley wrote:
> Hi all,
> This has been a side topic in several email threads recently. Currently we
> have an ambiguity. We have a tradition in the dev community that any
> committer can create a branch, and propose release candidates from it. Yet
> t
+1
On Tue, May 21, 2013 at 2:48 PM, Suresh Srinivas wrote:
> +1
>
>
> On Tue, May 21, 2013 at 2:10 PM, Matt Foley wrote:
>
> > Hi all,
> > This has been a side topic in several email threads recently. Currently
> we
> > have an ambiguity. We have a tradition in the dev community that any
> >
+1
-Giri
On Tue, May 21, 2013 at 2:10 PM, Matt Foley wrote:
> Hi all,
> This has been a side topic in several email threads recently. Currently we
> have an ambiguity. We have a tradition in the dev community that any
> committer can create a branch, and propose release candidates from it.
+1
--
Arpit Gupta
Hortonworks Inc.
http://hortonworks.com/
On May 21, 2013, at 2:10 PM, Matt Foley wrote:
> Hi all,
> This has been a side topic in several email threads recently. Currently we
> have an ambiguity. We have a tradition in the dev community that any
> committer can create a bran
I see one significant benefit to having Release Plan votes: Fewer releases with
more members of the community working on any given release.
In turn, fewer Hadoop releases implies less confusion for end users attempting
to download and use an Apache Hadoop release.
If there are a dozen different
+1, thanks for taking the initiative on this Matt.
On May 21, 2013, at 2:10 PM, Matt Foley wrote:
> Hi all,
> This has been a side topic in several email threads recently. Currently we
> have an ambiguity. We have a tradition in the dev community that any
> committer can create a branch, and pr
+1 thanks Matt.
On Tue, May 21, 2013 at 2:10 PM, Matt Foley wrote:
> Hi all,
> This has been a side topic in several email threads recently. Currently we
> have an ambiguity. We have a tradition in the dev community that any
> committer can create a branch, and propose release candidates fro
+1 (non-binding)
On Tue, May 21, 2013 at 4:02 PM, Eli Collins wrote:
> +1 thanks Matt.
>
>
> On Tue, May 21, 2013 at 2:10 PM, Matt Foley wrote:
>
> > Hi all,
> > This has been a side topic in several email threads recently. Currently
> we
> > have an ambiguity. We have a tradition in the de
+1
On Tue, May 21, 2013 at 4:02 PM, Eli Collins wrote:
> +1 thanks Matt.
>
>
> On Tue, May 21, 2013 at 2:10 PM, Matt Foley wrote:
>
> > Hi all,
> > This has been a side topic in several email threads recently. Currently
> we
> > have an ambiguity. We have a tradition in the dev community th
+1 (non-binding)
On Tue, May 21, 2013 at 4:13 PM, Jitendra Pandey
wrote:
> +1
>
>
> On Tue, May 21, 2013 at 4:02 PM, Eli Collins wrote:
>
> > +1 thanks Matt.
> >
> >
> > On Tue, May 21, 2013 at 2:10 PM, Matt Foley wrote:
> >
> > > Hi all,
> > > This has been a side topic in several email thre
+1.
thanks
mahadev
On Tue, May 21, 2013 at 4:48 PM, Karthik Kambatla wrote:
> +1 (non-binding)
>
>
> On Tue, May 21, 2013 at 4:13 PM, Jitendra Pandey
> wrote:
>
>> +1
>>
>>
>> On Tue, May 21, 2013 at 4:02 PM, Eli Collins wrote:
>>
>> > +1 thanks Matt.
>> >
>> >
>> > On Tue, May 21, 2013 at 2:1
13/14 +1's. I think that constitutes consensus. Moving this to a VOTE
thread. Please repeat your +1s :-)
Cheers,
--Matt
On Tue, May 21, 2013 at 5:33 PM, Mahadev Konar wrote:
> +1.
>
> thanks
> mahadev
>
> On Tue, May 21, 2013 at 4:48 PM, Karthik Kambatla
> wrote:
> > +1 (non-binding)
> >
> >
Why repeat just tally new ones?
Sent from my iPhone
On May 21, 2013, at 6:58 PM, "Matt Foley" wrote:
> 13/14 +1's. I think that constitutes consensus. Moving this to a VOTE
> thread. Please repeat your +1s :-)
> Cheers,
> --Matt
>
>
> On Tue, May 21, 2013 at 5:33 PM, Mahadev Konar wrote:
>
Ok, if no one complains I will phrase the vote to include +1's explicitly
cast in the discussion thread.
--Matt
On Tue, May 21, 2013 at 6:58 PM, Mattmann, Chris A (398J) <
chris.a.mattm...@jpl.nasa.gov> wrote:
> Why repeat just tally new ones?
>
> Sent from my iPhone
>
> On May 21, 2013, at 6:58
This was previously discussed in the thread "[PROPOSAL] change in bylaws to
remove Release Plan vote". 13 people explicitly cast "+1"s in that thread.
Absent objection I will count those as votes without requiring them to
(re-)respond to this VOTE thread.
The following change is proposed in the
Hi Jagane,
since you did not explicitly cast a -1 or other numerical vote, please if
you wish go ahead and cast a vote in the VOTE thread.
Best regards,
--Matt
On Tue, May 21, 2013 at 3:47 PM, Jagane Sundar wrote:
> I see one significant benefit to having Release Plan votes: Fewer releases
> wi
+1.
-- Hitesh
On May 21, 2013, at 7:03 PM, Matt Foley wrote:
> This was previously discussed in the thread "[PROPOSAL] change in bylaws to
> remove Release Plan vote". 13 people explicitly cast "+1"s in that thread.
> Absent objection I will count those as votes without requiring them to
> (r
Ivan Mitic created HADOOP-9590:
--
Summary: Move to JDK7 improved APIs for file operations when
available
Key: HADOOP-9590
URL: https://issues.apache.org/jira/browse/HADOOP-9590
Project: Hadoop Common
Uri Laserson created HADOOP-9591:
Summary: Hadoop SnappyCodec (incorrectly?) uses block compression
Key: HADOOP-9591
URL: https://issues.apache.org/jira/browse/HADOOP-9591
Project: Hadoop Common
35 matches
Mail list logo
