I think the PMC should abandon the fuse-dfs HDFS contrib component.  It's last meaningful contribution was March 2010:

HDFS-961. dfs_readdir incorrectly parses paths. Contributed by Eli Collins.

There are 18 unresolved contrib/fuse-dfs issues in Jira, none of them Patch Available.

Here is my +1.

Nige

I am guessing that this is in moderate use by people and seems like a useful
thing. I do not use it myself.

-dhruba

On Thu, Feb 10, 2011 at 6:58 PM, Nigel Daley <[EMAIL PROTECTED]> wrote:

> I think the PMC should abandon the fuse-dfs HDFS contrib component.  It's
> last meaningful contribution was March 2010:
>
> HDFS-961. dfs_readdir incorrectly parses paths. Contributed by Eli Collins.
>
> There are 18 unresolved contrib/fuse-dfs issues in Jira, none of them Patch
> Available.
>
> Here is my +1.
>
> Nige
>
>
--
Connect to me at http://www.facebook.com/dhruba

+1 on punting it.  Its a drag on core.  Move it elsewhere.
St.Ack
On Thu, Feb 10, 2011 at 6:58 PM, Nigel Daley <[EMAIL PROTECTED]> wrote:
> I think the PMC should abandon the fuse-dfs HDFS contrib component.  It's last meaningful contribution was March 2010:
>
> HDFS-961. dfs_readdir incorrectly parses paths. Contributed by Eli Collins.
>
> There are 18 unresolved contrib/fuse-dfs issues in Jira, none of them Patch Available.
>
> Here is my +1.
>
> Nige
>
>

On Thu, Feb 10, 2011 at 6:58 PM, Nigel Daley <[EMAIL PROTECTED]> wrote:

> I think the PMC should abandon the fuse-dfs HDFS contrib component.  It's
> last meaningful contribution was March 2010:
>

I think we should hold on to this one until there is a reasonable
replacement. -1

-- Owen

On Feb 10, 2011, at 9:22 PM, Owen O'Malley wrote:

> On Thu, Feb 10, 2011 at 6:58 PM, Nigel Daley <[EMAIL PROTECTED]> wrote:
>
>> I think the PMC should abandon the fuse-dfs HDFS contrib component.  It's
>> last meaningful contribution was March 2010:
>>
>
> I think we should hold on to this one until there is a reasonable
> replacement. -1

If a reasonable replacement was developed elsewhere, would you change your vote?  I believe some folks were interested in developing this elsewhere.

Nige

On Thu, Feb 10, 2011 at 9:57 PM, Nigel Daley <[EMAIL PROTECTED]> wrote:

If a reasonable replacement was developed elsewhere, would you change your
> vote?  I believe some folks were interested in developing this elsewhere.
>

It would depend. As I have said before, our goal as a PMC is to produce
useful Hadoop releases. Pulling out functionality that users require makes
the Hadoop releases less useful. Making users go to 20 different sites to
download compatible versions of the different components, although it helps
aggregating companies like RedHat, is an anti-goal.

That said, if projects are active enough splitting them out into other
Apache projects makes sense. Chukwa, HBase, Hive, Hive, Pig, and Zookeeper
are wonderful examples of related projects where we've moved them out of
Hadoop and their communities are healthier for the move. Moving actively
used components into non-Apache managed projects, including Apache Extras,
is an anti-goal.

-- Owen

On Feb 11, 2011, at 7:33 AM, Owen O'Malley wrote:

> On Thu, Feb 10, 2011 at 9:57 PM, Nigel Daley <[EMAIL PROTECTED]> wrote:
>
> If a reasonable replacement was developed elsewhere, would you change your
>> vote?  I believe some folks were interested in developing this elsewhere.
>>
>
> It would depend. As I have said before, our goal as a PMC is to produce
> useful Hadoop releases. Pulling out functionality that users require makes
> the Hadoop releases less useful. Making users go to 20 different sites to
> download compatible versions of the different components, although it helps
> aggregating companies like RedHat, is an anti-goal.

