Identifying portname in a bug?

[Jay Levitt]

William Siegrist wrote:
> On Sep 12, 2008, at 11:45 AM, Jay Levitt wrote:
>> Suggestions for new ticket entry:
[summarized]

[1. Move "port" next to "component" on entry form]
[2. Separate "port" into "portname" and "port version"]

> I'm +1 for #1 and #2, if no one else objects, please file a ticket 
> against server/hosting with these.

Will do, pending discussion.

>> 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.
>>
> 
> This is already covered by the original Port field ticket, which is a 
> work in progress:
> 
> http://trac.macports.org/ticket/15210

Cool.  I should've been clearer about "arbitrary"; I meant as in "Could I 
contribute something in Ruby, cuz I ain't learned Python yet."  I think Trac 
plugins can only be Python eggs.  (It's really hard to find discussions 
ABOUT Trac on Google; you get everyone's Trac site instead.)  Oh well.

>> 4. "Version" should then change to "MacPorts" version.
>>
> 
> This is non-trivial (changing a core Trac field). I also feel that the 
> fact that it lists version numbers for MacPorts makes it fairly obvious. 
> Perhaps making the versions show "MacPorts 1.6.0" etc would help? I dont 
> think its that big of a deal though. That being said, it _is_ possible, 
> so if other people agree go ahead and file a ticket against server/hosting.

Ugh, not worth it then.. I was just being all symmetrical. I -1 myself.

>> 5. For extra bonus UI points, "portname" and "port version" should be
>> unselectable until component=ports.
>>
> 
> I think its possible to have other components relate to ports, (a base 
> bug specific to a port, or portgroup, etc). So I dont think its worth 
> the engineering effort to pull this off.

That makes sense.

[6. Require portname for new tickets and for editing existing ones]

> So I'm 
> +1 on this item when component=ports.

OK, I'll add that to the ticket.

[Add portname/version fields to reports]

I'll file a ticket.

>> 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..
> 
> I can just do it at the SQL level and avoid all the notification mess. 
> If you want to write something up, our Trac is backed by PostgreSQL 
> v8.2.  Go ahead and lump this into the ticket for #3 and #6

Great.  I'll set up a Trac early next week to play with the schema.

>> Other:
>>
>> The "ports.php" search page should link to the bug reports for that port.
>>
> 
> ports.php is in the repo, seems trivial to add a link to 
> "/query?port=<?$port?>" or whatever it would be.  This should be a 
> separate ticket, but still server/hosting. Any committer should be able 
> to do this though. "For bonus points" an attached patch would be great. :)

OK!  I ain't learned much PHP either, but I think I can hack an href out of 
it :)

Thanks for the quick response and encouragement.  I just knew there was a 
way I could put off working on my real project.

Jay