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

[Jim Meyering]

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

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\

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).

I presume you can give an example where cp produces different results
with and without --fiemap-sync.  Please demonstrate that.