Comment 4 for bug 333215

I also agree it does seem useless.

I included "non-upstreamed" upstream tasks in my bug triaging process for a while, but the experiment didn't work out. The idea was that as I processed through a lengthy list of bugs, I could quickly mark bugs I felt should go upstream, but leave the link unset. I could then go back later and query for "Bugs needing to go upstream", and work through filing each of these upstream and attach the links as I had time. Certainly it is quite time consuming to send a bug upstream, so this seemed like it would let me split the work up better.

However, in practice I found it caused confusion amongst other bug triagers, who went back after me and invalidated these "empty bug links". Bug reporters also found it odd that a bug would be given an upstream task but not actually filed upstream. And it was exceedingly rare that anyone else would take the hint and do the bug forwarding for me.

Ultimately, I discontinued this process. I found that I needed to fully grok the bug to decide if it should go upstream, and then needed to reach the same grokkage level when actually sending it upstream, so I ended up having to do the grokking twice, which was inefficient.

Instead, I opted for the approach of once I grokked a bug, I set it to Triaged and at the same time send it upstream. If the bug was not upstreamable (which for X.org is the exceptional case), I'd indicate this in the title, description, or a comment.

Anyway, so yeah, my experience is that being able to "register that it is upstream" without linking, is not that useful. People who do this as part of a workflow could switch to using 'needs-upstreamed' tagging or other mechanisms for flagging these kinds of bugs.