This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bug tracker

On Thu, Aug 19, 2010 at 11:02:35AM -0500, Jeremy Bopp wrote:
>On 8/19/2010 10:18 AM, Andrew Schulman wrote:
>> (1) Most important:  How many people care?  Do users want a bug tracker?
>> Would package maintainers use it?  Would the cygwin and setup.exe
>> maintainers use it?
>> Andrew Schulman and Bill Blunn would find a bug tracker useful, but that's
>> not enough reason to build one.  There has to be significant community
>> buy-in, or it's not worth doing.
>I'll chime in that I believe a bug tracker would be an excellent support
>option for Cygwin.  For various reasons, many people new to Cygwin
>either don't know about or fail to successfully use the mail archives to
>find answers to their questions or solutions to their issues.
>Personally, I find that searching the mail archives leaves much to be
>desired when trying to follow the various threads that can sometimes be
>spawned by a single issue over Cygwin's history.
>For instance, how many threads have been created over the years because
>someone has trouble getting sshd correctly configured to work with
>pubkey authentication?  And assuming the intrepid decide to play nice
>and search the mail archives first, how are new users supposed to know
>which reply in which thread has the authoritative answer for their
>version of Cygwin on their installation of Windows?  For people who
>haven't been monitoring the list for years, it's hard to know who is an
>authority for any particular subject, and it's doubly hard to keep track
>of which version of Cygwin, openssh, what-have-you is relevant to any
>discussion older than 12 months.
>A defect tracker should hopefully address such issues at least somewhat
>better than mail archives.  Duplicate issues can be merged, issue owners
>can be more readily assumed to be able to provide the authoritative
>answers and solutions, resolved issues can be unambiguously closed, and
>detailed information such as package and Cygwin versions and affected
>Windows platforms can be recorded for quick reference when applicable.

This seems like a terrible example to me.  You seem to be expecting a bug
tracker will be used for technical support so that if someone is having
problems setting up openssh they will be walked through the problem in
the bug tracker.  I'd actually expect that a user error would be closed
as "user error".  And, subsequent reports of the problem would be closed
as "dup"s.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]