I wasn't aware that RedHat was producing an aggregated release.

If these components are required, why are they in contrib?  Feel free to start a vote to move this component to core or incubator.

Why is this an anti-goal of Hadoop?  Did you mean non-goal?  Hadoop is NOT the Big Data Stack.  We're not responsible for integrating Pig, HBase, Hive, ZK, and all these contribs into one package.  If you'd like to propose a Big Data Stack integration project to the incubator I suspect you'll have a lot of support from folks in this community. That could be a really compelling project.  Until that happens, there's obvious value for users to use an aggregated, integrated Big Data Stack type package from companies like Cloudera.

> That said, if projects are active enough splitting them out into other
> Apache projects makes sense. Chukwa, HBase, Hive, Hive, Pig, and Zookeeper
> are wonderful examples of related projects where we've moved them out of
> Hadoop and their communities are healthier for the move. Moving actively
> used components into non-Apache managed projects, including Apache Extras,
> is an anti-goal.

We seem to have trouble creating releases of core Hadoop.  Why saddle ourselves with these ancillary components that are not core?  Sure, I'd love to see some of these move to incubator -- but I'm not signing up to do that.

Cheers,
Nige

On Thu, Feb 10, 2011 at 9:57 PM, Nigel Daley <[EMAIL PROTECTED]> wrote:

>
> On Feb 10, 2011, at 9:22 PM, Owen O'Malley wrote:
>
> > On Thu, Feb 10, 2011 at 6:58 PM, Nigel Daley <[EMAIL PROTECTED]> wrote:
> >
> >> I think the PMC should abandon the fuse-dfs HDFS contrib component.
>  It's
> >> last meaningful contribution was March 2010:
> >>
> >
> > I think we should hold on to this one until there is a reasonable
> > replacement. -1
>
> If a reasonable replacement was developed elsewhere, would you change your
> vote?  I believe some folks were interested in developing this elsewhere.
>

Looks like lot of folks are using the current one, so why not wait until new
one is submitted (and it works)?

Just because there are bugs against fuse-dfs that haven't been fixed in a
while doesn't make it useless. There are bugs open against Hadoop that
haven't been worked on for a long time either.


>
> Nige
>
>

On Feb 11, 2011, at 10:59 AM, M. C. Srivas wrote:

> On Thu, Feb 10, 2011 at 9:57 PM, Nigel Daley <[EMAIL PROTECTED]> wrote:
>
>>
>> On Feb 10, 2011, at 9:22 PM, Owen O'Malley wrote:
>>
>>> On Thu, Feb 10, 2011 at 6:58 PM, Nigel Daley <[EMAIL PROTECTED]> wrote:
>>>
>>>> I think the PMC should abandon the fuse-dfs HDFS contrib component.
>> It's
>>>> last meaningful contribution was March 2010:
>>>>
>>>
>>> I think we should hold on to this one until there is a reasonable
>>> replacement. -1
>>
>> If a reasonable replacement was developed elsewhere, would you change your
>> vote?  I believe some folks were interested in developing this elsewhere.
>>
>
> Looks like lot of folks are using the current one, so why not wait until new
> one is submitted (and it works)?
>
> Just because there are bugs against fuse-dfs that haven't been fixed in a
> while doesn't make it useless. There are bugs open against Hadoop that
> haven't been worked on for a long time either.
>

Indeed - and I would volunteer to clean house if given the time.

I've been browsing through the open issues.  A lot could be knocked out easily; most are improvement requests.

The contrib is used by folks in the community; it works well for them.  Typically, it only will need to be updated when the libhdfs header changes or when bugs are found.  It can use some TLC, not removal.

Brian

As a university researcher for file systems, having the fuse-dfs code  
makes life easy when trying to run i/o benchmark apps. I would hate to  
see it go. Here's my -1

  - Grant

Quoting Nigel Daley <[EMAIL PROTECTED]>:

