[please don't top-post on technical lists]

On 01/09/2012 06:41 PM, Linda Walsh wrote:
> I see....
> 
> So the default policy is that if Windows touches it, gnu won't?

More like: Windows is at best a secondary system, and doesn't have as
high as a priority since it does not promote freedom; you'll get better
response by directing your query to the folks more interested in working
on that platform (and while some of those folks, including me, happen to
hang out on both this list and the cygwin list, I prefer hearing about
cygwin issues on the cygwin list).  We have also seen, time after time,
that bug reports about the windows ports are more often problems with
the port itself and not a problem in the upstream code.  And the
attitude on this list about Windows ports is consistent with the overall
GNU philosophy about ports to highly-crippled proprietary systems:
https://www.gnu.org/software/autoconf/manual/standards.html#References

> Eric's initial assumptions about the bug were incorrect as I responded.

My initial assumptions that the issue has only been seen with cygwin in
the mix, and therefore the cygwin folks should be involved first, is
still correct.  As for whether or not I missed your documentation that
you are using an alias for cp, that is probably the case, but it doesn't
impact the decision that we should deal with the bug at the point where
it was first observed, or that you should simplify your testcase without
cygwin in the mix to prove that it is indeed an upstream issue.

> That doesn't lead me to believe that instantly closing a bug coming
> from a cygwin port should always be the best automatic response.

It's not just cygwin, but all pre-built binaries.  For example, if you
use Fedora, and encounter a crash when using a UTF-8 locale, you are
encouraged to report it to the Fedora folks, who will then triage the
bug and determine if it is a bug in the Fedora multi-byte add-on patch
(which has been the case in a number of circumstances), or generic to
upstream (less common, but it has also happened).  The underlying
principle is the same, though - when dealing with a pre-built binary,
either _report the bug to the person that built the binary_, because the
bug may be in how the binary was built and not upstream, or reproduce
the bug yourself on a self-built coreutils.git, and mention the fact
that you have reproduced it in a pristine upstream environment.  By
removing the variable of the pre-built binary from the equation, you
will have made your bug report that much more reliable, and thrown the
burden of fixing things on the point where the bug has been isolated.

Which means that our behavior of closing bugs that are reported directly
upstream by people that only use a downstream pre-built binary is par
for the course, as we trust the downstream packagers to reopen things if
it turns out to be an upstream issue after all (for this particular bug,
I happen to also be the downstream maintainer, so I _will_ be responding
more on the cygwin side of things, and possibly adding more to this
upstream conversation based on those findings).

Finally, the action of closing a bug does not mean that we are
discouraging all conversation on the topic; it is merely a bookkeeping
practice to make it easier to track which issues are being actively
worked on in the context of this list.  As long as your particular
report is being investigated on the cygwin list, we don't need to be
reproducing the efforts here on this list.  You can reply to closed
bugs, and the replies are still valid.  There's no need to add to the
bookkeeping efforts if a maintainer closed a bug because he thought it
was better dealt with downstream.  And in the future, when I reply to a
cross-posted message (you sent your original to both coreutils and
cygwin), by closing off one side of the cross-posting to focus on the
issue from the other side, I will try to be more clear about making that
particular point clear in my message.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org