I don't know if there have been any thoughts around on this, but I think there is no form of policy in place regarding the CentOS bug-tracker? I'm thinking along stuff like i.e. no activity for > 1 year --> close issue.
I would like to hear feedback (suggestions if there are some) on this thought. If we want to move something like that into place (and there is enough feedback), i'd be willing to write an initial draft to expand upon.
Thanks and Cheers Christoph
On Wed, Jan 8, 2014 at 10:16 AM, Christoph Galuschka tigalch@tigalch.org wrote:
I don't know if there have been any thoughts around on this, but I think there is no form of policy in place regarding the CentOS bug-tracker? I'm thinking along stuff like i.e. no activity for > 1 year --> close issue.
I would like to hear feedback (suggestions if there are some) on this thought. If we want to move something like that into place (and there is enough feedback), i'd be willing to write an initial draft to expand upon.
Thanks for bringing this up. My main "concern" is that bugs.c.o. has not been receiving much attention by the community as well as by the admin team. It can use more assistance / man power and that should help speed up identifying and resolving bugs, or discarding non-bugs and redirect users to support venues.
There are those that definitely need actions from the admin side. I'm hoping, with the latest arrangement, that the devteam would be able to spend more time for the stuff hanging in bugs.c.o. Then, anything that is still left unresolved > 1 year might have to be "given up" and closed as such.
Akemi
On Thu, 9 Jan 2014, Akemi Yagi wrote:
On Wed, Jan 8, 2014 at 10:16 AM, Christoph Galuschka tigalch@tigalch.org wrote:
I don't know if there have been any thoughts around on this, but I think there is no form of policy in place regarding the CentOS bug-tracker? I'm thinking along stuff like i.e. no activity for > 1 year --> close issue.
...
Thanks for bringing this up. My main "concern" is that bugs.c.o. has not been receiving much attention by the community as well as by the admin team. It can use more assistance / man power and that should help speed up identifying and resolving bugs, or discarding non-bugs and redirect users to support venues.
There are those that definitely need actions from the admin side. I'm hoping, with the latest arrangement, that the devteam would be able to spend more time for the stuff hanging in bugs.c.o. Then, anything that is still left unresolved > 1 year might have to be "given up" and closed as such.
I think it is timely to be raising this given the newly announced relationship with Red Hat.
I've always felt the bugs.c.o should mostly just be a waypoint en route to bugzilla.redhat.com. First determine if the problem is a build problem - if so, resolve it within CentOS. Otherwise, refer the bug reporter to bugzilla.redhat.com and close the bug. That last step was always troublesome, because the bug reporter has no relationship with RH, and the problem hasn't been specifically reported against RHEL. The new relationship creates the possibility of negotiating a combined approach to bug tracking with RH, so that bug reports and analysis and fixes and workarounds are pooled between centos and RHEL.
I would recommend that CentOS core people ask RH how CentOS can best help with bug reporting and analysis. I doubt they will think that pretending that CentOS and RHEL are separate products helps in the overall goal of responding well and quickly to any bug reports.
--- Charlie
On 01/09/2014 12:45 PM, Charlie Brady wrote:
On Thu, 9 Jan 2014, Akemi Yagi wrote:
On Wed, Jan 8, 2014 at 10:16 AM, Christoph Galuschka tigalch@tigalch.org wrote:
I don't know if there have been any thoughts around on this, but I think there is no form of policy in place regarding the CentOS bug-tracker? I'm thinking along stuff like i.e. no activity for > 1 year --> close issue.
...
Thanks for bringing this up. My main "concern" is that bugs.c.o. has not been receiving much attention by the community as well as by the admin team. It can use more assistance / man power and that should help speed up identifying and resolving bugs, or discarding non-bugs and redirect users to support venues.
That's pretty accurate, and I'm very guilty of it myself.
There are those that definitely need actions from the admin side. I'm hoping, with the latest arrangement, that the devteam would be able to spend more time for the stuff hanging in bugs.c.o. Then, anything that is still left unresolved > 1 year might have to be "given up" and closed as such.
Initial reaction is that I'm fine killing bugs that are now over a year old.
I think it is timely to be raising this given the newly announced relationship with Red Hat.
I've always felt the bugs.c.o should mostly just be a waypoint en route to bugzilla.redhat.com. First determine if the problem is a build problem - if so, resolve it within CentOS. Otherwise, refer the bug reporter to bugzilla.redhat.com and close the bug. That last step was always troublesome, because the bug reporter has no relationship with RH, and the problem hasn't been specifically reported against RHEL. The new relationship creates the possibility of negotiating a combined approach to bug tracking with RH, so that bug reports and analysis and fixes and workarounds are pooled between centos and RHEL.
A couple things in this one. We won't ever really be 'pooled' with RHEL. While we're now working together, that combined effort is focused on the community space, and not really at the engineering level. We don't have any influence on the RHEL engineering folks.
Other than that, the plan is reasonably solid, and in theory that's how it should work.
I would recommend that CentOS core people ask RH how CentOS can best help with bug reporting and analysis. I doubt they will think that pretending that CentOS and RHEL are separate products helps in the overall goal of responding well and quickly to any bug reports.
We did kick this around a bit during some of our talks however it wasn't a key topic item.
I'd like to streamline the process a bit, because having a user create an account, file a bug, have the bug verified as 'not ours', then have them create an account in bugzilla, file the bug again, etc.. is a little cumbersome.
The issue of bugs will become even more important when the variants get going, so we do need to kick this around reasonably soon.
On 01/09/2014 06:45 PM, Charlie Brady wrote:
I would recommend that CentOS core people ask RH how CentOS can best help with bug reporting and analysis. I doubt they will think that pretending that CentOS and RHEL are separate products helps in the overall goal of responding well and quickly to any bug reports.
I think Jim has already hit the nail on the head - lets not assume that all reports at bugs.c.o map to the distro. Most do, but not all. Also, the idea has always been that components that we inherit from upstream should have issues propogated upstream once we are reasonabally sure we didnt inject the issue ourselves.
Also, its been possible to cross reference a CentOS bug issue at bz.r.c for quite a few years :)
On 01/09/2014 06:05 PM, Akemi Yagi wrote:
Thanks for bringing this up. My main "concern" is that bugs.c.o. has not been receiving much attention by the community as well as by the admin team. It can use more assistance / man power and that should help speed up identifying and resolving bugs, or discarding non-bugs and redirect users to support venues.
thats an important thing - quite a few of those are just people asking for help or 'hey i installed this thing, now what'; so i mostly defer to the QA folks to triage
There are those that definitely need actions from the admin side. I'm hoping, with the latest arrangement, that the devteam would be able to spend more time for the stuff hanging in bugs.c.o. Then, anything that is still left unresolved > 1 year might have to be "given up" and closed as such.
The idea of 'devteam' is going to erode a bit moving forward, which is good - because the throwback should be a much larger group of people able to execute / change / propose-change.
How about we recap in 6 months to see if that has happened ?
- KB
Karanbir Singh kirjoitti:
On 01/09/2014 06:05 PM, Akemi Yagi wrote:
Thanks for bringing this up. My main "concern" is that bugs.c.o. has not been receiving much attention by the community as well as by the admin team. It can use more assistance / man power and that should help speed up identifying and resolving bugs, or discarding non-bugs and redirect users to support venues.
thats an important thing - quite a few of those are just people asking for help or 'hey i installed this thing, now what'; so i mostly defer to the QA folks to triage
I do agree that bugs.c.o should be looked at, and cleaned up of old problem reports, one way or another.
Now that bugs.c.o is somewhat less visible than what it was with the old website, I'm hoping that the majority of "I have a problem, help!" questions will end up to the forum, where they might be easier to triage. In addition, the forum (and IRC) allow easier community participation in resolving problems. bugs.c.o is mainly handled by the devs and QA people.
If something ends up being a real bug, it should be easy to tell users on the forum/IRC to file a bug at either bugs.c.o or bz.r.c, as appropriate.
If someone has a problem like "My server is not booting, help!", it's going to take a while to determine if the problem is really a bug or not. I'd like to have those discussions either on the forum or on IRC, so bugs.c.o would only get real bugs that actually need fixing.
On 01/09/2014 11:10 PM, Anssi Johansson wrote:
Now that bugs.c.o is somewhat less visible than what it was with the old website, I'm hoping that the majority of "I have a problem, help!" questions will end up to the forum, where they might be easier to triage. In addition, the forum (and IRC) allow easier community participation in resolving problems. bugs.c.o is mainly handled by the devs and QA people.
how do you propose we make the bugs.c.o more visible. The wiki /GettingHelp page might be something to clean up, almost certainly shorten and promoted ?
If something ends up being a real bug, it should be easy to tell users on the forum/IRC to file a bug at either bugs.c.o or bz.r.c, as appropriate.
generally, all bugs found on CentOS builds should goto bugs.c.o - depending on how much time someone @redhat wants to spend with us there, the option to migrate an issue to bz.r.c should only happen after someone who understands the difference, has had a look to verify.
ofcourse, if something is clearly an upstream issue, then by all means send people there - but value of CentOS-> RH bz goes up everytime there is a real issue reported.
If someone has a problem like "My server is not booting, help!", it's going to take a while to determine if the problem is really a bug or not. I'd like to have those discussions either on the forum or on IRC, so bugs.c.o would only get real bugs that actually need fixing.
absolutely.
Karanbir Singh kirjoitti:
On 01/09/2014 11:10 PM, Anssi Johansson wrote:
Now that bugs.c.o is somewhat less visible than what it was with the old website, I'm hoping that the majority of "I have a problem, help!" questions will end up to the forum, where they might be easier to triage. In addition, the forum (and IRC) allow easier community participation in resolving problems. bugs.c.o is mainly handled by the devs and QA people.
how do you propose we make the bugs.c.o more visible. The wiki /GettingHelp page might be something to clean up, almost certainly shorten and promoted ?
No, having bugs.c.o linked from www.c.o > Community > Contribute is enough for me. I don't want more visibility for bugs.c.o, the current situation is fine for me. Others may have differing opinions about this (such as http://bugs.centos.org/view.php?id=6886 ).
On Thu, Jan 9, 2014 at 3:59 PM, Anssi Johansson centos@miuku.net wrote:
Karanbir Singh kirjoitti:
On 01/09/2014 11:10 PM, Anssi Johansson wrote:
Now that bugs.c.o is somewhat less visible than what it was with the old website, I'm hoping that the majority of "I have a problem, help!" questions will end up to the forum, where they might be easier to triage. In addition, the forum (and IRC) allow easier community participation in resolving problems. bugs.c.o is mainly handled by the devs and QA people.
how do you propose we make the bugs.c.o more visible. The wiki /GettingHelp page might be something to clean up, almost certainly shorten and promoted ?
No, having bugs.c.o linked from www.c.o > Community > Contribute is enough for me. I don't want more visibility for bugs.c.o, the current situation is fine for me. Others may have differing opinions about this (such as http://bugs.centos.org/view.php?id=6886 ).
Surely, I beg to differ. :-)
The fact that the forum user who found some links on the new website that needed corrections but was unable to find a link to bugs.c.o. prompted me to file that bug report yesterday. And because it is there, let's move this talk over to that bug tracker, shall we?
Akemi
On Thu, Jan 9, 2014 at 3:42 PM, Karanbir Singh mail-lists@karan.org wrote:
generally, all bugs found on CentOS builds should goto bugs.c.o - depending on how much time someone @redhat wants to spend with us there, the option to migrate an issue to bz.r.c should only happen after someone who understands the difference, has had a look to verify.
ofcourse, if something is clearly an upstream issue, then by all means send people there - but value of CentOS-> RH bz goes up everytime there is a real issue reported.
*ahem* One near perfect example from a recent case *ahem* :
http://bugs.centos.org/view.php?id=6843
A user took the case (a bug in firefox) to bugzilla.redhat.com. It was evident that the issue was with the package in RHEL, not introduced by CentOS. So, to further promote it, I opened a support case with RH. They were able to reproduce it and are analyzing the issue at this moment.
Akemi
On 01/08/2014 06:16 PM, Christoph Galuschka wrote:
I don't know if there have been any thoughts around on this, but I think there is no form of policy in place regarding the CentOS bug-tracker? I'm thinking along stuff like i.e. no activity for > 1 year --> close issue.
I would like to hear feedback (suggestions if there are some) on this thought. If we want to move something like that into place (and there is enough feedback), i'd be willing to write an initial draft to expand upon.
Perhaps asking the QA team to do a sweep, for that Version at a point release time - might be a better solution than making it time driven. When 6.6 comes around, in the days it takes the build team to get an isos and rpm content into qa, perhaps ensure any bug filed before is 'considered'. Unlike bz.r.c we only seem to get a few hundred bugs between point releases.
Would that sort of a thing address your concern ?
-
Akemi Yagi -
Anssi Johansson -
Charlie Brady -
Christoph Galuschka -
Jim Perrin -
Karanbir Singh