bug#5914: feature request and non-bug patches submit policy

[jeff.liu]

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 
>> address@hidden
>>
>> A few months ago, I found the heads up for the new address@hidden 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 address@hidden, 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