Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
HDFS >> mail # dev >> [Proposal] Pluggable Namespace

Milind Bhandarkar 2013-10-03, 19:17
Bobby Evans 2013-10-04, 15:31
Andrew Purtell 2013-10-05, 18:23
Milind Bhandarkar 2013-10-05, 19:37
Azuryy Yu 2013-10-06, 01:40
Milind Bhandarkar 2013-10-06, 16:35
Vinod Kumar Vavilapalli 2013-10-06, 19:20
Milind Bhandarkar 2013-10-06, 19:54
Milind Bhandarkar 2013-10-07, 00:58
Mahadev Konar 2013-10-07, 03:04
Bobby Evans 2013-10-07, 15:52
Milind Bhandarkar 2013-10-07, 17:18
Chris Nauroth 2013-10-07, 16:44
Milind Bhandarkar 2013-10-07, 17:11
Doug Cutting 2013-10-07, 18:15
Andrew Purtell 2013-10-07, 19:05
Vinod Kumar Vavilapalli 2013-10-07, 19:42
Milind Bhandarkar 2013-10-07, 19:49
Copy link to this message
Re: [Proposal] Pluggable Namespace
On Mon, Oct 7, 2013 at 12:05 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
> I recognize some of what we recently experienced on a HDFS matter in what
> Milind wrote even if this was not the appropriate forum for it. Odd mention
> of "conspiracy theories" aside, for people who may come to this thread
> later, perhaps you can recommend an appropriate public Apache community
> forum for discussing such concerns?

I'm not exactly sure what "such concerns" are, but I'll guess that
you're worried that someone else has plans that conflict with yours
yet they're not stating that publicly.  Is that right?

We cannot ensure that everyone's contributions are equally loved by
everyone else.  Some people's contributions may sometimes conflict
with plans of others.  (I have no idea whether that's the case here.)
Making a proposal is a good way to inquire about this.  Directly
accusing one group of implied opposition is probably

We try to ensure that every contribution is given a fair discussion in
public and that it is weighed on its technical merit alone.  If a
proposal conflicts with some other not-yet-public plan then it's up to
the not-public planners to voluntarily make themselves public and try
to reach some compromise.  We don't permit vetoes without technical
justification, and the benefit of the doubt is generally given to
those with code in hand.  So there's little benefit in worrying about
what folks aren't saying.

The best practice is to first start a discussion around a proposal,
often incorporating feedback from the discussion into the proposal.
Then, barring fundamental objections to the proposal, contribute code
that implements it.  Ideally that code can be developed in public.  It
would be poor behavior for someone present at the proposal stage to
raise an easily-foreseen fundamental objection in the implementation

Does that help?  Can we please return to discussing the proposal?

Milind Bhandarkar 2013-10-07, 23:50
Konstantin Shvachko 2013-10-08, 02:40
sanjay Radia 2013-10-07, 19:31
sanjay Radia 2013-10-08, 04:50
Milind Bhandarkar 2013-10-08, 17:13