Identifying portname in a bug?

[Ryan Schmidt]

On Sep 12, 2008, at 1:45 PM, 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.

Somewhat indifferent. It could perhaps be placed better, but I would  
hope anyone filling out a bug report would examine all fields  
regardless of where on the screen they are.


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

Not in favor. Tickets can be filed against multiple ports (like a bug  
that applies e.g. to php4 and php5 and php5-devel, or to py- 
setuptools and py25-setuptools). Requiring a version in this case  
could be confusing. If you required entering versions for all ports,  
how would you search on that? I'd rather encourage users to enter the  
version number into the ticket description.


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

Not in favor, for the reason above.


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

Indifferent. As William said, the versions listed make it clear these  
are MacPorts versions.


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

Not in favor. People often file bugs as port bugs, when in fact they  
are base bugs that are exposed by certain ports. It's useful to list  
the port name, even after changing the ticket to a base bug, so that  
people searching for bugs about that port will find the base bug and  
won't file a duplicate.


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

Not in favor. Sometimes you don't know what port is responsible for  
the problem. People often file bugs against, say, ImageMagick, when  
in fact the bug is with one of its dependencies. Sometimes people  
don't provide enough information in the bug report to identify which  
port is responsible, in which case we don't know how to fill in the  
port field.

Also, sometimes people file base bugs and forget to classify it as a  
base bug; they classify it as a port bug. Then they'd run into an  
error about the port field being required. They might realize they  
need to switch the classification to base bugs, or they might fill  
garbage into the port field, or they might get frustrated and abandon  
the bug report entirely, which we don't want.

That's the problem with more required fields. They can annoy and even  
drive away the people you need most -- the ones who are telling you  
about problems in your software. I'm in favor of fewer fields, not  
more. For example, I don't like that we have duplication between  
"type" (defect, enhancement), "milestone" (base bugs, base  
enhancements, port bugs, port enhancements) and "component" (base,  
ports).



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

Sure. That's a nice idea. MPWA should link to port bug reports too.


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

I think by definition, ports are already first class citizens in  
MacPorts -- I'd consider them the only first class citizens we have,  
since MacPorts is all about ports (what else?). But I won't deny that  
the MacPorts web presence could still be improved.