Adding "upstream issue" to ticket resolutions

[Sean Farley]

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.