Identifying portname in a bug?

[William Siegrist]

On Sep 12, 2008, at 11:45 AM, Jay Levitt wrote:

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

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


> 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

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

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


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

This would be implemented the same way as #3 above. So if you want to  
comment on that ticket to request that it also be "required" when  
component=ports,  and optional otherwise, I think I can do that.  So  
I'm +1 on this item when component=ports.


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

Its a standard Trac v0.11 setup, feel free to contribute plugins.


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

Good catch, I never went back and added it. Please file a ticket for  
all applicable reports to include the port field.


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

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


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


Thanks
-Bill





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080912/1424bc75/attachment.bin