Identifying portname in a bug?
lists-macports at shopwatch.org
Fri Sep 12 16:28:56 PDT 2008
William Siegrist wrote:
> On Sep 12, 2008, at 11:45 AM, Jay Levitt wrote:
>> Suggestions for new ticket entry:
[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
>> 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:
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.
>> 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
Thanks for the quick response and encouragement. I just knew there was a
way I could put off working on my real project.
More information about the macports-dev