Issue #116: Pagure sync: initial issue description should include what the bug is proposed as - blockerbugs

fedora-qa / blockerbugs

#116 Pagure sync: initial issue description should include what the bug is proposed as

Closed: Fixed 3 years ago by kparal. Opened 4 years ago by adamwill.

When a Pagure issue is filed for a newly-proposed bug, the title of the issue gives you the bug description and the issue text just includes a link to the bug, the vote summary, and the 'how to vote' link. I think the initial description should also say what the bug is proposed as (e.g. 'Proposed Fedora 32 Beta blocker', 'Proposed Fedora 32 Final freeze exception' etc.) I don't know if we need to get into adding comments when the proposal status changes or anything like that, but at least initially indicating what the bug is proposed as seems like it'd be useful for voting purposes.

kparal commented 4 years ago

I already covered this in #115. The expectation is that you'll arrive at that ticket through BBA, where you do see what this bug is proposed against. And that info is refreshed regularly. We wanted to avoid creating some initial description just to have it outdated once somebody touches the bug report.

It's true that we didn't realize that you'll also receive new ticket notifications directly from Pagure, which sidesteps the BBA view. Still, I'm not sure including a potentially outdated information in the ticket is helpful, because when we do, you can be sure people won't inspect the bug report carefully to see what it is proposed against at that very moment, and will only vote for what is specified in the ticket description. That's just human nature.

lbrabec commented 4 years ago

I can see the benefit of additional info when you open multiple new tabs with Pagure discussions. In this situation you probably don't remember which tab is for blocker and which for FE. Would people use BBA this way? I don't know, we'll see what people say when the async PoC is in use.

One idea I had is to use comment instead of description (or tag). When discussion issue is created, blockerbot adds comment, e.g. "This bug was proposed as FinalBlocker". It doesn't require any sync, when "proposed as" changes it will be reflected in the discussion (well, will it?) and you should read the whole discussion before voting anyway.

Thoughts?

kparal commented 4 years ago

when "proposed as" changes it will be reflected in the discussion (well, will it?)

You mean somebody manually mentioning that. It might happen, it might not, and it might be buried in the middle of a long discussion :-/

When discussion issue is created, blockerbot adds comment, e.g. "This bug was proposed as FinalBlocker".

We can try it, but I'm worried that people laziness will prevail (myself included). I think we should either bite the bullet and provide proper syncs, or have the nuisance of needing to open the bug or BBA. In the long run, proper sync might be the desired solution, but I don't want to do it as part of the PoC. It's really unfortunate we couldn't deploy it to production for F32.

I wonder if there is some middle ground. A wild idea - could the Pagure ticket description also include a link to BBA, something like https://bba.url?bugid=123456, and BBA would then highlight all bugs 123456 in its interface, so that you could easily see all nominations? It would have to work across releases/milestones. In case the bug id wasn't present anywhere, it would tell you. But I don't know if the work required for this wouldn't be similar to a proper sync for tickets.

lbrabec commented 4 years ago

That idea with link to BBA got me thinking...

You can embed remote images in the issue description. I tested it on stg, although pagure documentation says it is not supported. We should ask if this is intentional or bug.

If the remote images are now supported, I can implement endpoint to BBA (e.g. https://bba.url/bugimg/<bugid>) that would return SVG image containing the "proposed as" text. We would just include this image to issue description. No sync required, the image URL stays the same, BBA just creates the image dynamically with current info.

kparal commented 4 years ago

Hmm, it works even in production, interesting. I'm quite certain it used to not work. You can ask Pagure admins whether they changed their mind, and if they did, it's an interesting idea to do. Note that we will be moving to Gitlab in the future, it seems, so let's be sure we can use the same functionality in Gitlab before we implement it.

lbrabec commented 4 years ago

Pingou confirmed that documentation is outdated and remote images should work now.

I wrote PoC for this and frantisek deployed it. The images below are from communishift BBA instance:
![1816098](http://blockerbugs-blockerbugs.apps.os.fedorainfracloud.org/api/v0/bugimg/1816098)

![1816547](http://blockerbugs-blockerbugs.apps.os.fedorainfracloud.org/api/v0/bugimg/1816547)

lbrabec commented 4 years ago

Well, my browser console is saying:
Refused to load the image 'http://...snip' because it violates the following Content Security Policy directive: "img-src 'self' https:".

If you open the image URL directly, it works. If I read the error correctly, to make it work here, we'll need https for BBA.

lbrabec commented 4 years ago

Trying again with https, sorry for the spam, I cannot use preview because the images are lazyloaded.

![1816098](https://blockerbugs-blockerbugs.apps.os.fedorainfracloud.org/api/v0/bugimg/1816098)

![1816547](https://blockerbugs-blockerbugs.apps.os.fedorainfracloud.org/api/v0/bugimg/1816547)

Edited 4 years ago by lbrabec

lbrabec commented 4 years ago

So I tested this change locally, I don't like the dropped shadow, but that's styling of Pagure.

What do you say, @adamwill ?

kparal commented 4 years ago

Let's prefix the image with some info, so that it doesn't confuse people about what it exactly is. What about this?

Bug details: ** URL **
Information from [BlockerBugs App](https://qa.fedoraproject.org/blockerbugs/):
<image>

I love that it also shows rejected trackers (even though the BBA web interface doesn't). Great.

A small annoyance is that Pagure loads embeded images only after it loads all avatars of all subscribers (the right column at the very bottom) from libravatar, which is often very slow. So you might wait a minute for that image to appear. We can file an RFE against Pagure about that.

adamwill commented 4 years ago

sure, looks nice to me.

kparal commented 3 years ago

Hey @lbrabec, can you please implement this (your comment)? I think our current experiment works quite fine for us and we can start adding features. Thanks!

kparal commented 3 years ago

Related PR: #138

kparal commented 3 years ago

Fixed in 8d32b1b

Metadata Update from @kparal:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 years ago

kparal commented 3 years ago

@lbrabec Now that this has been implemented, what will happen if a bug is still in the proposed state, but it has been closed, and so it not showing up in the BBA web UI? Here's an example of a proposed F33BetaFE, which was closed shortly afterwards:
https://bugzilla.redhat.com/show_bug.cgi?id=1880768

If the bug is not shown in BBA, I'd like that to be clear from the bugimg. If it still shows as Proposed F33BetaFE, it will be confusing, but it's not really proposed anymore. In this case I believe the bugimg should simply say something like "BUG CLOSED", and optionally also show all the proposed/accepted fields. But it should definitely mention that it has been closed. Or it can say "unknown bug", if we no longer have a record of this bug in our database (I don't know if we remove these records or not). Can you please check this edge case? Thanks!

lbrabec commented 3 years ago

ATM, it is exactly as you describe, active and status fields are ignored and the rendered image contains 33-beta: Proposed FE.

It won't be a problem to add logic that checks either active or status and if bug is inactive or CLOSED, the image will display this additional information.

lbrabec commented 3 years ago