Just bringing this topic to the appropriate mailing list
On the last kernel meeting [1] it was suggested negative karma points should be linked to a reported bug which kinda makes sense if you think about it.
What that means is that you ( as in reporter ) will no longer be able to provide negative karma without linking it to an already existing bug report either created by your or someone else if that came to be.
Now this has been discussed and rejected before by Fesco here [2].
From my point of view FESCO should not be sticking their nose in this topic
since I think it's up to ourselves ( the QA community ) to decide whether we want to implement this or not hence I posted this here to this list for further discussion.
I myself give +1 to implement this since give negative feedback without linking to an already existing bug report helps no one.
There was also mentioned on the meeting that reporters seem to be giving negative karma for bugs that never where mentioned getting fixed in the updates.
Doing this is a big NO NO since this will lead to fixes for bugs that got mentioned being fixed in the update not reaching our end user base because of that negative karma so I'm gonna ask reporters that did that to stop doing that.
Thanks JBG
1. http://lists.fedoraproject.org/pipermail/kernel/2012-June/003886.html 2. http://meetbot.fedoraproject.org/teams/fesco/fesco.2010-09-07-19.30.log.html
On Wed, Jun 27, 2012 at 15:54:18 +0000, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
I myself give +1 to implement this since give negative feedback without linking to an already existing bug report helps no one.
There was also mentioned on the meeting that reporters seem to be giving negative karma for bugs that never where mentioned getting fixed in the updates.
It may make sense to only allow negative karma if there is a link to an open bug that is not one of the bugs listed as being fixed in this update. (If one of the listed bugs isn't really fixed, this is normally a +0 or +1 karma situation along with a note explaining the issue.)
In theory it's possible for a linked bug fix to be a bug introduced in a previous test build and be a regression against stable. But that's pretty rare.
On Wed, Jun 27, 2012 at 4:58 PM, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Jun 27, 2012 at 15:54:18 +0000, "Jóhann B. Gušmundsson" johannbg@gmail.com wrote:
I myself give +1 to implement this since give negative feedback without linking to an already existing bug report helps no one.
There was also mentioned on the meeting that reporters seem to be giving negative karma for bugs that never where mentioned getting fixed in the updates.
It may make sense to only allow negative karma if there is a link to an open bug that is not one of the bugs listed as being fixed in this update. (If one of the listed bugs isn't really fixed, this is normally a +0 or +1 karma situation along with a note explaining the issue.)
If we move in this direction then I think it's safe to say that the comment section should be removed as well since the reporter should be making his remark in the relevant bug report arguably not in some comment section in bodhi.
Basically the reporter logs into bodhi and his only option are giving either a +1 or -1 and provide a link to an bug report
JBG
On Wed, 2012-06-27 at 15:54 +0000, Jóhann B. Guðmundsson wrote:
Just bringing this topic to the appropriate mailing list
On the last kernel meeting [1] it was suggested negative karma points should be linked to a reported bug which kinda makes sense if you think about it.
What that means is that you ( as in reporter ) will no longer be able to provide negative karma without linking it to an already existing bug report either created by your or someone else if that came to be.
Now this has been discussed and rejected before by Fesco here [2].
From my point of view FESCO should not be sticking their nose in this topic since I think it's up to ourselves ( the QA community ) to decide whether we want to implement this or not hence I posted this here to this list for further discussion.
It's hardly 'sticking their nose in'. The updates policy is owned by FESCo, not by us. In practice, I'd say the point is kinda moot because this is clearly Bodhi 2.0 stuff, and we've been waiting for Bodhi 2.0 forever and a day, and it'll be very different from current Bodhi, so we should probably just keep waiting for it and re-evaluate the whole process once it _finally_ arrives.
I myself give +1 to implement this since give negative feedback without linking to an already existing bug report helps no one.
There was also mentioned on the meeting that reporters seem to be giving negative karma for bugs that never where mentioned getting fixed in the updates.
Doing this is a big NO NO since this will lead to fixes for bugs that got mentioned being fixed in the update not reaching our end user base because of that negative karma so I'm gonna ask reporters that did that to stop doing that.
Yeah, this is mentioned in the proven tester instructions (which are useful for all updates testers, really, so we could probably adjust the wiki to point to them more prominently) - it's not correct to give a -1 just because an update doesn't fix a bug. It's not correct even if the update _does_ claim to fix the bug, unless it's the only thing the update does. If the update has other beneficial changes, then 'it doesn't fix one bug' is not a valid reason to hold it up.
On 06/27/2012 06:19 PM, Adam Williamson wrote:
It's hardly 'sticking their nose in'. The updates policy is owned by FESCo, not by us.
WooT?
In practice, I'd say the point is kinda moot because this is clearly Bodhi 2.0 stuff, and we've been waiting for Bodhi 2.0 forever and a day, and it'll be very different from current Bodhi, so we should probably just keep waiting for it and re-evaluate the whole process once it_finally_ arrives.
I disagree we should reach decision now and have it implement ( or not ) when bodh 2.0 finally arrives.
It kinda goes without saying that it's better for the developers to add it now rather then after they release + it would give us time to test it
JBG
On Wed, 2012-06-27 at 18:34 +0000, "Jóhann B. Guðmundsson" wrote:
On 06/27/2012 06:19 PM, Adam Williamson wrote:
It's hardly 'sticking their nose in'. The updates policy is owned by FESCo, not by us.
WooT?
In practice, I'd say the point is kinda moot because this is clearly Bodhi 2.0 stuff, and we've been waiting for Bodhi 2.0 forever and a day, and it'll be very different from current Bodhi, so we should probably just keep waiting for it and re-evaluate the whole process once it_finally_ arrives.
I disagree we should reach decision now and have it implement ( or not ) when bodh 2.0 finally arrives.
It kinda goes without saying that it's better for the developers to add it now rather then after they release + it would give us time to test it
That's a point, actually. But we'd need to look at it within the broader context of how Bodhi 2.0 is actually designed, because it's not at all designed around the Bodhi 1.0 concept of 'one numeric karma value and a comment box'. Luke, would you be available to join the QA meeting at 1500 UTC on Monday, for a discussion about Bodhi 2.0 and some possible feedback from us into the design? Thanks!
On Wed, Jun 27, 2012 at 11:54 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
Just bringing this topic to the appropriate mailing list
On the last kernel meeting [1] it was suggested negative karma points should be linked to a reported bug which kinda makes sense if you think about it.
What that means is that you ( as in reporter ) will no longer be able to provide negative karma without linking it to an already existing bug report either created by your or someone else if that came to be.
Is there such a surplus of people testing things and providing negative karma that it's acceptable to refuse any that doesn't come with a bug report? And is the pain of bugless negative karma so great that it will overcome the cost of an additional mandatory step in the karma reporting process?
Why not start by sending email nags to people who've added negative karma but who haven't provided a buglink?
On Thu, Jun 28, 2012 at 1:09 AM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Wed, Jun 27, 2012 at 11:54 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
Just bringing this topic to the appropriate mailing list
On the last kernel meeting [1] it was suggested negative karma points should be linked to a reported bug which kinda makes sense if you think about it.
What that means is that you ( as in reporter ) will no longer be able to provide negative karma without linking it to an already existing bug report either created by your or someone else if that came to be.
Is there such a surplus of people testing things and providing negative karma that it's acceptable to refuse any that doesn't come with a bug report? And is the pain of bugless negative karma so great that it will overcome the cost of an additional mandatory step in the karma reporting process?
IMO it should be optional but recommended. Enforcing it is not a good idea.
Why not start by sending email nags to people who've added negative karma but who haven't provided a buglink?
Well sending nag mails can become annoying resulting into people no longer providing karma.
On Wed, Jun 27, 2012 at 11:09 PM, Gregory Maxwell gmaxwell@gmail.comwrote:
On Wed, Jun 27, 2012 at 11:54 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
Just bringing this topic to the appropriate mailing list
On the last kernel meeting [1] it was suggested negative karma points
should
be linked to a reported bug which kinda makes sense if you think about
it.
What that means is that you ( as in reporter ) will no longer be able to provide negative karma without linking it to an already existing bug
report
either created by your or someone else if that came to be.
Is there such a surplus of people testing things and providing negative karma that it's acceptable to refuse any that doesn't come with a bug report? And is the pain of bugless negative karma so great that it will overcome the cost of an additional mandatory step in the karma reporting process?
I'm not seeing this as any additional obstacle for reporters seriously how harder is it to provide a link to a bug report vs filling in the comment field?
JBG
On 28/06/12 14:05, Jóhann B. Guðmundsson wrote:
I'm not seeing this as any additional obstacle for reporters seriously how harder is it to provide a link to a bug report vs filling in the comment field?
JBG
Do you really want a bugzilla report for each time, when dependencies break? IMHO requiring bz reports will drastically lower the number of testing reports, especially when you need to file a bug.
On Thu, Jun 28, 2012 at 12:12 PM, Matthias Runge mrunge@matthias-runge.dewrote:
On 28/06/12 14:05, Jóhann B. Guðmundsson wrote:
I'm not seeing this as any additional obstacle for reporters seriously how harder is it to provide a link to a bug report vs filling in the comment field?
JBG
Do you really want a bugzilla report for each time, when dependencies break?
No then again we should be catching those dependency breaks elsewhere
IMHO requiring bz reports will drastically lower the number of testing reports, especially when you need to file a bug.
Really now.
Since you seem to have those numbers ready please post them here and the method how you gathered them for let's say last 5 release cycle let's implement this for three to prove you right/wrong
On Thu, 2012-06-28 at 13:11 +0000, Jóhann B. Guðmundsson wrote:
Do you really want a bugzilla report for each time, when dependencies break?No then again we should be catching those dependency breaks elsewhere
AutoQA depcheck already does, and it's pretty reliable these days. The AutoQA team is working towards making the depcheck test no longer advisory, but 'mandatory' - preventing updates going through until depcheck is satisfied.
On Thu, 2012-06-28 at 12:05 +0000, Jóhann B. Guðmundsson wrote:
I'm not seeing this as any additional obstacle for reporters seriously how harder is it to provide a link to a bug report vs filling in the comment field?
Well, the extra work is in filing the bug report, if it doesn't already exist.
I simply don't like this idea, there is enough bugzilla noise and enough bureaucracy (read: obstacles) for anyone wanting to contribute (yes, even just clicking +1/-1 karma is a valuable contribution ...)
- is this opinion worth 0.02€? :-)
btw, reading the subject line, at first I understood it in a way that a negative karma comment will be mirrored into bugzilla comment of the appropriate bug _if it exists_
that would be good, IMO
note that *I* do updates based on - fixing actual bugs - "fixing" bugs reported by updates monitoring so at least one bug exists for each update
this may vary for different packages & contributors ...
K.
Dne St 27. června 2012 15:54:18, Jóhann B. Guðmundsson napsal(a):
Just bringing this topic to the appropriate mailing list
On the last kernel meeting [1] it was suggested negative karma points should be linked to a reported bug which kinda makes sense if you think about it.
What that means is that you ( as in reporter ) will no longer be able to provide negative karma without linking it to an already existing bug report either created by your or someone else if that came to be.
Now this has been discussed and rejected before by Fesco here [2].
From my point of view FESCO should not be sticking their nose in this topic since I think it's up to ourselves ( the QA community ) to decide whether we want to implement this or not hence I posted this here to this list for further discussion.
I myself give +1 to implement this since give negative feedback without linking to an already existing bug report helps no one.
There was also mentioned on the meeting that reporters seem to be giving negative karma for bugs that never where mentioned getting fixed in the updates.
Doing this is a big NO NO since this will lead to fixes for bugs that got mentioned being fixed in the update not reaching our end user base because of that negative karma so I'm gonna ask reporters that did that to stop doing that.
Thanks JBG
http://lists.fedoraproject.org/pipermail/kernel/2012-June/0038 86.html 2. http://meetbot.fedoraproject.org/teams/fesco/fesco.2010-09-07-1 9.30.log.html
On Thu, Jun 28, 2012 at 10:45 AM, Karel Volný kvolny@redhat.com wrote:
I simply don't like this idea, there is enough bugzilla noise and enough bureaucracy (read: obstacles) for anyone wanting to contribute (yes, even just clicking +1/-1 karma is a valuable contribution ...)
This is no additional bureocrasy thou you claim it to be and please do sell/explain it further what value you see in having reporters to just click +1/-1
Btw way please follow [1]
Thanks JBG
1. http://fedoraproject.org/wiki/Mailing_list_guidelines#Proper_posting_style
Dne Čt 28. června 2012 12:11:02, Jóhann B. Guðmundsson napsal(a):
On Thu, Jun 28, 2012 at 10:45 AM, Karel Volný
kvolny@redhat.com wrote:
I simply don't like this idea, there is enough bugzilla noise and enough bureaucracy (read: obstacles) for anyone wanting to contribute (yes, even just clicking +1/-1 karma is a valuable contribution ...)
This is no additional bureocrasy thou you claim it to be
please elaborate on this
situation now: step 1. follow a link to bodhi step 2. click "Add a comment" (optional) step 3. write a comment what doesn't work for you step 4. click "does not work" step 5. click "Add Comment"
your proposal: step 1. follow a link to bodhi step 2. click "Add a comment" step 3. open Bugzilla in another window step 4. click New steps 5.-96. do all the things you have to do to properly file a bug step 97. return to bodhi step 98. write a comment which includes the newly reported bug number step 99. "click does not work" step 100. click "Add Comment"
you really don't see anything additional in the second case?
and please do sell/explain it further what value you see in having reporters to just click +1/-1
I see whether someone actually bothered to test the update, and what is the result
Btw way please follow [1]
http://fedoraproject.org/wiki/Mailing_list_guidelines#Proper_po sting_style
it was directed to a topic as a whole, not to a specific paragraph of your text ... sorry for not removing the original message not to "increase the size of the daily digests" but I'd find it more "highly confusing and incoherent" if I'd just deleted it
btw, please follow http://fedoraproject.org/wiki/Mailing_list_guidelines#Be_Courteous (or is it just me who finds it at least a bit strange to start the thread by ill-founded, as Adam pointed out, attack on FESCO?)
K.
On Thu, Jun 28, 2012 at 2:57 PM, Karel Volný kvolny@redhat.com wrote:
Dne Čt 28. června 2012 12:11:02, Jóhann B. Guðmundsson napsal(a):
On Thu, Jun 28, 2012 at 10:45 AM, Karel Volný
kvolny@redhat.com wrote:
I simply don't like this idea, there is enough bugzilla noise and enough bureaucracy (read: obstacles) for anyone wanting to contribute (yes, even just clicking +1/-1 karma is a valuable contribution ...)
This is no additional bureocrasy thou you claim it to be
please elaborate on this
situation now: step 1. follow a link to bodhi step 2. click "Add a comment" (optional) step 3. write a comment what doesn't work for you step 4. click "does not work" step 5. click "Add Comment"
your proposal: step 1. follow a link to bodhi step 2. click "Add a comment" step 3. open Bugzilla in another window step 4. click New steps 5.-96. do all the things you have to do to properly file a bug step 97. return to bodhi step 98. write a comment which includes the newly reported bug number step 99. "click does not work" step 100. click "Add Comment"
you really don't see anything additional in the second case?
No since the reporter should have already done all the steps involving the bug reporter which states either if this update introduced a regression or did not fix a bug that was claimed to be fixed in the update.
and please do sell/explain it further what value you see in having reporters to just click +1/-1
I see whether someone actually bothered to test the update, and what is the result
Right right could you point me to all the test cases for the packages you maintain that reporter should follow to properly test relevant's updated that is if they exist and if you happen to be one of the few that actually have some test cases for reporters to follow could you provide me to the link for the rest?
The case is we discussed this long time ago here in the QA community before you or Adamw or Tim joined and I can tell without a doubt there has been little to nothing changed since then in that regard.
Providing +1 karma in Bodhi today gives at best the meaning that an reporter updated and did not hit *notice* any regression, not that he conducted any extensive testing on the relevant component being updated.
Btw way please follow [1]
http://fedoraproject.org/wiki/Mailing_list_guidelines#Proper_po sting_style
it was directed to a topic as a whole, not to a specific paragraph of your text ... sorry for not removing the original message not to "increase the size of the daily digests" but I'd find it more "highly confusing and incoherent" if I'd just deleted it
btw, please follow http://fedoraproject.org/wiki/Mailing_list_guidelines#Be_Courteous (or is it just me who finds it at least a bit strange to start the thread by ill-founded, as Adam pointed out, attack on FESCO?)
There is nothing I'll founded in my claims against FESCO sticking their nose into our business they ( Atleast the people that where in it at that time ) in conjunction with FPC ( and again the people that where in it at that time ) have already contributed enough in preventing things being better than they could be with regards to QA .
It's us ( QA+Releng ) that have to implement maintain and oversee these processes to the best of our ability and a yay or nay at some meeting from people that aren't actively working on this stuff makes absolutely no sense
It's us QA Community in conjunction with Releng Community that ought to be making these decision period.
JBG
On Thu, 2012-06-28 at 15:57 +0000, Jóhann B. Guðmundsson wrote:
It's us ( QA+Releng ) that have to implement maintain and oversee these processes to the best of our ability and a yay or nay at some meeting from people that aren't actively working on this stuff makes absolutely no sense
That's not really true. We don't maintain the updates policy, FESCo does. We don't maintain Bodhi, infrastructure does. We don't maintain Bugzilla, RH engineering ops does. There isn't really much at all in the updates process that is owned/maintained by QA; we just have an obvious responsibility to contribute our testing.
On 06/28/2012 09:22 PM, Adam Williamson wrote:
That's not really true. We don't maintain the updates policy, FESCo does.
Yes that's what I'm saying as in why is Fesco maintaining the update policy instead of us + releng?
We don't maintain Bodhi, infrastructure does. We don't maintain Bugzilla, RH engineering ops does.
Yeah with regards to Bugzilla, our infrastructure team really ought to be maintaining our own private instance of it. If it continues to be run by RH engineering ops limiting us by some RHEL Customer rules and policies and what not that we have no clues who are then I guess I will have to start going against what I have advocated all these years and recommend that reporters stop using it and report bugs directly upstream as several maintainers within the project has wanted us to do for some time.
We already have had one project leaving Bugzilla perhaps it's time for us to do it as well.
There isn't really much at all in the updates process that is owned/maintained by QA; we just have an obvious responsibility to contribute our testing.
Arguably that should be changed...
JBG
On Thu, 2012-06-28 at 23:13 +0000, "Jóhann B. Guðmundsson" wrote:
On 06/28/2012 09:22 PM, Adam Williamson wrote:
That's not really true. We don't maintain the updates policy, FESCo does.
Yes that's what I'm saying as in why is Fesco maintaining the update policy instead of us + releng?
We don't maintain Bodhi, infrastructure does. We don't maintain Bugzilla, RH engineering ops does.
Yeah with regards to Bugzilla, our infrastructure team really ought to be maintaining our own private instance of it. If it continues to be run by RH engineering ops limiting us by some RHEL Customer rules and policies and what not that we have no clues who are then I guess I will have to start going against what I have advocated all these years and recommend that reporters stop using it and report bugs directly upstream as several maintainers within the project has wanted us to do for some time.
We already have had one project leaving Bugzilla perhaps it's time for us to do it as well.
There isn't really much at all in the updates process that is owned/maintained by QA; we just have an obvious responsibility to contribute our testing.
Arguably that should be changed...
Oh, I see. Well there's obviously a case for that, if we wanted to argue it, but it's not totally clear cut, as there's obviously a big 'packaging/engineering' component to updates as well as a 'testing' component, which is why it's currently under FESCo.
Jóhann B. Guðmundsson wrote:
On 06/28/2012 09:22 PM, Adam Williamson wrote:
That's not really true. We don't maintain the updates policy, FESCo does.
Yes that's what I'm saying as in why is Fesco maintaining the update policy instead of us + releng?
You could propose (to fesco) that responsibility be delegated
-- rex
On Thu, Jun 28, 2012 at 11:13:05PM +0000, "Jóhann B. Guðmundsson" wrote:
Yeah with regards to Bugzilla, our infrastructure team really ought to be maintaining our own private instance of it. If it continues to be run by RH engineering ops limiting us by some RHEL Customer rules and policies and what not that we have no clues who are then I guess
Please provide a list of issues that hinder you / the QA community because Bugzilla is used / maintained by Red Hat. If you need certain features in Bugzilla, you can get them into upstream Bugzilla and they will land some day in Fedora's Bugzilla. And lot of stuff can probably be implemented by using Bugzilla's RPC interface.
Regards Till
On Fri, 2012-06-29 at 21:26 +0200, Till Maas wrote:
On Thu, Jun 28, 2012 at 11:13:05PM +0000, "Jóhann B. Guðmundsson" wrote:
Yeah with regards to Bugzilla, our infrastructure team really ought to be maintaining our own private instance of it. If it continues to be run by RH engineering ops limiting us by some RHEL Customer rules and policies and what not that we have no clues who are then I guess
Please provide a list of issues that hinder you / the QA community because Bugzilla is used / maintained by Red Hat. If you need certain features in Bugzilla, you can get them into upstream Bugzilla and they will land some day in Fedora's Bugzilla. And lot of stuff can probably be implemented by using Bugzilla's RPC interface.
Well, there's a lot of stuff to Bugzilla which is local site configuration, and there _are_ cases where the configuration of RH Bugzilla is compromised by having to work for both RHEL and Fedora.
To give an example I've been trying to sort out for _years_ - there is a somewhat significant flaw in our blocker/NTH process. You nominate a bug as blocker/NTH by setting it as blocking the tracker bug. But regular users can't actually set bugs as blocking other bugs, in RH BZ. Only people with editbugs privileges can. All packagers and Bugzappers have editbugs privileges, but not all registered users do. So if you're just a regular Fedora user and you file a bug that should be a blocker - you can't actually nominate it yourself. You have to ask someone who has privileges to do it for you. That kind of sucks, and I've had a ticket with eng ops to get it changed for a long time now, but it hasn't happened yet, and that's partly due to the fact that it wouldn't necessarily be good for RHEL if any registered user could alter the Blocks: field on a bug.
(For anyone interested in this issue, the current state in the art is https://bugzilla.redhat.com/show_bug.cgi?id=707252 , where you can marvel at the utter lack of activity. Sigh. I do suspect that if we had a Fedora bugzilla, this would have been sorted out by now. Of course, this one sole issue probably doesn't outweigh the duplication of effort involved in running a separate Fedora bugzilla, but I'm sure there are others).
On Fri, Jun 29, 2012 at 01:34:53PM -0700, Adam Williamson wrote:
Well, there's a lot of stuff to Bugzilla which is local site configuration, and there _are_ cases where the configuration of RH Bugzilla is compromised by having to work for both RHEL and Fedora.
To give an example I've been trying to sort out for _years_ - there is a somewhat significant flaw in our blocker/NTH process. You nominate a bug as blocker/NTH by setting it as blocking the tracker bug. But regular users can't actually set bugs as blocking other bugs, in RH BZ. Only people with editbugs privileges can. All packagers and Bugzappers have editbugs privileges, but not all registered users do. So if you're just a regular Fedora user and you file a bug that should be a blocker - you can't actually nominate it yourself. You have to ask someone who has privileges to do it for you. That kind of sucks, and I've had a ticket with eng ops to get it changed for a long time now, but it hasn't happened yet, and that's partly due to the fact that it wouldn't necessarily be good for RHEL if any registered user could alter the Blocks: field on a bug.
(For anyone interested in this issue, the current state in the art is https://bugzilla.redhat.com/show_bug.cgi?id=707252 , where you can marvel at the utter lack of activity. Sigh. I do suspect that if we had a Fedora bugzilla, this would have been sorted out by now. Of course, this one sole issue probably doesn't outweigh the duplication of effort involved in running a separate Fedora bugzilla, but I'm sure there are others).
From looking in Bugzilla's documentation this does not seem to be a RHEL
vs. Fedora problem since Bugzilla only allows to use a experimental feature to get this fine grained control, which might also not be supported by the Fedora infrastructure team, if they managed Bugzilla.
Nevertheless it seems to be easy to workaround, for example by using the whiteboard as an additional way to propose blocker/NTH bugs. It should even be possible to write an additional service that scans for bugs with the respective whiteboard field and adding the bug to the respective tracker bug.
Regards Till
On Sat, 2012-06-30 at 01:13 +0200, Till Maas wrote:
Nevertheless it seems to be easy to workaround, for example by using the whiteboard as an additional way to propose blocker/NTH bugs. It should even be possible to write an additional service that scans for bugs with the respective whiteboard field and adding the bug to the respective tracker bug.
The problem with the whiteboard field is it's too vulnerable to error: you can typo easily, and anyone putting anything else there can intentionally or inadvertently overwrite what anyone else has put in it. It's such a fragile field I'm never happy relying on it...even using it for accepted/rejected status as we do now was meant to be a stopgap.
Adjusting the process for nominating blockers is a legitimate way out of the problem, of course, but I don't think using the whiteboard field is a good alternative. Any other ideas? :)
On Fri, Jun 29, 2012 at 04:38:18PM -0700, Adam Williamson wrote:
On Sat, 2012-06-30 at 01:13 +0200, Till Maas wrote:
Nevertheless it seems to be easy to workaround, for example by using the whiteboard as an additional way to propose blocker/NTH bugs. It should even be possible to write an additional service that scans for bugs with the respective whiteboard field and adding the bug to the respective tracker bug.
The problem with the whiteboard field is it's too vulnerable to error: you can typo easily, and anyone putting anything else there can intentionally or inadvertently overwrite what anyone else has put in it. It's such a fragile field I'm never happy relying on it...even using it for accepted/rejected status as we do now was meant to be a stopgap.
If for example all Bugzilla notification mails are screened for changes in the whiteboard field, it would be enough for someone to add it properly once to notify the blocker/NTH committee of its existence.
Adjusting the process for nominating blockers is a legitimate way out of the problem, of course, but I don't think using the whiteboard field is a good alternative. Any other ideas? :)
Other ideas: - Screening for special keywords in comments - Allowing to add blocker proposals to a wiki page and screen changes - Allow to send blocker proposals to a special e-mail address - Provide a special web app where bug IDs can be entered
Regards Till
On Sat, 2012-06-30 at 11:09 +0200, Till Maas wrote:
On Fri, Jun 29, 2012 at 04:38:18PM -0700, Adam Williamson wrote:
On Sat, 2012-06-30 at 01:13 +0200, Till Maas wrote:
Nevertheless it seems to be easy to workaround, for example by using the whiteboard as an additional way to propose blocker/NTH bugs. It should even be possible to write an additional service that scans for bugs with the respective whiteboard field and adding the bug to the respective tracker bug.
The problem with the whiteboard field is it's too vulnerable to error: you can typo easily, and anyone putting anything else there can intentionally or inadvertently overwrite what anyone else has put in it. It's such a fragile field I'm never happy relying on it...even using it for accepted/rejected status as we do now was meant to be a stopgap.
If for example all Bugzilla notification mails are screened for changes in the whiteboard field, it would be enough for someone to add it properly once to notify the blocker/NTH committee of its existence.
Adjusting the process for nominating blockers is a legitimate way out of the problem, of course, but I don't think using the whiteboard field is a good alternative. Any other ideas? :)
Other ideas:
- Screening for special keywords in comments
- Allowing to add blocker proposals to a wiki page and screen changes
- Allow to send blocker proposals to a special e-mail address
- Provide a special web app where bug IDs can be entered
I'm not a huge fan of any of these because they all require manual translation of the request, and that's something that's always going to go wrong at some point. What the current method achieves is it feeds the nomination straight into our actual blocker handling workflow, which is entirely centred around Bugzilla. There's no manual 'handling' of the nomination needed, it's just...done. I'd definitely like to keep that element.
On Sun, Jul 01, 2012 at 05:58:44PM -0700, Adam Williamson wrote:
On Sat, 2012-06-30 at 11:09 +0200, Till Maas wrote:
If for example all Bugzilla notification mails are screened for changes in the whiteboard field, it would be enough for someone to add it properly once to notify the blocker/NTH committee of its existence.
Other ideas:
- Screening for special keywords in comments
- Allowing to add blocker proposals to a wiki page and screen changes
- Allow to send blocker proposals to a special e-mail address
- Provide a special web app where bug IDs can be entered
I'm not a huge fan of any of these because they all require manual translation of the request, and that's something that's always going to go wrong at some point. What the current method achieves is it feeds the nomination straight into our actual blocker handling workflow, which is entirely centred around Bugzilla. There's no manual 'handling' of the nomination needed, it's just...done. I'd definitely like to keep that element.
I though it was obvious, but of course there does not need to be any manual translation, but a script that automatically adds the specified bugs to the tracking bug.
Regards Till
On Mon, 2012-07-02 at 09:07 +0200, Till Maas wrote:
On Sun, Jul 01, 2012 at 05:58:44PM -0700, Adam Williamson wrote:
On Sat, 2012-06-30 at 11:09 +0200, Till Maas wrote:
If for example all Bugzilla notification mails are screened for changes in the whiteboard field, it would be enough for someone to add it properly once to notify the blocker/NTH committee of its existence.
Other ideas:
- Screening for special keywords in comments
- Allowing to add blocker proposals to a wiki page and screen changes
- Allow to send blocker proposals to a special e-mail address
- Provide a special web app where bug IDs can be entered
I'm not a huge fan of any of these because they all require manual translation of the request, and that's something that's always going to go wrong at some point. What the current method achieves is it feeds the nomination straight into our actual blocker handling workflow, which is entirely centred around Bugzilla. There's no manual 'handling' of the nomination needed, it's just...done. I'd definitely like to keep that element.
I though it was obvious, but of course there does not need to be any manual translation, but a script that automatically adds the specified bugs to the tracking bug.
Oh, right. Well, that makes more sense, but it seems like a lot more moving parts than the current set up...
On Tue, Jul 03, 2012 at 11:07:19AM -0700, Adam Williamson wrote:
On Mon, 2012-07-02 at 09:07 +0200, Till Maas wrote:
On Sun, Jul 01, 2012 at 05:58:44PM -0700, Adam Williamson wrote:
On Sat, 2012-06-30 at 11:09 +0200, Till Maas wrote:
If for example all Bugzilla notification mails are screened for changes in the whiteboard field, it would be enough for someone to add it properly once to notify the blocker/NTH committee of its existence.
Other ideas:
- Screening for special keywords in comments
- Allowing to add blocker proposals to a wiki page and screen changes
- Allow to send blocker proposals to a special e-mail address
- Provide a special web app where bug IDs can be entered
I'm not a huge fan of any of these because they all require manual translation of the request, and that's something that's always going to go wrong at some point. What the current method achieves is it feeds the nomination straight into our actual blocker handling workflow, which is entirely centred around Bugzilla. There's no manual 'handling' of the nomination needed, it's just...done. I'd definitely like to keep that element.
I though it was obvious, but of course there does not need to be any manual translation, but a script that automatically adds the specified bugs to the tracking bug.
Oh, right. Well, that makes more sense, but it seems like a lot more moving parts than the current set up...
From my point of view the proposed ideas are a lot easier than
setting up and maintaining a second Bugzilla instance.
Regards Till
On 07/05/2012 06:36 PM, Till Maas wrote:
From my point of view the proposed ideas are a lot easier than setting up and maintaining a second Bugzilla instance.
I'm not sure why your are referring to two bugzilla instances since there would be only one for the project the Fedora instance in anycase this is less about the ideas more about community freedom and control away from RHEL...
There are several things we cant do due to RHEL integration into that bugzilla instance and that's even after James pushed couple of ideas for improvement that might have improve things both for developers and reporters internally to the relevant places.
In addition to that we are ages behind upstream bugzilla release ( last time I checked ) which we otherwise might not be if we had our own instead of that corporate dictated one.
If we cant have our own instance I see no other alternative other than to motion that we stop using it altogether and the QA community calls for a community vote on that matter from both developers and reporters...
JBG
On Thu, Jul 05, 2012 at 18:50:15 +0000, ""Jóhann B. Guðmundsson"" johannbg@gmail.com wrote:
In addition to that we are ages behind upstream bugzilla release ( last time I checked ) which we otherwise might not be if we had our own instead of that corporate dictated one.
There was an upgrade shortly before the F17 release. Bugzilla is now pretty current (version 4.2.1-2.2).
On Thu, 2012-07-05 at 20:36 +0200, Till Maas wrote:
On Tue, Jul 03, 2012 at 11:07:19AM -0700, Adam Williamson wrote:
On Mon, 2012-07-02 at 09:07 +0200, Till Maas wrote:
On Sun, Jul 01, 2012 at 05:58:44PM -0700, Adam Williamson wrote:
On Sat, 2012-06-30 at 11:09 +0200, Till Maas wrote:
If for example all Bugzilla notification mails are screened for changes in the whiteboard field, it would be enough for someone to add it properly once to notify the blocker/NTH committee of its existence.
Other ideas:
- Screening for special keywords in comments
- Allowing to add blocker proposals to a wiki page and screen changes
- Allow to send blocker proposals to a special e-mail address
- Provide a special web app where bug IDs can be entered
I'm not a huge fan of any of these because they all require manual translation of the request, and that's something that's always going to go wrong at some point. What the current method achieves is it feeds the nomination straight into our actual blocker handling workflow, which is entirely centred around Bugzilla. There's no manual 'handling' of the nomination needed, it's just...done. I'd definitely like to keep that element.
I though it was obvious, but of course there does not need to be any manual translation, but a script that automatically adds the specified bugs to the tracking bug.
Oh, right. Well, that makes more sense, but it seems like a lot more moving parts than the current set up...
From my point of view the proposed ideas are a lot easier than setting up and maintaining a second Bugzilla instance.
That wasn't really the alternative I was positing. The current situation is obviously supportable as it's been working well enough for several releases.
It could stand improvement, but I'm not sure either pushing for a Fedora bugzilla or switching to less direct, more 'tooly' system for proposing blockers constitutes a straightforward improvement.
-
Adam Williamson -
Bruno Wolff III -
drago01 -
Gregory Maxwell -
Jóhann B. Guðmundsson -
Karel Volný -
Matthias Runge -
Rex Dieter -
Till Maas