A word on Trac ticket submissions...

[Ryan Schmidt]

On Jun 22, 2010, at 08:08, Jeff Singleton wrote:

> How about configuring Trac with Drop Down selections for maintainers,

We had a drop-down for maintainers. It slowed Trac to a crawl. We removed the drop-down. Most people seem to manage just fine with the text field.

> or Error checks that automatically prompt us, or even prevent the ticket from being submitted until it is correct.

I don't know what Trac gives us the possibility to do here, but I'm a bit wary of doing so. I read once that it should be as simple as possible for the user to enter bug reports, to encourage them to do so; if it's too hard to enter a bug report, the user may just not report it, which would be bad. I already think we require a bit much of users at bug-reporting time. (Having Trac automatically look up a port's maintainer, for example, would be helpful, but I don't know if Trac can do that for us.)

> In particular...the bug I recently submitted #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.

In that case, thank you for submitting a bug report; clearly it's hard for us to fix problems we don't know about, so now that we know about it, hopefully someone can take a look. I'm not a Ruby person so it won't be me, but hopefully the maintainer or another Ruby expert will.

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

We are all volunteers. Some volunteer to maintain, then circumstances change -- they had a Mac at work but switched employers and now don't have one, or they no longer use the software in question, or they no longer have time to contribute. If a port seems to be abandoned, there is a procedure described in the Guide that can be followed. Also, anyone else with an interest in the port can submit patches to be reviewed.

> And when the port is broken due to upstream issues, then it should be marked broken

In what way do you suggest it should be marked? We don't currently have an established marking mechanism for that.

> and force a working version to be used instead or a note stating what the issue is.

IMHO the notes stating what the issues are are called Trac tickets.

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

Thank you! That should be helpful.

-Ryan