Ryan Schmidt writes:

> On Jun 12, 2014, at 2:25 PM, Mojca Miklavec wrote:
>
>> Sometimes the open tickets are really upstream issues that the
>> maintainer isn't able to fix until the upstream solves a particular
>> problem. I would like to clearly distinguish these tickets from the
>> rest.
>> 
>> Such tickets can either stay open for years (and give a bad impression
>> that tickets in the tracker are too often ignored [which is actually
>> true to some extent]) or they can be closed with "wontfix" and go
>> completely out of radar (if upstream actually fixes the problem,
>> backporting the fix might still be desired) + maybe even discouraged
>> anyone to submit a patch.
>> 
>> It would be nice to introduce a special state, meaning that while this
>> is still an issue, it will only be fixed if the upstream fixes the
>> problem (or if someone is willing to invest time to fix this). Like
>> here:
>>    
>> https://github.com/Homebrew/homebrew/issues?labels=upstream+issue&page=1&state=open
>
> I'm loth to add more options. I think we already have far too many options 
> that people need to select, and more than often select incorrectly. I like 
> simpler bug trackers, like FogBugz, which require nothing more than a single 
> sentence to open a ticket.
>
> If we really wanted to indicate that a ticket wasn't fixed because it's an 
> upstream issue, we could use a new keyword... We could then make it 
> independent of whether we close the ticket or not. i.e. if it's a problem 
> affecting many users and the developers are active, we could add an 
> "upstreamissue" keyword while leaving the ticket open so that others can 
> easily find the issue, then backport the fix when it's available. Or if the 
> ticket was just a wishful feature request, we can close it as "wontfix" while 
> adding the "upstreamissue" keyword.

While I really don't like trac nor it's interface, I have to say that,
being a package manager and all, we really need an 'upstream'
state. 'wontfix' isn't what we want as that's mostly rude and signifies
a user error. 'upstream' signifies, I think fairly generally, that we'd
be willing to accept an upstream patch that's been backported or wait
until the next release of a package. 'wontfix' just doesn't convey that
message.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to