Identifying portname in a bug?

[Jay Levitt]

Caspar Florian Ebeling wrote:
>> The field was already added recently. But it is not used in older bugs.
>> So it would help if only anyone editing a bug would populate this field
>> as well.
> 
> oh, yes, sorry, so I missed that and my information was stale.

...so you can see why I think it ought to be a more visible field... :)

Suggestions for new ticket entry:

1. Upon entering a new ticket, I do see the "port" field, but it's dead
last, after "keywords" and even "CC".  I'd put it next to "component", since
"port" is a subcategory of the "ports" component.

2. Ideally, "port" should be two fields: port name, and port version.  Sure,
we can establish a convention, but software's much better at that than
humans.  I'd like to be able to search for all bugs on the postgresql port,
or only bugs reported on the latest version.

3. Does trac allow an arbitrary validation script to run?  If so, we could
check that the portname was, in fact, the name of a valid port.

4. "Version" should then change to "MacPorts" version.

5. For extra bonus UI points, "portname" and "port version" should be
unselectable until component=ports.

6. Make the portname field required on the form for all new tickets, and (I
think) for updates to all existing tickets.  Argument against the latter: "I
just want to provide some helpful information!  I shouldn't have to do data
entry."  Counterargument: "From a philosophically pure standpoint, you're
right.  From a pragmatic standpoint, it's just asking for information you
already know: the name of the port.  And it helps us all."

I know nothing about Trac, so what I'm suggesting might be easy or hard.  If
it's hard, but you like the idea, I'll volunteer to do the legwork.

For reports:

Add the portname and port version fields to the existing columns in the
default reports; right now, they show "component" but not "port".

For existing tickets:

I think I could write a script that goes through trac as an HTTP client (or
is there a REST API?), pulls the portname out of the summary, and moves it
into the portname and version fields.  You'd want to turn off that
trac-tickets feed while it was running, though, at least for tickets
modified by me..

Other:

The "ports.php" search page should link to the bug reports for that port.

I think that all these would help make individual ports "first class
citizens" of MacPorts, which will in turn make it easier for users to report
bugs, and maintainers to fix them.

What do you all think?

Jay