> I think the PMC should abandon the fuse-dfs HDFS contrib component.  
> It's last meaningful contribution was March 2010:
>
> HDFS-961. dfs_readdir incorrectly parses paths. Contributed by Eli Collins.
>
> There are 18 unresolved contrib/fuse-dfs issues in Jira, none of  
> them Patch Available.
>
> Here is my +1.
>
> Nige
>

Grant Mackey
UCF Research Assistant
Engineering III
Rm 238 Cubicle 1

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

I see these votes as a desire to simply not develop this code under the
Hadoop project, not to kill the code base. I believe the general intention
is to "clean up" the project so it passes the "do one thing and do it well"
rule (or "develop one thing and develop it well"). Projects that are related
such as fuse-dfs, mrunit, and so on should and must exist. The question (and
vote) is simply should it be within Hadoop proper.

I think they can thrive in the incubator or wherever the majority of active
contributors wish to host it (although Owen has made the good point about
visibility and community development features of the ASF). My (non-binding)
vote is +1.

On Fri, Feb 11, 2011 at 2:37 PM, Grant Mackey <[EMAIL PROTECTED]> wrote:

> As a university researcher for file systems, having the fuse-dfs code makes
> life easy when trying to run i/o benchmark apps. I would hate to see it go.
> Here's my -1
>
>  - Grant
>
>
> Quoting Nigel Daley <[EMAIL PROTECTED]>:
>
>  I think the PMC should abandon the fuse-dfs HDFS contrib component.  It's
>> last meaningful contribution was March 2010:
>>
>> HDFS-961. dfs_readdir incorrectly parses paths. Contributed by Eli
>> Collins.
>>
>> There are 18 unresolved contrib/fuse-dfs issues in Jira, none of them
>> Patch Available.
>>
>> Here is my +1.
>>
>> Nige
>>
>>
>
>
> Grant Mackey
> UCF Research Assistant
> Engineering III
> Rm 238 Cubicle 1
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
--
Eric Sammer
twitter: esammer
data: www.cloudera.com

-1 (not binding) as well.

Cheers,
Chris

On Feb 11, 2011, at 11:37 AM, Grant Mackey wrote:

> As a university researcher for file systems, having the fuse-dfs code  
> makes life easy when trying to run i/o benchmark apps. I would hate to  
> see it go. Here's my -1
>
>  - Grant
>
> Quoting Nigel Daley <[EMAIL PROTECTED]>:
>
>> I think the PMC should abandon the fuse-dfs HDFS contrib component.  
>> It's last meaningful contribution was March 2010:
>>
>> HDFS-961. dfs_readdir incorrectly parses paths. Contributed by Eli Collins.
>>
>> There are 18 unresolved contrib/fuse-dfs issues in Jira, none of  
>> them Patch Available.
>>
>> Here is my +1.
>>
>> Nige
>>
>
>
>
> Grant Mackey
> UCF Research Assistant
> Engineering III
> Rm 238 Cubicle 1
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: [EMAIL PROTECTED]
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Since this vote didn't pass and fuse-dfs is being maintained [1] I've
filed HDFS-3451 to move fuse-dfs out of contrib into the native build.
(This won't introduce a new build dependency for people who don't want
it, like Snappy it won't compile by default unless you have the fuse
headers).

1. I've committed the following changes so far in 2012:
HDFS-860 fuse-dfs truncate behavior causes issues with scp
HDFS-3396     FUSE build fails on Ubuntu 12.04
HDFS-420 Fuse-dfs should cache fs handles
HDFS-2696 Fix the fuse-dfs build
HDFS-780 Revive TestFuseDFS

Thanks,
Eli

On Thu, Feb 10, 2011 at 6:58 PM, Nigel Daley <[EMAIL PROTECTED]> wrote:
> I think the PMC should abandon the fuse-dfs HDFS contrib component.  It's last meaningful contribution was March 2010:
>
> HDFS-961. dfs_readdir incorrectly parses paths. Contributed by Eli Collins.
>
> There are 18 unresolved contrib/fuse-dfs issues in Jira, none of them Patch Available.
>
> Here is my +1.
>
> Nige
>