Re: mv symlink-to-dir/, debian bug feed

[Bob Proulx]

Jim Meyering wrote:
> Eric Blake wrote:
> > Meanwhile, would it be worth subscribing bug-coreutils to the debian bug
> > feed list?  That way, this list would see bugs as they are reported, and
> > others besides Jim will be able to chime in with advice.
> 
> I know Bob Proulx is already subscribed there.
> Some of the traffic would not be interesting, i.e., a message
> announcing that a bug is closed, or tagged -- but those are easy to skip.
> 
> Overall, I think it would be better for both Debian and GNU.
> We can always try, and if it doesn't work out, remove it later.
> Bob, Michael, what do you think?

I have mixed thoughts about subscribing GNU's bug-coreutils to the
Debian coreutils BTS list.  There are good points and bad points and I
can think of several of each.  It will be more information and more
noise to the mailing list.  I can't be unbiased and so will abstain
from voting.  In the end it will depend upon the needs of the rest of
the community.  If Jim would like to subscribe it and gets benefit
from it then that is okay with me.

For all distros perhaps being more aggressive at forwarding downstream
bugs to the upstream mailing list would be a good thing.  I know that
I have not been doing that as much as I should.

I will comment that the way reports should be answered will be
different depending upon the path by which they are reported.  Users
of a software distribution are best served when the bug is fixed in
the native packaging environment.  This means that answering a user
with a pointer to the source code and saying to upgrade to the latest
version is not the best thing for a distribution user.  If a Solaris,
HP-UX, IBM AIX, etc. (no native packages) user reports a bug and they
have a locally compiled version of the source then this makes the most
sense.

But for Debian and others too the best answer is usually to get things
into the pipeline for an official release such that the next software
distribution stable release contains the fix.  In that environment
developers may work on the bleeding edge but less technical users are
encouraged to work in stable release environments.  There will often
be a large pipeline delay between upstream and downstream.  Living
with both environments will mean needing to understand the reporting
user's environment and how to best serve the user when answering.

Bob