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

For the various maintainers of the Cygwin project and its packages, this
should also help them keep track of and prioritize issues and more
transparently plan how and when the issues will be addressed.  For
especially difficult cases, perhaps a voting system could even be
implemented to help everyone agree upon the prioritization of defects so
that developers can better spend their time addressing the most urgent
needs of the community at large (not that a volunteer developer really
has to adhere to any community vote ;-).  We also shouldn't overlook the
case where one person replaces another as the maintainer of something.
Having the current list of outstanding issues and some clear history of
previous issues would make the new maintainer's job much easier.


Problem reports:
Unsubscribe info:

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