GNU bug report logs - #5914
feature request and non-bug patches submit policy

Previous Next

Full log

View this message in rfc822 format

From: "jeff.liu" <jeff.liu <at> oracle.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: Sunil Mushran <sunil.mushran <at> oracle.com>, 5914 <at> debbugs.gnu.org
Subject: bug#5914: feature request and non-bug patches submit policy
Date: Fri, 09 Apr 2010 23:12:17 +0800

Hi Jim,

Thanks for your prompt response!

Jim Meyering wrote:
> jeff.liu wrote:
>> Hi Jim,
>>
>> I'd like to know if I should still submit new feature patches to here or coreutils <at> gnu.org.
>>
>> A few months ago, I found the heads up for the new coreutils <at> gnu.org mail list, and it mentioned
>> only the bugs report/fix should be send to this list.  Otherwise, for the general discussion and new
>> features request should go to the new list, Am I right?
>>
>> But looks there is little activity in coreutils <at> gnu.org, I have sent a few patches related to cp(1)
>> sparse file enhancement through fiemap ioctl(2), but almostly no response from the list members in
>> about 2 weeks, except Joel I cc-ed.  Maybe nobody is interesed. :(
>>
>> I know you guys are busy with work.  Actually, I just want to know if I was misunderstood the
>> policy?  If so, I will submit the patches here.
> 
> Hi Jeff,
> 
> bug-coreutils is definitely the right list, and I confirmed this
> morning that you are covered on the copyright front (Oracle has an "ANY"
> assignment with the FSF), assuming you're doing this on company time.
> If you're doing any of this work on your own time, you should follow
> the procedure outlined here:
> 
>     http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING#n327
> 
Yeah, I did this work on my company time.

> Over the last few weeks I've been working on other projects
> (pretty must time dedicated to getting grep back into shape),
> so coreutils has languished.  Sorry for not giving more feedback,
> but I have been watching.
> 
> In fact, seeing the use of HAVE_FTRUNCATE that is moved by your patch
> is what prompted me to mark the ftruncate module as obsolete and remove
> that code from copy.c.
> 
> While I'm writing, here's one high-level question for you.
> When would your new --fiemap-sync option be useful, and what change
> in semantics will I see between when I use it and when I don't?
> 
>          --fiemap-sync            sync file data before fiemap\n\
> 
IMHO, there is no difference from the user's point of view with or without this option.
and on the kernel side, if FIEMAP_FLAG_SYNC was specified, it just do the dirty page process
regardless of the sync succeeds or failed due to ENOSPC or EIO or other errors.

I need to do more investigation to answer this question.

> I cannot deduce that from anything I've seen written in your
> patch or even in the related kernel sources I've seen so far.
> I.e., if you can justify the addition of this option,
> then that justification should be obvious from its description
> in doc/coreutils.texi.
> 
> Sure, I know what "sync" means, but for a command-line tool
> like cp, why provide the option when the user can simply
> precede the cp invocation with a use of sync(1).
> 
At first, I think the user could just run `cp --fiemap=[WHEN] --fiemap-sync' in terms of 'sync;
cp...' semantics.
But actually, just as you said, it is indeed a duplicate option since we can do same thing in a
simply way.

> I presume you can give an example where cp produces different results
> with and without --fiemap-sync.  Please demonstrate that.
I will try to do more test for the verify check.

Best Regards,
-Jeff

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.