On Thu, Nov 12, 2020 at 4:15 PM Kamil Paral <kparal(a)redhat.com> wrote:
First, a ticket creation should automatically send a comment to
so that the developer/package maintainer and anyone watching knows about
the discussion and can participate (we're fairly bad about it at the
Filed as https://pagure.io/fedora-qa/blockerbugs/issue/148
And it would also be nice to reduce the amount of manual
secretarialization needed after a vote is accepted - Bugzilla could be
ideally updated automatically with the correct flags.
Filed as https://pagure.io/fedora-qa/blockerbugs/issue/149
On Thu, Nov 12, 2020 at 6:00 PM Adam Williamson <adamwill(a)fedoraproject.org>
* No synchronization of "decision made" between ticket and
when a decision is made someone has to update both separately (using
different Magic Texts, which it's easy to mess up). It would be really
nice if we could just mark the decision in Bugzilla and have that
automatically propagate to the ticket system.
Please discuss the implementation in
* Using Magic Text for voting and admin is awkward and error-prone.
Better UI for this would be really helpful.
I'm not sure how it can be improved. Do you have any ideas?
In addition, the state isn't automatically updated when you vote
or mark a
decision, so I
always find myself manually refreshing the page after doing it just to
make sure I did it right and the change took effect.
Yes, that's the recommended approach documented at
. Pagure can actually detect a
change in description and in theory it should refresh it live, but mostly
I've seen it simply becoming a mess of characters, because while it updated
the contents, it didn't render it as RST and it was just a messy output. I
wanted to file a bug about it, but when I tested it today, it didn't even
respond to description updates and simply nothing happened and I had to
reload the page. So I'm not sure whether it's a race or they fixed the
previous incorrect behavior by simply not responding to that event,
*shrug*. Since Fedora seems to be moving towards Gitlab, I don't want to
spend too much time debugging Pagure issues at the moment.
With Lukas Brabec we also considered adding a "thumbs up" reaction to your
comment if it contains a well-parsed command, which could show up
immediately. But it seems to be not supported by Pagure API at the moment.
Do you have some idea how to make the voting process feedback better,
without relying on Pagure bugfixes/feature updates?
* It'd be really nice if the web UI showed the current vote
the ticket. I frequently find myself opening every proposal ticket in a
tab and going through them all just to see if any have enough votes for
a decision yet; it'd be much more efficient if I could just see the
totals at a glance on the blockerbugs web UI overview.
Filed as https://pagure.io/fedora-qa/blockerbugs/issue/150
On Thu, Nov 12, 2020 at 9:25 PM Chris Murphy <lists(a)colorremedies.com>
I often had to click the 'how to vote' link in a separate tab
copy/paste the proper tag. It'd be nice if the list of possible voting
tags is simply incorporated into the initial issue text.
Do you mean the list of trackers - BetaBlocker, FinalBlocker, BetaFE,
FinalFE, 0Day, PreviousRelease? I found them quite easy to remember, once
you vote in a few tickets. But we can surely include them in every ticket
description, along with the link to the full documentation. I just want to
make sure I understand you. Or do you mean something different?
On Thu, Nov 12, 2020 at 11:41 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
Sometimes the ticket titles were not very informative, but thats
the fault of the bug really.
Well, we can easily add e.g. the component the bug was proposed against at
the time of the ticket creation. That would add a bit more context. I
wanted to keep the ticket title and contents pretty light, because we don't
have any infrastructure set up to keep the data synchronized. So if the bug
title changes, we don't update it. The same would apply for the component,
or release version, currently proposed blockers, etc. And my worry is that
it might easily become confusing, if we show a lot of outdated information.
We improved that situation at least a little by showing inline images in
the ticket description that poll blockerbugs app and show whether the bug
is open or closed and which trackers it has already been accepted/rejected
with (unfortunately that image loads very slow due to
We could add plumbing to update the mentioned data, but it's a lot of work
and I'm concerned about reliability. The envision workflow was that you
visit the ticket through blockerbugs web app, and so you already know most
of the metadata from there. Of course if you sign up for new ticket
notifications on the project itself, that's not the case, you're visiting
the ticket directly. I'm just not sure if the cost/benefit ratio is good
here for mirroring the data inside the ticket.
Could there be some way to list what critera is being used in the
I don't know how we could do that. It's true that sometimes people mention
the criterion in Bugzilla while proposing the blocker, but it's a free-form
text that we can't easily process. Also, often people don't mention any
criterion when proposing this. And then people argue about the best
criterion in the ticket. The arguing sometimes happens even if a criterion
*was* originally proposed. So I don't know how to highlight it.
Is there any plans for a cleanup cycle? ie, now that f33 is out,
out all the f33 tickets?
Yes, Lukas Brabec is working on it in
On Fri, Nov 13, 2020 at 5:21 PM Ben Cotton <bcotton(a)redhat.com> wrote:
I always forgot what the commands were.
Alright, that's a similar feedback to Chris'. Could you specify what
exactly did you not remember? The tracker names (FinalBlocker, FinalFE,
etc)? Their CamelCase format (hint: case doesn't matter)? Or the order of
the voting command (FinalBlocker +1)? Or just everything together?
I tried to create the tracker names in the same spirit as we use it at IRC
meetings and in Bugzilla (well, in Bugzilla we use FreezeException instead
of FE, but I thought everybody would hate me for making them write long
words in each ticket). At IRC meetings we usually have the order reversed
("+1 BetaBlocker"), but I swapped it because it was easier to implement
parsing with the tracker name being first, which also seemed more logical
It seems we definitely need some cheat sheet in each ticket.
What Adam and others have said, plus an expansion on "It'd
nice if the web UI showed the current vote counts from
the ticket.". Specifically, I'd like to see the IRC format include
# info Current vote in ticket is (+X,Y,-Z)
I included that by hand when I was running the meetings, but it'd be
nice to let the computer do it for me. Additionally, we might want to
include the names of people who voted and how. Not as certain if I'd
actually want that or not.
I filed https://pagure.io/fedora-qa/blockerbugs/issue/150
Thanks everyone for feedback. This is very helpful. I can't promise we'll
quickly implement most of this, but I'll try to prioritize the mentioned
problems and regularly annoy Lukas Brabec (who's done most of the code so
far) to make him fix them :-)
Please continue submitting ideas, if you have some. Thanks.