Re: [gentoo-project] The meaning of RESOLVED/UPSTREAM on bugzie

[Kent Fredric]

On Wed, 29 Mar 2017 16:01:18 +0200
Ulrich Mueller <ulm@g.o> wrote:

> UPSTREAM
>     The requested bug is considered to be out of the purview of the
>     distro and should be submitted/discussed directly with the
>     respective upstream project. This could include a number of things
>     such as changing default configuration options or behavior, adding
>     new options or functionality, or deleting support for older
>     systems.
>
> IMHO it would be out of proportion to remove the field, just because
> some developers don't use it as intended.

To me, this is a case of "bad choice of name leads to bad use"

I doubt many people actually know that definition.

But naming is hard.

The RESO/UPSTREAM situation would be *much* better if bugs that were marked
that way injected a blob of text *somewhere* on the page in a different colour
to inform the user about what it means.

"This bug has been marked `Upstream`, which means the nature of your request
 is outside the scope of things Gentoo developers consider to be things within
 their realm of responsibilities to resolve.

 Please contact upstream and have them implement your feature/fix your bug
 there, instead"

As it stands, receiving a "RESO/UPSTREAM" resolution is almost as big a slap in the face
as "RESO/INVALID". 

_Especially_ when a developer marks a ticket as that without adequate explanation as to
why.

All you see is "Piss off mate, we don't like ya"

Even a class of "Resolved" is pretty much not useful here, because it implies
to the reader "the bug is gone", even though its not really.

"DEFERRED/OUTOFSCOPE" would probably be a more adequate and natural resolution
if you had to make one in a very small amount of space that conveyed all the right information.

Because then, if its merely "deferred", that implies it can be pushed back to Gentoo in
some capacity once external effort is complete, and then the author of the bug can:

1. Change the name of the bug from a request for a change, to a request for a bump to the feature-including bug
2. Change the resolution back to open
3. Have the bug resolved / Fixed.

"DEFERRED/TESTREQ" -- Its not resolved, but action can't complete until somebody tests it
"DEFERRED/INVALID" -- Data given so far indicates its not a bug, but perhaps better data could change that
"DEFERRED/NEEDINFO" -- Its not "fixed" as such, but we can't continue due to lack of information.

But I guess I'm reacting too much to the use of the word "Resolved", which is a bit easy to conflate.

Because while it is /a resolution/, "resolved" in colloquial usage /implies/ "fixed", even though
its use in bugzilla is no such thing.

But I think a renaming/recategorizing campeign at this point is too much, and an alternative of finding a way to embed
resolution-descriptions as helper text in the issue once a resolution state has been chosen, to smooth the path for the reader,
and to _reinforce_ what that resolution means, would probably be more productive.

But I suspect such a feature is best petitioned to bugzilla, so I could file a bug about this in Gentoo bugzilla that we
add this feature, and somebody can mark it "RESOLVED: UPSTREAM" and really satiate my meta-recursion fetish.