A word on Trac ticket submissions...

[Jeff Singleton]

Ya know...

If the same effort was put into fixing bugs as was put into ensuring tickets
entered are correct, I think we would have a lot less bugs.

How about configuring Trac with Drop Down selections for maintainers, or
Error checks that automatically prompt us, or even prevent the ticket from
being submitted until it is correct.  This takes more onus off the
maintainers/Trac Admin and puts in where it belongs...in the user/bug
reporter's hands.

In particular...the bug I recently submitted
#25372<http://trac.macports.org/ticket/25372> has
been an issue since at least Macports v1.7/1.8 with no one ever submitting a
bug, nor anyone ever testing it to ensure it works.  There are several
others that I have run across that seem to never get touched...sure bugs
need to be created.  But I would think the maintainer should be
"maintaining" which should include the random test builds to ensure
everything still works.

And when the port is broken due to upstream issues, then it should be marked
broken and force a working version to be used instead or a note stating what
the issue is.  I know there are others like me, who tinker, and aren't
afraid to start over in the effort of learning.  One thing I always do when
something is broken in Macports, is check with the upstream provider for
newer code, try compiling it manually, and see what is causing it to be
broken in Macports.  If I can figure it out, then I tend to submit a
bug/email.

Anyway...I hope this generates some decent discussion in the effort of
making Macports a better experience for all.

-- 
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20100622/849daee9/attachment.html>