GNU bug report logs -
#5914
feature request and non-bug patches submit policy
Previous Next
Reported by: "jeff.liu" <jeff.liu <at> oracle.com>
Date: Fri, 9 Apr 2010 12:39:02 UTC
Severity: wishlist
Done: Bob Proulx <bob <at> proulx.com>
Bug is archived. No further changes may be made.
Full log
Message #8 received at 5914 <at> debbugs.gnu.org (full text, mbox):
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
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.
This bug report was last modified 15 years and 101 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.