Greetings you all
After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own.
Now it pretty much boils down to this.
1. Generic attitude of many maintainers is that reports either go to the correct place ( upstream ) or they get their bugzilla ignored. 2. More often than not downstream maintainer as in packager does not know the code at all so filling the bug downstream makes no sense since it brings just unnecessary latency to the process. 3. Hosting our own bugzilla cost resources and does not solve 1. or 2.
I personally for many years have argued against this since to an reporter it might mean having thousand of accounts but given that we are going through new fase and the times are changing in the linux eco system I would like to get your opinion about we stop reporting altogether in Red Hat bugzilla and report only directly upstream as in kernel bugs to the kernel community, Gnome bugs to theirs, KDE to their etc.
The obvious benefit of doing this is that our bugs might actually get look at,dealt with as well as all that being done in a shorter time frame.
Thoughts and comment.
JBG
On 09/23/2013 04:49 PM, "Jóhann B. Guðmundsson" wrote:
Greetings you all
After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own.
Now it pretty much boils down to this.
- Generic attitude of many maintainers is that reports either go to
the correct place ( upstream ) or they get their bugzilla ignored. 2. More often than not downstream maintainer as in packager does not know the code at all so filling the bug downstream makes no sense since it brings just unnecessary latency to the process. 3. Hosting our own bugzilla cost resources and does not solve 1. or 2.
I personally for many years have argued against this since to an reporter it might mean having thousand of accounts but given that we are going through new fase and the times are changing in the linux eco system I would like to get your opinion about we stop reporting altogether in Red Hat bugzilla and report only directly upstream as in kernel bugs to the kernel community, Gnome bugs to theirs, KDE to their etc.
The obvious benefit of doing this is that our bugs might actually get look at,dealt with as well as all that being done in a shorter time frame.
Thoughts and comment.
JBG
While I do think this is a good idea, I am a few immediate concerns on which I would request a bit more information/guidance -
1. What if a bug is due to a specific combination libraries or builds in Fedora and not necessarily an upstream issue?
2. In many cases, abrt does a nice job of collecting all the information needed to file a bug report? If we are repoting bugs directly to upstream, people who are not very familiar with the process might not be able to file bug reports properly, which might in turn annoy the developers. What would our workaround for this?
3, Will reporting to upstream be possible for new users? When I started using Fedora (or Linux in general, just three years ago), I had no idea what information was appropriate in a bug report much less know the various components! So, does anyone else think that reporting bugs to upstream has the potential to alienate enthusiastic new users?
On 09/23/2013 10:43 PM, nonamedotc wrote:
While I do think this is a good idea, I am a few immediate concerns on which I would request a bit more information/guidance -
- What if a bug is due to a specific combination libraries or builds
in Fedora and not necessarily an upstream issue?
Upstream will point that out and we take care of that then and there.
- In many cases, abrt does a nice job of collecting all the
information needed to file a bug report? If we are repoting bugs directly to upstream, people who are not very familiar with the process might not be able to file bug reports properly, which might in turn annoy the developers. What would our workaround for this?
Many years ago I started the how to debug process to address exactly what you express here in the distribution and at that time developers where pretty annoyed with poor bug reporting here we just continue with it where I left it but adapt it with and in accordance to upstream procedures.
3, Will reporting to upstream be possible for new users?
Yes why should it not be?
When I started using Fedora (or Linux in general, just three years ago), I had no idea what information was appropriate in a bug report much less know the various components! So, does anyone else think that reporting bugs to upstream has the potential to alienate enthusiastic new users?
I have hard time seeing that happening but given that I have experienced myself first hand certain openbsd kernel developer behaviour from upstream there is nothing that prevents that from happening.
JBG
How will you track blocker bugs?
How can we see a global view of all open bugs? Aggregate from X upstream bug report systems? Which not all are Bugzilla?
How can we track critical bugs?
Jan
Jan Wildeboer (jwildebo@redhat.com) said:
How will you track blocker bugs?
How can we see a global view of all open bugs? Aggregate from X upstream bug report systems? Which not all are Bugzilla?
How can we track critical bugs?
Additional concerns I'd have above this:
- Not all things we ship have active upstream bug trackers to fall back on - We still need a way to track Fedora-specific integration & packaging concerns, which would likely get closed upstream as 'NOTABUG' for that project - What filing downstream gives the Fedora maintainer is a good mechanism for knowing what's going on in that package in Fedora. Tracking *all* upstream bugs in a bug tracker may not be a good way to do so.
Honestly, I think a good dedicated triage team that works to verify and move upstream as appropriate works better. But, you know, requires getting and keeping such a team.
Bill
On 09/23/2013 11:07 PM, Bill Nottingham wrote:
Jan Wildeboer (jwildebo@redhat.com) said:
How will you track blocker bugs?
How can we see a global view of all open bugs? Aggregate from X upstream bug report systems? Which not all are Bugzilla?
How can we track critical bugs?
Additional concerns I'd have above this:
- Not all things we ship have active upstream bug trackers to fall back on
What do you think that tells us about the thing we are shipping?
- We still need a way to track Fedora-specific integration & packaging concerns, which would likely get closed upstream as 'NOTABUG' for that project
Yes we would.
- What filing downstream gives the Fedora maintainer is a good mechanism for knowing what's going on in that package in Fedora. Tracking *all* upstream bugs in a bug tracker may not be a good way to do so.
If that bug tracker would have a component field called distribution and in was fedora that would not be a problem but neither would it if everybody used the same kind of bug tracker or a global mutual bug tracker for all distro to use but that could be solved via Fedora tag line in the bug report itself with relevant upstream.
Honestly, I think a good dedicated triage team that works to verify and move upstream as appropriate works better. But, you know, requires getting and keeping such a team.
Quite frankly that has been proven not to work and quite frankly the packager should be the one playing that middle man ( which is not working either ).
On Mon, 23 Sep 2013 23:21:13 +0000, Jóhann B. Guðmundsson wrote:
On 09/23/2013 11:07 PM, Bill Nottingham wrote:
- Not all things we ship have active upstream bug trackers to fall back on
What do you think that tells us about the thing we are shipping?
Nothing. There are large projects as well as small projects, some with non-public bug tracking only, but with good reachability via email (or message boards or IRC).
Honestly, I think a good dedicated triage team that works to verify and move upstream as appropriate works better. But, you know, requires getting and keeping such a team.
Quite frankly that has been proven not to work and quite frankly the packager should be the one playing that middle man ( which is not working either ).
It's not feasible in all cases. It fails already, if a bug reporter doesn't answer questions (in the worst case whether the problem is reproducible with the latest development code?). The most a "middle man" can do in that case is forwarding a bug report upstream without prior triaging or contributing a patch. That's not very helpful. Especially not if a problem is not reproducible. There are upstreams that move on immediately, if the first attempt at reproducing a problem is not successful or if the backtrace may be just due to side-effects.
On Mon, 23 Sep 2013 19:07:04 -0400 Bill Nottingham notting@redhat.com wrote:
Jan Wildeboer (jwildebo@redhat.com) said:
How will you track blocker bugs?
How can we see a global view of all open bugs? Aggregate from X upstream bug report systems? Which not all are Bugzilla?
How can we track critical bugs?
Additional concerns I'd have above this:
- Not all things we ship have active upstream bug trackers to fall
back on
- We still need a way to track Fedora-specific integration & packaging concerns, which would likely get closed upstream as 'NOTABUG' for
that project
- What filing downstream gives the Fedora maintainer is a good
mechanism for knowing what's going on in that package in Fedora. Tracking *all* upstream bugs in a bug tracker may not be a good way to do so.
Honestly, I think a good dedicated triage team that works to verify and move upstream as appropriate works better. But, you know, requires getting and keeping such a team.
we are missing a tool that would clone the Fedora bugs from bugzilla to upstream bug trackers. I think the removal of the manual work needed to copy all the information from bugzilla to upstream tracker would be appreciated by the packagers. I have the idea for the tool for quite some time, but didn't find the time to realize it :-(
Dan
On 09/24/2013 06:45 AM, Dan Horák wrote:
we are missing a tool that would clone the Fedora bugs from bugzilla to upstream bug trackers. I think the removal of the manual work needed to copy all the information from bugzilla to upstream tracker would be appreciated by the packagers. I have the idea for the tool for quite some time, but didn't find the time to realize it
I requested that myself a while back but that died with RH bugzilla team ( just so we could at least have bidirectional communication between 2 bugzilla instances )
JBG
On Tue, Sep 24, 2013 at 09:53:46AM +0000, "Jóhann B. Guðmundsson" wrote:
On 09/24/2013 06:45 AM, Dan Horák wrote:
we are missing a tool that would clone the Fedora bugs from bugzilla to upstream bug trackers. I think the removal of the manual work needed to copy all the information from bugzilla to upstream tracker would be appreciated by the packagers. I have the idea for the tool for quite some time, but didn't find the time to realize it
I requested that myself a while back but that died with RH bugzilla team ( just so we could at least have bidirectional communication between 2 bugzilla instances )
The problem is doing it right, so it only propagates useful information, without too much bloat. When I e.g. see what kind of bloat push Debian bugtrackers into upstream bugzillas, the useful information there is hidden in tons of email headers for every comment, tons of previous comments duplicated (many times; reply to with stuff not being trimmed to a minimum, reply to reply to reply to reply), etc. So perhaps better is just to add to the upstream bz a link to the downstream bugzilla, with optional comment or something, not duplicating everything from the downstream bugzilla.
Jakub
On Sep 24, 2013, at 4:07 AM, Jakub Jelinek jakub@redhat.com wrote:
On Tue, Sep 24, 2013 at 09:53:46AM +0000, "Jóhann B. Guðmundsson" wrote:
On 09/24/2013 06:45 AM, Dan Horák wrote:
we are missing a tool that would clone the Fedora bugs from bugzilla to upstream bug trackers. I think the removal of the manual work needed to copy all the information from bugzilla to upstream tracker would be appreciated by the packagers. I have the idea for the tool for quite some time, but didn't find the time to realize it
I requested that myself a while back but that died with RH bugzilla team ( just so we could at least have bidirectional communication between 2 bugzilla instances )
The problem is doing it right, so it only propagates useful information, without too much bloat. When I e.g. see what kind of bloat push Debian bugtrackers into upstream bugzillas, the useful information there is hidden in tons of email headers for every comment,
Right. It's no good to automate hassling or cluttering upstream bug reports.
So perhaps better is just to add to the upstream bz a link to the downstream bugzilla, with optional comment or something, not duplicating everything from the downstream bugzilla.
That's what I was thinking. RHBZ creates upstream bug, both bugs get crosslinked URLs, the upstream bug gets summary, package-version info, and the Description (the thing before the first comment), and that's it. If upstream wants to comment in the downstream bug, they do it manually, and vice versa.
Best would also be a checkbox "Report Upstream" that can have a package specific default, so upstreams can opine on whether they want the box checked by default or not. e.g. maybe kernel devs would say no, because they seem to be rather vigilant looking at both redhat.com and kernel.org bz's. On the other hand, linking might eliminate some amount of duplicate entries.
In any case, some description pushed upstream is needed for searches to avoid duplicate entries. And on the other hand, the two entires shouldn't mirror each other's added comments. That'd get ugly quickly.
Chris Murphy
On Sep 24, 2013, at 12:45 AM, Dan Horák dan@danny.cz wrote:
we are missing a tool that would clone the Fedora bugs from bugzilla to upstream bug trackers.
I agree. Auto populating upstream bug reporting with some percentage of spurious bugs that are not their bugs still puts the bug in front of more eyes.
Chris Murphy
On Mon, 2013-09-23 at 19:07 -0400, Bill Nottingham wrote:
Additional concerns I'd have above this:
- Not all things we ship have active upstream bug trackers to fall back on
- We still need a way to track Fedora-specific integration & packaging concerns, which would likely get closed upstream as 'NOTABUG' for that project
- What filing downstream gives the Fedora maintainer is a good mechanism for knowing what's going on in that package in Fedora. Tracking *all* upstream bugs in a bug tracker may not be a good way to do so.
I don't think all packages are the same when it comes to bug reporting. Speaking just for GNOME, I will say that getting feedback (in the form of bugs and crash reports) from rawhide and the 'next' branch during the development cycle is pretty valuable, and removing overhead (in the form of extra bugzilla jumps) from this feedback is very good - six month is too short a time to waste on shuffling bugs and status updates back and forth...
Upstream bugzilla has advantages for us as developers - we can use git-bz to attach patches, and splinter to review them, which is very convenient.
The main advantage of downstream bug reporting at this point is retrace.fedoraproject.org, as far as I'm concerned.
Matthias
Matthias Clasen (mclasen@redhat.com) said:
I don't think all packages are the same when it comes to bug reporting. Speaking just for GNOME, I will say that getting feedback (in the form of bugs and crash reports) from rawhide and the 'next' branch during the development cycle is pretty valuable, and removing overhead (in the form of extra bugzilla jumps) from this feedback is very good - six month is too short a time to waste on shuffling bugs and status updates back and forth...
Upstream bugzilla has advantages for us as developers - we can use git-bz to attach patches, and splinter to review them, which is very convenient.
The main advantage of downstream bug reporting at this point is retrace.fedoraproject.org, as far as I'm concerned.
As an upstream developer, that may be fine. I think a lot of the issue is people who wear both the upstream and the downstream hats, and maybe that's better solved by getting more people to wear the downstream hats. Unless people think bugzilla is merely there to service our developers, but that does a large disservice to our users.
Bill
On 09/23/2013 10:59 PM, Jan Wildeboer wrote:
How will you track blocker bugs?
Given that we are the ones filling them that's should not be an hard issue to overcome.
How can we see a global view of all open bugs? Aggregate from X upstream bug report systems? Which not all are Bugzilla?
How can we track critical bugs?
I'm having a hard time following this line of questioning since our view is already limited to only what we have reported here in Fedora as in we dont have the full view of upstream filed bugs ( with all the downside not doing so.
JBG
This is as bad of an idea now as it has been every previous time it has been suggested.
1) Many of the bugs which get filed against Fedora are just that, Fedora bugs, not bugs in upstream packages. Missing file in a package? Fedora bug. Package linked against the wrong version? Fedora bug. Bug about upgrading to a new version of an upstream package? Fedora bug. Bug in the Fedora installer? Fedora bug.
I can't imagine where you expect these bugs to go if Fedora "move[s] entirely away from Red Hat bugzilla as well as away from [the] concept of hosting our own." If that were to occur, then the bugs in Fedora-specific packages such as the installer would have, literally, nowhere else to go. And I assure you that upstream package maintainers will not want Fedora-specific bugs in their bug databases.
2) Most Fedora users are not developers. If they have to jump through hoops to figure out where to report bugs, then they won't report the bugs. The "one-stop shop" that Red Hat bugzilla provides as a point of entry for all bugs that users encounter in Fedora is a huge, huge, value-add service. Getting rid of it would do catastrophic damage to Fedora's ability to get feedback about problems from end users who aren't power users and developers. Is Fedora trying to simply write off such users as irrelevant?
3) I am not sure what you mean when you make the generalized statement that the current system of package maintainers triaging bugs, soliciting additional information from users as needed, and reporting upstream as needed, "is not working." I admit that there are some package maintainers who don't do a good enough job of this, but there are also many package maintainers who do it extremely well; in fact, I'd say that the majority of bugs I file are dealt with appropriately by their maintainers. If some package maintainers aren't doing their jobs, then the solution is to teach them how to do their jobs better and replace the ones who can't, not to throw the baby out with the bathwater by getting rid of the entire bug-tracking system because some of the people participating in it are not doing as good a job as they should.
4) As others have pointed out, there is a huge amount of value in being able to track how Fedora is doing at handling the bugs /that are reported by Fedora users./ While it's true that the Fedora bug database doesn't have every bug in every upstream package in it, there will /never/ be /any/ bug-tracking system which has that global view, so that's a red herring. What the Fedora bug database tells us is what bugs are being encountered and reported specifically by Fedora users, which is the best possible metric of the quality of the Fedora release. The fact that upstream bugs that Fedora users don't encounter don't end up in the Fedora database is a good thing and an argument in favor of keeping the Fedora database, not a bad thing.
Mint has a bug database. Ubuntu has a bug database. Mageia has a bug database. Debian has a bug database. Those are the top four Linux distributions currently in use http://www.zdnet.com/the-most-popular-end-user-linux-distributions-are-7000017223/. Fedora is number five. By all means, if you want Fedora to go even lower in the rankings, buck the trend the top four all seem comfortable with and get rid of the bug database.
jik
On Mon, Sep 23, 2013 at 8:44 PM, Jonathan Kamens jik@kamens.us wrote:
Most Fedora users are not developers. If they have to jump through hoops to figure out where to report bugs, then they won't report the bugs. The "one-stop shop" that Red Hat bugzilla provides as a point of entry for all bugs that users encounter in Fedora is a huge, huge, value-add service
+1
Yes, please end this nonsensical discussion.
FC
На 24.09.2013 02:44, Jonathan Kamens написа:
- Most Fedora users are not developers. If they have to jump through hoops to
figure out where to report bugs, then they won't report the bugs. The "one-stop shop" that Red Hat bugzilla provides as a point of entry for all bugs that users encounter in Fedora is a huge, huge, value-add service. Getting rid of it would do catastrophic damage to Fedora's ability to get feedback about problems from end users who aren't power users and developers. Is Fedora trying to simply write off such users as irrelevant?
+1
I myself am an experienced QA and sometimes fail to file a bug against the correct component, let alone a user who just wants to report a problem so it is fixed the next time. How will users know where the upstream tracker is ? This is just too much to ask from them.
-- Alex
On 09/23/2013 05:49 PM, "Jóhann B. Guðmundsson" wrote:
Greetings you all
After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own.
Now it pretty much boils down to this.
- Generic attitude of many maintainers is that reports either go to the
correct place ( upstream ) or they get their bugzilla ignored. 2. More often than not downstream maintainer as in packager does not know the code at all so filling the bug downstream makes no sense since it brings just unnecessary latency to the process. 3. Hosting our own bugzilla cost resources and does not solve 1. or 2.
I personally for many years have argued against this since to an reporter it might mean having thousand of accounts but given that we are going through new fase and the times are changing in the linux eco system I would like to get your opinion about we stop reporting altogether in Red Hat bugzilla and report only directly upstream as in kernel bugs to the kernel community, Gnome bugs to theirs, KDE to their etc.
The obvious benefit of doing this is that our bugs might actually get look at,dealt with as well as all that being done in a shorter time frame.
Thoughts and comment.
JBG
I have found Redhat bz more responsive, comparatively speaking, than upstream bzs. And, I certainly do not want the logistics involved in knowing numerous upstream bzs. Reporting to one place has worked for years even tho it is not perfect. Maybe implement a little technology that automatically forwards a bz as appropriate based on the package being reported on.
Please don't change the current method.
What to do when someone discovers what is clearly a problem but neither he nor anyone reading his report here or on devel list can tell whether the bug is in kernel, driver, xorg, gnome/kde/xfce/etc. or something else?
On 09/23/2013 11:55 PM, Felix Miata wrote:
What to do when someone discovers what is clearly a problem but neither he nor anyone reading his report here or on devel list can tell whether the bug is in kernel, driver, xorg, gnome/kde/xfce/etc. or something else?
Well I'm pretty sure upstream is better suited to judge if their component is at fault then the package maintainer in Fedora or devel.
JBG
On 09/23/2013 07:58 PM, "Jóhann B. Guðmundsson" wrote:
On 09/23/2013 11:55 PM, Felix Miata wrote:
What to do when someone discovers what is clearly a problem but neither he nor anyone reading his report here or on devel list can tell whether the bug is in kernel, driver, xorg, gnome/kde/xfce/etc. or something else?
Well I'm pretty sure upstream is better suited to judge if their component is at fault then the package maintainer in Fedora or devel.
I am not at all sure about that.
Many, many bugs involve unexpected interactions between different components. If you think upstream maintainers want to play whack-a-mole trying to figure out why their package in Fedora is encountering an issue that they're not encountering (remember, Fedora is the fifth most popular distribution; MOST DEVELOPERS AREN'T USING IT) and users on other distributions are not encountering, you're wrong. If you think upstream maintainers want to have to maintain installations of every distribution that ships their software, just so they can troubleshoot distribution-specific bugs, you're wrong.
Furthermore, let's discuss how things will actually work under the system you're proposing:
*User to upstream bugzilla A: *"I'm encountering bug frobnitz."
*Maintainer A: *"That bug is not being caused by my package. Go away."
*User:* "Then what package is causing it?"
*Maintainer:* "I don't know. Go away."
or maybe...
*Maintainer:* "Try bugilla B."
*User to upstream bugzilla B*: "I'm encountering bug frobnitz."
*Maintainer B:* "That bug is not being caused by my package. Go away."
*User:* "Then what package is causing it?"
*Maintainer: *"I don't know. Go away."
or maybe...
*Maintainer:* "Try bugzilla A."
or maybe...
*Maintainer:* "Try bugzilla C."
Etc.
On 09/23/2013 04:58 PM, "Jóhann B. Guðmundsson" wrote:
On 09/23/2013 11:55 PM, Felix Miata wrote:
What to do when someone discovers what is clearly a problem but neither he nor anyone reading his report here or on devel list can tell whether the bug is in kernel, driver, xorg, gnome/kde/xfce/etc. or something else?
Well I'm pretty sure upstream is better suited to judge if their component is at fault then the package maintainer in Fedora or devel.
JBG
As a user, it's much more difficult to file a bug upstream: Each upstream bugzilla: Almost always requires creating an account Different projects use different bug-tracking interfaces Of course, that assumes that the user can find the upstream project and their bug-tracking system (if any).
The Fedora bugzilla, even if occasionally non-responsive, is *very* convenient. One can at least see if other users are experiencing the same issue. And other Fedora users cat at least leave bug comments that might aid other users (even if the comment points upstream).
Although far from ideal, I'd put rate Fedora's bugzilla at several notches above worthwhile.
Cheers, -Bob Arendt
On Mon, 2013-09-23 at 18:17 -0700, Bob Arendt wrote:
The Fedora bugzilla, even if occasionally non-responsive, is *very* convenient. One can at least see if other users are experiencing the same issue. And other Fedora users cat at least leave bug comments that might aid other users (even if the comment points upstream).
This is my experience as well. I no longer expect bugs to actually get closed but BZ is useful as a resource to read. The fix might even show up in a future package, even if the BZ# stays active or simply ages out. None of that changes the usefulness of searching through it.
And after reading through this whole discussion there is really only one conclusion. Fedora is dysfunctional. Debugging is harder than writing and the developers have made Fedora as large and as complex as they can make it, meaning they can't possibly debug it anymore. Debating the details of infrastructure, who to report to, none of that is going to matter until the elephant in the room is dealt with.
A little more care needs to go into deciding what is Fedora, if it can't be maintained it shouldn't be included. The ongoing talk to split Fedora into a well maintained core and layers above that is probably the right general direction.
And while 'first' is a good goal, 'works' should perhaps be elevated to a co-equal status. Because if it doesn't work it isn't going to be 'fun.'
Perhaps a rule that if packages you maintain have X or more bugs any packages pushed need to close a BZ#. And of the total bug count exceeds a limit nobody can upload a new package that isn't fixing a bug. Making new shiny is always more fun than maintaining, given a choice most people will go for fun and leave the fixing for 'later.'
On Mon, Sep 23, 2013 at 09:49:23PM +0000, "Jóhann B. Guðmundsson" wrote:
After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own.
...
Thoughts and comment.
This absolutely does not scale from a POV of a user reporting bugs. It may be convenient for packagers but in your wildest dreams you cannot expect that in order to file a bug I will first research for every package if that even has some for of a bug tracker, and if it happens to exist will dig out all its idiosyncrasies, aquire required logins and credentials and will try to track what happened with various bug reports only to learn that upstream does not care about "distro specific" problems and/or not the latest available version. A packager with a limited number of an upstream contacts may kick out a report up if so desired.
If I will be forced to do things above I will simply stop to bother.
Michal
On 09/24/2013 01:45 AM, Michal Jaegermann wrote:
This absolutely does not scale from a POV of a user reporting bugs.
Well neither does it do so from developer standpoint that also has to maintain downstream distribution bugzilla accounts.
Basically the amount of work and the effort are on par for both parties as in reporter has to file multiple reports against multiple package and the developer has to deal with multiple reports against multiple distribution in multiple downstreams etc. so arguing one has to do more work then the other is a mute point at least as far as I see it.
in any case continue since we need to gather as much feedback as well as data points ( like how many bugs are being closed as EOL ) before throwing this to community voting and once the results from that are clear we can focus on improving our procedures in either direction.
JBG
On 09/23/2013 10:03 PM, "Jóhann B. Guðmundsson" wrote:
On 09/24/2013 01:45 AM, Michal Jaegermann wrote:
This absolutely does not scale from a POV of a user reporting bugs.
Well neither does it do so from developer standpoint that also has to maintain downstream distribution bugzilla accounts.
Basically the amount of work and the effort are on par for both parties as in reporter has to file multiple reports against multiple package and the developer has to deal with multiple reports against multiple distribution in multiple downstreams etc. so arguing one has to do more work then the other is a mute point at least as far as I see it.
It's really not the same at all. Not nearly.
First of all, the developers are experienced power users for whom maintaining bugzilla accounts, if they really need to do that, is not nearly as big a deal as it is for end users who are neither developers nor power users.
Second, upstream developers can participate in the distribution bug databases if they feel like it, but it's hardly required. When a distribution package maintainer reports a bug upstream, the developer only has to deal with the bug in his own bug database. Whereas if Fedora bugzilla goes away, every end user /must/ deal with multiple bug databases to report package bugs to the right place.
Third, there are, I hope, several more orders of magnitude of users than there are upstream developers, and there are at least two orders of magnitude more developers than their are distributions. Therefore, in terms of the total amount of work done, all the developers creating accounts on all the distributions' bug databases, even if they do feel compelled to do that, is far, far less work overall than all the users who report bugs having to figure out how to report bugs for hundreds of different packages and create accounts on many different bug sites.
jik
On 09/24/2013 03:10 AM, Jonathan Kamens wrote:
On 09/23/2013 10:03 PM, "Jóhann B. Guðmundsson" wrote:
On 09/24/2013 01:45 AM, Michal Jaegermann wrote:
This absolutely does not scale from a POV of a user reporting bugs.
Well neither does it do so from developer standpoint that also has to maintain downstream distribution bugzilla accounts.
Basically the amount of work and the effort are on par for both parties as in reporter has to file multiple reports against multiple package and the developer has to deal with multiple reports against multiple distribution in multiple downstreams etc. so arguing one has to do more work then the other is a mute point at least as far as I see it.
It's really not the same at all. Not nearly.
Given that this would the direction we take for the next 10 years for the QA community and based on you responce I have to ask how do you see the "traditional" desktop being relevant after all that time and if so used by whom as in which target users ( novice end users/power users/administrators )?
Here in Iceland ( and I know that have started doing the same in Denmark which means they are doing in other places in the world ) they are deploying tablets in schools not pc, which means the next generation of tinkeres will be doing so on tablet or the evolution of tablets at that time.
They are handing out tablets with news paper subscriptions so slowly the tablet is replacing the traditional pc as well as laptops for the novice end users as well ( and pc are already starting to collect dust here ), light portable with mobile network connectivity and is at the same time running the same underlying OS as your mobile phone so no extra learning curve for the end user to study new OS.
So from my point of view we wont be gathering reports from novices end users in 10 years time.
JBG
On 09/24/2013 05:46 AM, "Jóhann B. Guðmundsson" wrote:
Given that this would the direction we take for the next 10 years for the QA community
On what basis do you assert that if we were to decide today to continue to use RHBZ to track Fedora bugs, we would be locked into that decision "for the next 10 years"? I see no grounds for such an assertion.
Also, "the QA community" is hardly the only stakeholder who should have a voice in this discussion. In fact, there are four stakeholders: QA, packagers, upstream, and users. What efforts are being made to solicit useful feedback from all four groups?
and based on you responce I have to ask how do you see the "traditional" desktop being relevant after all that time and if so used by whom as in which target users ( novice end users/power users/administrators )?
[... amusing theorizing about how the growth of the tablet market means that in 10 years novice users won't be using Fedora anymore...]
So from my point of view we wont be gathering reports from novices end users in 10 years time.
* Many of the benefits to RHBZ that I and others have pointed out accrue whether the user base contains "novice" end users or not.
* I can play the prognostication game as well as you can, and no, I do not think that the rise of the tablet means that in ten years there won't be any "novice" users on desktop computers. I can type 102 words per minute on a keyboard, and I can work a lot more productively on my two 25" monitors than on an iPad screen. There are uses for which a tablet is great, and uses for which a desktop computer will still be better a hundred years from now.
* I expect that as smart-phones and tablets become more ubiquitous, Fedora and other desktop OSes will evolve and focus on the things for which desktops are best, while tablets will continue to focus on the things for which tablets are best.
jik
On 09/24/2013 12:19 PM, Jonathan Kamens wrote:
. In fact, there are four stakeholders: QA, packagers, upstream, and users. What efforts are being made to solicit useful feedback from all four groups?
?
There are 2 stake holders in this
1 QA Community ( which includes reporters ) 2 the developers ( which includes packagers as well )
JBG
On Tue, 24 Sep 2013 12:28:18 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 09/24/2013 12:19 PM, Jonathan Kamens wrote:
. In fact, there are four stakeholders: QA, packagers, upstream, and users. What efforts are being made to solicit useful feedback from all four groups?
?
There are 2 stake holders in this
1 QA Community ( which includes reporters ) 2 the developers ( which includes packagers as well )
JBG
+ Infra, which will have to run, if possible any scheme. Haven't they said no?
On 09/24/2013 12:30 PM, Frank Murphy wrote:
On Tue, 24 Sep 2013 12:28:18 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 09/24/2013 12:19 PM, Jonathan Kamens wrote:
. In fact, there are four stakeholders: QA, packagers, upstream, and users. What efforts are being made to solicit useful feedback from all four groups?
?
There are 2 stake holders in this
1 QA Community ( which includes reporters ) 2 the developers ( which includes packagers as well )
JBG
- Infra, which will have to run, if possible any scheme.
Haven't they said no?
Infra is not maintaining any bugzilla instances RH is and infra has refused to put up project's own instance so I'm not sure what you are getting at.
JBG
On Tue, 24 Sep 2013 12:36:08 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
Infra is not maintaining any bugzilla instances RH is and infra has refused to put up project's own instance so I'm not sure what you are getting at.
JBG
So, basically you want users to go find the bugzilla, I can see how the will help keep the distro running, unless you just want QA, and Packagers only using it.
For one, I won't be signing up to every site to track bugs, if bz is broke, help fix it!
Not create a whole new batch of problems.
On 09/24/2013 12:41 PM, Frank Murphy wrote:
So, basically you want users to go find the bugzilla, I can see how the will help keep the distro running, unless you just want QA, and Packagers only using it.
For one, I won't be signing up to every site to track bugs, if bz is broke, help fix it!
Not create a whole new batch of problems.
I'm not sure what that response is supposed to be adding to the discussion since it's a well known fact the discomfort it brings to reporters to have them go upstream to report.
On Tue, 24 Sep 2013 12:44:02 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
I'm not sure what that response is supposed to be adding to the discussion since it's a well known fact the discomfort it brings to reporters to have them go upstream to report.
I've added it because have stated "bugs" go unanswered. That is the "problem" need fixing, not bugzilla.
Is missing maintainer period too long? Extra co-maintainers needed, with commit access?
Now can you throw as much endeavour into helping resolve that
On 09/24/2013 12:50 PM, Frank Murphy wrote:
On Tue, 24 Sep 2013 12:44:02 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
I'm not sure what that response is supposed to be adding to the discussion since it's a well known fact the discomfort it brings to reporters to have them go upstream to report.
I've added it because have stated "bugs" go unanswered. That is the "problem" need fixing, not bugzilla.
There are 4 reasons that happens.
1. the packager is gone awol 2. the packager does not know how to fix 3. the maintainer lacks time to fix it. 4. bugzilla is not the interface the maintainer finds effective so he ignores it
Is missing maintainer period too long? Extra co-maintainers needed, with commit access?
Now can you throw as much endeavour into helping resolve that
To effectively resolve that you need to reduce the total number of components in the distribution as well as how many components maintainer is allowed to maintain as well as finding the communication interface with the maintainer which he finds effective.
Reporting upstream is one solution to the interface problem, detecting poorly maintained packages as well as orphaning unmaintained packages and coming up with a time sharing program takes care of the rest.
With the exception of reporting directly upstream which I have been always against, I pointed out the other things and you can find the discussion surrounding that in the archives on devel.
JBG
On Tue, 24 Sep 2013 13:04:18 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
I've added it because have stated "bugs" go unanswered. That is the "problem" need fixing, not bugzilla.
There are 4 reasons that happens.
- the packager is gone awol
1a: Not a buzilla problem, housekeeping
- the packager does not know how to fix
2a: If it a bug, that is know upstream link it, if it's fedora packing\config issue, help him understand
- the maintainer lacks time to fix it.
3a: Then should he be maintainer, if he cannot maintain?
- bugzilla is not the interface the maintainer finds effective so
he ignores it
It it part of fedora, help him learn it's ways
Is missing maintainer period too long? Extra co-maintainers needed, with commit access?
Now can you throw as much endeavour into helping resolve that
To effectively resolve that you need to reduce the total number of components in the distribution as well as how many components maintainer is allowed to maintain as well as finding the communication interface with the maintainer which he finds effective.
Agreed, or get maintainers in, and help them understand Fedora ways. But, I agree if John Does, want to bring in package foo, as his admittance price. Then he best know it's every inch.
Reporting upstream is one solution to the interface problem,
What if they too have bugzilla, bummer. The problem with many upstream is the dreaded "Works for me"
detecting poorly maintained packages as well as orphaning unmaintained packages and coming up with a time sharing program takes care of the rest.
(1a) ^
With the exception of reporting directly upstream which I have been always against, I pointed out the other things and you can find the discussion surrounding that in the archives on devel.
I'm not against reporting upstream, for a specific issue, where maintainer has said, can you please report upstream, as problem is agnostic.
Gnome is a special case, as upstream <> downstream can be overlapped, and the gnome-sig know their pkgs.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/24/2013 02:44 PM, "Jóhann B. Guðmundsson" wrote:
I'm not sure what that response is supposed to be adding to the discussion since it's a well known fact the discomfort it brings to reporters to have them go upstream to report.
On a more fundamental note:
Fedora isn't just upstream-slapped-with-a-specfile. As a distribution the resposibility is more complex:
- - Distribution-specific problems that come from the selection of versions and dependencies.
- - Distribution-specific problems coming from "own" projects like installer, update management etc.
Combined with the different set of expectations from users versus maintainers versus developers.
There will always be a need to track fedora-specific issues (note that I say issues, not bugs!). And once you accept the need for that, the rest follows.
Your proposal effectively ignores the distribution speficic part.
I (and quite some others, I guess) have a different view. From distribution to upstream to distribution. You cannot ignore the distribution part. You cannot ignore the difference between issues and bugs. You cannot wipe all that away without causing severe problems.
Sending users to upstream doesn't work. It will upset upstream and force users to jump through even more hoops. Maintaininhg a working relationship with upstream is a very responsible task that should not be decentralized. That's my take to sum it all up. Don't go there :-)
Jan
- -- Jan H Wildeboer | EMEA Open Source Affairs | Office: +49 (0)89 205071-207 Red Hat GmbH | Mobile: +49 (0)174 33 23 249 Technopark II, Haus C | Fax: +49 (0)89 205071-111 Werner-von-Siemens-Ring 11 -15 | 85630 Grasbrunn | _____________________________________________________________________
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 11 -15 85630 Grasbrunn, Handelsregister: Amtsgericht Muenchen HRB 153243 Geschaeftsfuehrer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera _____________________________________________________________________
GPG KeyID: 59E022AA GPG Fingerprint: 1222 D871 BC4D AF82 D55C 46E7 4D83 56FE 59E0 22AA
On 09/24/2013 09:05 AM, jwildebo@redhat.com wrote:
Fedora isn't just upstream-slapped-with-a-specfile. As a distribution the resposibility is more complex:
Yes, I already made that point yesterday; see https://lists.fedoraproject.org/pipermail/test/2013-September/117874.html. Jóhann has responded to many others messages in this conversation but has ignored that one. I can only assume that he has not responded because he has no good answer.
jik
On 09/24/2013 08:28 AM, "Jóhann B. Guðmundsson" wrote:
On 09/24/2013 12:19 PM, Jonathan Kamens wrote:
. In fact, there are four stakeholders: QA, packagers, upstream, and users. What efforts are being made to solicit useful feedback from all four groups?
There are 2 stake holders in this
1 QA Community ( which includes reporters ) 2 the developers ( which includes packagers as well )
I am trying to keep this discussion on the issues and not on the people, but I really have to say this... The fact that you apparently don't understand that "QA community" and "reporters" are two distinct (but overlapping) sets with very different needs and use cases, and ditto for "developers" and "packagers", is a stark illustration of how little you understand the RHBZ ecosphere and how unqualified you are to be making recommendations for how to improve it.
jik
On Tue, Sep 24, 2013 at 09:46:51AM +0000, "Jóhann B. Guðmundsson" wrote:
So from my point of view we wont be gathering reports from novices end users in 10 years time.
This is a plain self-fulfilling prophecy. If you will manage to kill report gathering means then indeed you will have no reports; from novice users in particular.
While bugzilla is far from perfect and it can be frustrating at times a "solution" you are pushing does not even start to pass a laugh test.
Michal
On 09/24/2013 03:48 PM, Michal Jaegermann wrote:
On Tue, Sep 24, 2013 at 09:46:51AM +0000, "Jóhann B. Guðmundsson" wrote:
So from my point of view we wont be gathering reports from novices end users in 10 years time.
This is a plain self-fulfilling prophecy. If you will manage to kill report gathering means then indeed you will have no reports; from novice users in particular.
While bugzilla is far from perfect and it can be frustrating at times a "solution" you are pushing does not even start to pass a laugh test.
Really...
Let's run a simple query against bugzilla for bugs in the status NEW ( as in not looked at ) and find out the oldest report from our reporters for the soon to be EOL released F18 which should have the longest time maintainers could have responded bugs filed by reporters.
The oldest bug was filed by Stef Walter mailto:stefw@redhat.comon 2012-08-15 against binutils with total of 7205 bugs found. ( You can multiple that number by half an hour at least of reporters time )
Now let's look at the gory details of EOL bugs closed wontfix running [2]
8031 bugs found.
Do you honestly think this is a) healthy b) constructive for new reporters ( which usually leave after waiting up to 13 months having their bug fixed or in the case of the above over a year for somekind of feedback from the maintainer )
I would think the highest priority from a QA perspective is to both report and actually get the highest chances of having the bugs fixed as well as receiving some kind of feed back from the maintainer while reporters are at it.
JBG
1. https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&classification=Fe...
2. https://bugzilla.redhat.com/buglist.cgi?bug_status=CLOSED&classification...
ps.
Here's an exercise for the reader find out how many got fixed in F17 ( for the shocking truth )
On 09/24/2013 06:42 PM, Michael Schwendt wrote:
On Tue, 24 Sep 2013 18:35:46 +0000, Jóhann B. Guðmundsson wrote:
Really...
Let's run a simple query against bugzilla for bugs in the status NEW ( as in not looked at )
NEW doesn't imply "not looked at". And it doesn't imply "no response" either.
Feel free to shift through those bugs and filter out those that have comment as well as no comment from maintainer ( as in only reporter have commented )
On Tue, 24 Sep 2013, "Jóhann B. Guðmundsson" wrote:
Really...
Let's run a simple query against bugzilla for bugs in the status NEW ( as in not looked at ) and find out the oldest report from our reporters ...
What does a count of the number of bug reports have to do with the bug tracker used?
If there are too many packages in Fedora, cut them back
If there are too few people fixing bugs, figure out if the project design is attractive to potential maintainers
If the release cadence is too fast, slow it down
If a moratorium of changes on favor of bug fixes is needed, call for it
... but NONE of this has more than a passing relation to the (subject line) proposal to change bug trackers used
This thread needs to be refactored (or just die). People are arguing just to hear themselves talk. If it is just about 'winning' or being vindicated, there is no purpose for it here
-- Russ herrold
As Michael Schwendt has pointed out, NEW implies neither that the bug hasn't been looked at nor that there has been no activity on it.
Russ Herrold is also correct: if bugs are not being looked at, then that's not the fault of the bug-tracking system, it's the fault of the people who are supposed to be looking at the bugs.
Drawing conclusions from a single package is rigging the game, since what we're discussing is that some packages are maintained better than others.
Looking at F18 is rigging the game, because a package maintainer may have (reasonably) stopped looking at F18 bugs when F19 came out if s/he knows that F19 has a new version which fixes significant bugs.
Having said all that, let's assume, for the sake of argument, that NEW bugs haven't been looked at or responded to, and try to answer the question of what percentage of Fedora bugs aren't being looked at or responded to in a reasonable amount of time. My methodology is to look at the total of all Fedora bugs filed between one and two months ago (to limit the scope of the problem -- otherwise you're just dealing with too many bugs) and then to look at how many bugs within that same time period are in state NEW.
There are 2,129 NEW Fedora bugs and 5,199 total Fedora bugs filed between 2013-07-24 and 2013-08-24. That's only 40% of the total number of bugs, which disproves assertion that the majority of bugs aren't being dealt with. If we go back a month earlier, from 2013-06-24 to 2013-07-24, there are 1,715 NEW bugs out of 3,932 total bugs, i.e., 43%. Still not the majority. A month earlier than that, 1,407 out of 3,804 = 36%. Still not the majority.
I entirely agree with you that it would be better if those percentages were lower. But driving those numbers is not the end goal. The end goal is to improve the quality of Fedora as much as we can with the resources we have, and I (and many others, clearly) don't believe that no longer tracking Fedora bugs in RHBZ will accomplish that.
jik
On 09/24/2013 02:35 PM, "Jóhann B. Guðmundsson" wrote:
On 09/24/2013 03:48 PM, Michal Jaegermann wrote:
On Tue, Sep 24, 2013 at 09:46:51AM +0000, "Jóhann B. Guðmundsson" wrote:
So from my point of view we wont be gathering reports from novices end users in 10 years time.
This is a plain self-fulfilling prophecy. If you will manage to kill report gathering means then indeed you will have no reports; from novice users in particular.
While bugzilla is far from perfect and it can be frustrating at times a "solution" you are pushing does not even start to pass a laugh test.
Really...
Let's run a simple query against bugzilla for bugs in the status NEW ( as in not looked at ) and find out the oldest report from our reporters for the soon to be EOL released F18 which should have the longest time maintainers could have responded bugs filed by reporters.
The oldest bug was filed by Stef Walter mailto:stefw@redhat.comon 2012-08-15 against binutils with total of 7205 bugs found. ( You can multiple that number by half an hour at least of reporters time )
Now let's look at the gory details of EOL bugs closed wontfix running [2]
8031 bugs found.
Do you honestly think this is a) healthy b) constructive for new reporters ( which usually leave after waiting up to 13 months having their bug fixed or in the case of the above over a year for somekind of feedback from the maintainer )
I would think the highest priority from a QA perspective is to both report and actually get the highest chances of having the bugs fixed as well as receiving some kind of feed back from the maintainer while reporters are at it.
JBG
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&classification=Fe...
https://bugzilla.redhat.com/buglist.cgi?bug_status=CLOSED&classification...
ps.
Here's an exercise for the reader find out how many got fixed in F17 ( for the shocking truth )
On 09/24/2013 07:17 PM, Jonathan Kamens wrote:
As Michael Schwendt has pointed out, NEW implies neither that the bug hasn't been looked at nor that there has been no activity on it.
Russ Herrold is also correct: if bugs are not being looked at, then that's not the fault of the bug-tracking system, it's the fault of the people who are supposed to be looking at the bugs.
Drawing conclusions from a single package is rigging the game, since what we're discussing is that some packages are maintained better than others.
Looking at F18 is rigging the game, because a package maintainer may have (reasonably) stopped looking at F18 bugs when F19 came out if s/he knows that F19 has a new version which fixes significant bugs.
Having said all that, let's assume, for the sake of argument, that NEW bugs haven't been looked at or responded to, and try to answer the question of what percentage of Fedora bugs aren't being looked at or responded to in a reasonable amount of time. My methodology is to look at the total of all Fedora bugs filed between one and two months ago (to limit the scope of the problem -- otherwise you're just dealing with too many bugs) and then to look at how many bugs within that same time period are in state NEW.
There are 2,129 NEW Fedora bugs and 5,199 total Fedora bugs filed between 2013-07-24 and 2013-08-24. That's only 40% of the total number of bugs, which disproves assertion that the majority of bugs aren't being dealt with. If we go back a month earlier, from 2013-06-24 to 2013-07-24, there are 1,715 NEW bugs out of 3,932 total bugs, i.e., 43%. Still not the majority. A month earlier than that, 1,407 out of 3,804 = 36%. Still not the majority.
I entirely agree with you that it would be better if those percentages were lower. But driving those numbers is not the end goal. The end goal is to improve the quality of Fedora as much as we can with the resources we have, and I (and many others, clearly) don't believe that no longer tracking Fedora bugs in RHBZ will accomplish that.
Working directly with upstream might improve it ( we ofcourse dont know until we actually try that ) since it will cut out the middle man ( the packager ) or give the upstream maintainer ( if he's the middle man ) more time to work on the bug discuss and pass it's patch through upstream ( which needs to be done in most cases anyway ).
JBG
Jóhann,
I do not think you are participating in this discussion with your mind open to the possibility that you may be wrong.
People have offered many reasons why they think what you are proposing is a bad idea. You have failed to acknowledge the possibility that any of those arguments might be valid; in fact, you have completely ignored many of them. In contrast, you may have noticed that the people who disagree with your proposal have still acknowledged that some of what you have said is true. It's a sure sign that someone is not listening with an open mind when they ignore anything in the discussion that weakens their thesis.
Furthermore, numerous things you've asserted here have been proved objectively false, and you've failed to acknowledge a single one of those, choosing instead to change the subject each time. Changing the subject rather than admitting error is another sure sign of an idealogue.
I am no longer active enough in this community to know whether you hold some sort of position of authority, whereby you will be the one actually making the decision about whether to stop putting Fedora bugs in RHBZ. If you do, then frankly your conduct throughout this discussion has given me no faith whatsoever that the decision will be made in a rational, objective way. Rather, it feels to me like you've already made up your mind and are just putting on a show of listening to other people's opinions before going ahead and doing what you wanted to do all along.
On 09/24/2013 04:35 PM, "Jóhann B. Guðmundsson" wrote:
On 09/24/2013 07:17 PM, Jonathan Kamens wrote:
I entirely agree with you that it would be better if those percentages were lower. But driving those numbers is not the end goal. The end goal is to improve the quality of Fedora as much as we can with the resources we have, and I (and many others, clearly) don't believe that no longer tracking Fedora bugs in RHBZ will accomplish that.
Working directly with upstream might improve it ( we ofcourse dont know until we actually try that ) since it will cut out the middle man ( the packager )
There is nothing in the current system to stop the person reporting a Fedora bug from choosing to report it upstream instead of, or in addition to, reporting it to Fedora. Indeed, I myself often do that when I believe that a bug I've encountered is not Fedora-specific, and I'm sure many other power users and developers do so as well.
What you seem to be ignoring (see above about your complete failure to acknowledge or respond to arguments to which you have no good answer) is that *people who are willing and able to do the work of reporting bugs upstream are an extremely small minority of the people who actually report Fedora bugs.* Many people here are telling you that if we make end users report bugs upstream, most end users will simply stop reporting bugs. You can't make this fact disappear by pretending it does not exist.
In other words... with the current system, power users can report bugs upstream when appropriate, while normal users can report bugs in one place, to Fedora RHBZ, and in the case of a properly maintained package, the package maintainer(s) will do the right thing with it. In the system you're proposing, power users must ALWAYS report bugs upstream, which means that (a) some of them won't bother and (b) there won't be any place for them to report Fedora-specific bugs, and most normal users, frankly, won't bother to report bugs at all if they have to jump through hoops to do so. *The system you are proposing is **a net loss.*
or give the upstream maintainer ( if he's the middle man ) more time to work on the bug discuss and pass it's patch through upstream ( which needs to be done in most cases anyway ).
I'm really not sure what you mean by this. In particular, I don't understand how and when the "upstream maintainer" of a package is the "middle man", nor why that would "need to be done in most cases."
Frankly, the more you write in this thread, the more convinced I become that you are just saying anything you need to say to avoid having to admit that you're wrong about anything. I make it a rule not to attempt to hold a rational discussion with someone who I don't believe is being rational. Therefore, I'm done with this discussion.
Regards,
jik
Once upon a time, Jonathan Kamens jik@kamens.us said:
Rather, it feels to me like you've already made up your mind and are just putting on a show of listening to other people's opinions before going ahead and doing what you wanted to do all along.
If you have read Jóhann's previous posts, he believes that Fedora should be completely separated from Red Hat. Though he has not mentioned it in this discussion, I believe that is what is driving his desire to stop using RHBZ (even if there is no satisfactory replacement).
On 09/24/2013 09:21 PM, Chris Adams wrote:
Once upon a time, Jonathan Kamens jik@kamens.us said:
Rather, it feels to me like you've already made up your mind and are just putting on a show of listening to other people's opinions before going ahead and doing what you wanted to do all along.
If you have read Jóhann's previous posts, he believes that Fedora should be completely separated from Red Hat. Though he has not mentioned it in this discussion, I believe that is what is driving his desire to stop using RHBZ (even if there is no satisfactory replacement).
I think we should strive to become self sustaining community yes with multiple sponsors as opposed to be highly depended and dictated by a single sponsor be it Red Hat be it something else to serve it's needs and be called guinea pigs for them in the process yes you are right in that regard but that's not the reason for it.
The reason for it is that infra has made it clear that we will not have our own bugzilla instance which we could hack against the things we need to hack against it ( like health monitor for components,badges etc ), have the ability to ping infra as well as using upstream tools to fix,motify and even delete user accounts,customize our own workflows, not being able to lookup bugs because some employee at RH closed the bug as duplicate of internal bugs and various other issues in that regard etc. so we will never be able to build a QA community to server our and developers need which leaves us with the alternative adopting upstream mantra.
JBG
On Tue, 24 Sep 2013 21:34:49 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
...snip...
The reason for it is that infra has made it clear that we will not have our own bugzilla instance
Let me provide a more detailed answer, just exactly like the one I provided on the infrastructure list.
At this current time, and given the resources we have, we are not interested in running our own bugzilla. We are open to any changes in that evaluation. See: https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker Additionally, we want to try and work with bugzilla admins to try and reduce or eliminate problems/pain points we are seeing in the Fedora community.
I may be biased, so the full discussion on the infra list: https://lists.fedoraproject.org/pipermail/infrastructure/2013-September/0134...
which I would summarize as:
- You asked about us running our own bugzilla. - We mentioned we have been thinking about this and pointed to the above wiki page. - We noted at this time that we aren't wanting to do so, but are happy to hear more info that would persuade us. - We asked you about the specific issues you had with bugzilla.redhat.com but I have never seen them. Could you add them to the wiki page? - There was a off topic sidetrack where you indicated that you thought EPEL shouldn't be considered part of Fedora or considered in any bug tracking plans. - You then suggested we switch to github's issue tracker. - A bunch of people indicated issues with this plan. - You then decided we should just stop using bugzilla at all.
which we could hack against the things we need to hack against it ( like health monitor for components,badges etc ), have the ability to ping infra as well as using upstream tools to fix,motify and even delete user accounts,customize our own workflows, not being able to lookup bugs because some employee at RH closed the bug as duplicate of internal bugs and various other issues in that regard etc. so we will never be able to build a QA community to server our and developers need which leaves us with the alternative adopting upstream mantra.
We do modify accounts all the time. (How do you think fedorabugs works?)
Again, if you want to be productive could you detail the exact pain points you have and we can try and alleviate them with RH bugzilla team.
Thanks,
kevin
On Tue, 24 Sep 2013 22:12:48 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
I needed to migrate all of my bugs to another account tied to one of my email address then delete it ( old work account ) and that was not possible
I would think you could simply do a search for the critera (all bugs assigned or cc your old account) and click on 'change serveral bugs at once' and then change the assigned or cc.
I do believe you yourself on numerous occasions as well as other in fedora-admin have claimed powerless and directly me to contact directly bz admins. Are you know telling that has been changed?
What do you mean by 'contact directly' ?
What I am suggesting is that we gather up the issues from the community and see what overlap they have, boil them down to specific cases then file bugs on them. That way we can track whats already been filed and possibly not fixed or scheduled to be fixed or whatever.
The way to 'contact directly' bugzilla folks has always be to file a bug: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&version=4.4
Anyhow, I don't find your proposal(s) compelling, so I will just stop here. Good luck.
kevin
On 09/24/2013 10:07 PM, Kevin Fenzi wrote:
Again, if you want to be productive could you detail the exact pain points you have and we can try and alleviate them with RH bugzilla team.
Unlimited unhindered hacking access to bugzilla for one, an full disclosure of the RH administrative policy in the workings which no one of us in the community has ever known ( with the exception of maybe RH employees ) for example I one time hit a wall when they claimed they could not do that and I asked why the tool was part of upstream bugzilla due to policy when asked which policy things went silent. The other are staff related Jaroslav mentioned he would take care of it with the RH staff in BRNO.
JBG
On 09/24/2013 10:07 PM, Kevin Fenzi wrote:
which I would summarize as:
- You asked about us running our own bugzilla.
- We mentioned we have been thinking about this and pointed to the above wiki page.
- We noted at this time that we aren't wanting to do so, but are happy to hear more info that would persuade us.
- We asked you about the specific issues you had with bugzilla.redhat.com but I have never seen them. Could you add them to the wiki page?
I do believe you yourself on numerous occasions as well as other in fedora-admin have claimed powerless and directly me to contact directly bz admins. Are you know telling that has been changed?
- There was a off topic sidetrack where you indicated that you thought EPEL shouldn't be considered part of Fedora or considered in any bug tracking plans.
No it belongs in RHBZ
- You then suggested we switch to github's issue tracker.
- A bunch of people indicated issues with this plan.
As well as the entire bits that make up the distro.
- You then decided we should just stop using bugzilla at all.
No I did not until I spoke with couple of developers and heard their view on things
Biased indeed and not your usually answer we dont have enough man power to run it even when offered one...
JBG
On 09/24/2013 09:14 PM, Jonathan Kamens wrote:
Jóhann,
I do not think you are participating in this discussion with your mind open to the possibility that you may be wrong.
People have offered many reasons why they think what you are proposing is a bad idea. You have failed to acknowledge the possibility that any of those arguments might be valid; in fact, you have completely ignored many of them. In contrast, you may have noticed that the people who disagree with your proposal have still acknowledged that some of what you have said is true. It's a sure sign that someone is not listening with an open mind when they ignore anything in the discussion that weakens their thesis.
You mean I have not been understanding these points [1] which I myself have been making for many years.
Is it not more likely that it's quite the opposite that you refuse to look at the angle from as an upstream that maintains component in downstream point of view?
JBG
1. https://lists.fedoraproject.org/pipermail/desktop/2011-February/006928.html
On Tue, Sep 24, 2013 at 06:35:46PM +0000, "Jóhann B. Guðmundsson" wrote:
On 09/24/2013 03:48 PM, Michal Jaegermann wrote:
On Tue, Sep 24, 2013 at 09:46:51AM +0000, "Jóhann B. Guðmundsson" wrote:
So from my point of view we wont be gathering reports from novices end users in 10 years time.
This is a plain self-fulfilling prophecy. If you will manage to kill report gathering means then indeed you will have no reports; from novice users in particular.
While bugzilla is far from perfect and it can be frustrating at times a "solution" you are pushing does not even start to pass a laugh test.
Really...
Let's run a simple query against bugzilla for bugs in the status NEW ( as in not looked at ) and find out the oldest report from our reporters for the soon to be EOL released F18 which should have the longest time maintainers could have responded bugs filed by reporters.
The oldest bug was filed by Stef Walter mailto:stefw@redhat.comon 2012-08-15 against binutils with total of 7205 bugs found. ( You can multiple that number by half an hour at least of reporters time )
Now let's look at the gory details of EOL bugs closed wontfix running [2]
8031 bugs found.
<snip>
Out of how many total bugs? Simply reported 8k bugs without a comparison tells us nothing.
Considering that Fedora is roughly 120 months old, that's about 66 bugs per month closed. That out of how many packages? That's, roughly, less than 1 bug per package ever that's been closed as wontfix. (meaningless, but think about it)
On 09/24/2013 07:28 PM, Darryl L. Pierce wrote:
On Tue, Sep 24, 2013 at 06:35:46PM +0000, "Jóhann B. Guðmundsson" wrote:
On 09/24/2013 03:48 PM, Michal Jaegermann wrote:
On Tue, Sep 24, 2013 at 09:46:51AM +0000, "Jóhann B. Guðmundsson" wrote:
So from my point of view we wont be gathering reports from novices end users in 10 years time.
This is a plain self-fulfilling prophecy. If you will manage to kill report gathering means then indeed you will have no reports; from novice users in particular.
While bugzilla is far from perfect and it can be frustrating at times a "solution" you are pushing does not even start to pass a laugh test.
Really...
Let's run a simple query against bugzilla for bugs in the status NEW ( as in not looked at ) and find out the oldest report from our reporters for the soon to be EOL released F18 which should have the longest time maintainers could have responded bugs filed by reporters.
The oldest bug was filed by Stef Walter mailto:stefw@redhat.comon 2012-08-15 against binutils with total of 7205 bugs found. ( You can multiple that number by half an hour at least of reporters time )
Now let's look at the gory details of EOL bugs closed wontfix running [2]
8031 bugs found.
<snip>
Out of how many total bugs? Simply reported 8k bugs without a comparison tells us nothing.
Considering that Fedora is roughly 120 months old, that's about 66 bugs per month closed. That out of how many packages? That's, roughly, less than 1 bug per package ever that's been closed as wontfix. (meaningless, but think about it)
That query was run against F17 which had our usually 13month run so I'm not sure where you got your 120 months from...
On Tue, Sep 24, 2013 at 07:55:44PM +0000, "Jóhann B. Guðmundsson" wrote:
Out of how many total bugs? Simply reported 8k bugs without a comparison tells us nothing.
Considering that Fedora is roughly 120 months old, that's about 66 bugs per month closed. That out of how many packages? That's, roughly, less than 1 bug per package ever that's been closed as wontfix. (meaningless, but think about it)
That query was run against F17 which had our usually 13month run so I'm not sure where you got your 120 months from...
I was talking about the overall age of Fedora (see my first sentence up to the comma).
Still, we have more than 8k packages (62,361) that's approximately 1 bug that was closed for every 8 packages. Not a huge problem viewed that way.
And, again, that's 8k out of how many overall bugs that were reported against F17? *THAT* would be a more telling answer as to whether there's even an issue here at all.
On 2013-09-24 19:55 (GMT) "Jóhann B. Guðmundsson" composed:
Considering that Fedora is roughly 120 months old, that's about 66 bugs per month closed. That out of how many packages? That's, roughly, less than 1 bug per package ever that's been closed as wontfix. (meaningless, but think about it)
That query was run against F17 which had our usually 13month run so I'm not sure where you got your 120 months from...
Fedora Core 1 was released 118 months ago.
On Tue, Sep 24, 2013 at 02:03:23AM +0000, "Jóhann B. Guðmundsson" wrote:
On 09/24/2013 01:45 AM, Michal Jaegermann wrote:
This absolutely does not scale from a POV of a user reporting bugs.
Well neither does it do so from developer standpoint that also has to maintain downstream distribution bugzilla accounts.
Developers in the upstream projects don't have to have accounts in the various distros' bugtracking systems. Quite the opposite: the package maintainers should have accounts in the bug tracking systems for the upstream projects s/he maintains.
Basically the amount of work and the effort are on par for both parties as in reporter has to file multiple reports against multiple package and the developer has to deal with multiple reports against multiple distribution in multiple downstreams etc. so arguing one has to do more work then the other is a mute point at least as far as I see it.
Disagreed.
If there's a bug upstream, and each distro reports it, then the upstream can mark any additional bug reports as duplicates. Though, again, the package maintainer for each distro would be expected to check and see if the bug is already reported and then attach themselves to it for updates, and also to add that upstream bug link to the BZ.
I do precisely this for the packages I maintain, specifically the Qpid packages. I also add the JIRA (which is used upstream) to any BZ reported against the packages. It's pretty simple.
in any case continue since we need to gather as much feedback as well as data points ( like how many bugs are being closed as EOL ) before throwing this to community voting and once the results from that are clear we can focus on improving our procedures in either direction.
On 09/24/2013 03:45 AM, Michal Jaegermann wrote:
On Mon, Sep 23, 2013 at 09:49:23PM +0000, "Jóhann B. Guðmundsson" wrote:
After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own.
...
Thoughts and comment.
This absolutely does not scale from a POV of a user reporting bugs.
Exactly, users are reporting bugs against a product called "Fedora", not against another party's product called "package".
In that sense it's a Fedora package maintainer's duty to arbitrate processing bug reports and communicate them to appropriate channels and/or initiate appropriate measures, while keeping the impact on the Fedora user and bug-reporters low.
In some situations, this means the package maintainer to implement a patch, in others, to forward a bug report to upstream, in some it may mean to initiate a direct contact between upstream and bug reporter.
It's simply another case of there is "no size fits all", except that Fedora MUST continue to carry some central address to receiving bug reports on Fedora's bugs. Currently that's bugzilla.
Ralf
On 09/24/2013 05:50 AM, Ralf Corsepius wrote:
Exactly, users are reporting bugs against a product called "Fedora", not against another party's product called "package".
In that sense it's a Fedora package maintainer's duty to arbitrate processing bug reports and communicate them to appropriate channels and/or initiate appropriate measures, while keeping the impact on the Fedora user and bug-reporters low.
In some situations, this means the package maintainer to implement a patch, in others, to forward a bug report to upstream, in some it may mean to initiate a direct contact between upstream and bug reporter.
It's simply another case of there is "no size fits all", except that Fedora MUST continue to carry some central address to receiving bug reports on Fedora's bugs. Currently that's bugzilla.
I agree with you that this should be packagers responsibility they themselves are suppose to triage their component and act accordingly by either gather the required information and forward it upstream but the reality is quite different more often than not they are in no communication with upstream nor are incapable to actually debug their own component or provide the information to do so.
JBG
On Tue, 24 Sep 2013 09:51:52 +0000, Jóhann B. Guðmundsson wrote:
[...] this should be packagers responsibility they themselves are suppose to triage their component and act accordingly by either gather the required information and forward it upstream but the reality is quite different more often than not they are in no communication with upstream nor are incapable to actually debug their own component or provide the information to do so.
_Why_ are they "in no communication with upstream"?
It is your impression that reports filed in Red Hat bugzilla are ignored by Fedora packagers. That's true for some packages [1], but the better fix for that would be to add package maintainers and/or triagers and testers, who don't ignore bugzilla completely. More team-work. The ACLs in pkgdb are there for a good reason. I mean, sometimes the packaging is broken, and even reports about that seem to get ignored.
Also, there are upstream developers, who enjoy visiting bug details in Red Hat bugzilla when they are pointed at it. E.g. via a direct link to a stacktrace or via the overview at http://bugz.fedoraproject.org/SRCRPMNAME
[1] In other cases, there won't be a response in an upstream bug tracker either. The more tickets, the less likely it is that someone will process them all. Sometimes the code changes so quickly and developers are aware of issues in the replaced code, problem reports are obsolete already when they are filed.
On 09/24/2013 11:22 AM, Michael Schwendt wrote:
_Why_ are they "in no communication with upstream"?
?
Because there is no requirement for them doing so when they become maintainers for a given package nor is it being ensured if package is orphaned that the maintainer that takes it over is in any communication with upstream.
The rest is basically you telling us that you want ship that package maintainership responsibility over to the QA community ( triagers/testers ) if that is the case is it not better that our triager/tester teams deal directly with upstream with the people that know and can fix their code.
JBG
On Tue, 24 Sep 2013 11:29:52 +0000, Jóhann B. Guðmundsson wrote:
On 09/24/2013 11:22 AM, Michael Schwendt wrote:
_Why_ are they "in no communication with upstream"?
?
Because there is no requirement for them doing so when they become maintainers for a given package
https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Work_with...
nor is it being ensured if package is orphaned that the maintainer that takes it over is in any communication with upstream.
Same as above.
The rest is basically you telling us that you want ship that package maintainership responsibility over to the QA community ( triagers/testers )
There is no such rough split between package (co-)maintainers and "the QA community". I don't even know how you define "the QA community".
if that is the case is it not better that our triager/tester teams deal directly with upstream with the people that know and can fix their code.
Can't comment on that before clearing up the matters above.
On Tue, 24 Sep 2013 12:29:04 +0000, Jóhann B. Guðmundsson wrote:
There is no such rough split between package (co-)maintainers and "the QA community". I don't even know how you define "the QA community".
Those that participate in QA community activity testing/reporting etc.
That includes package (co-)maintainers who acquire 'watchbugzilla' access in pkgdb and handle incoming problem reports.
It is a perfectly fine scenario for somebody, let's say "a power-user", with interest in a Fedora package to join as a co-maintainer and focus on problem reports and testing of the "product" we release, even if there may be no interest in 'commit' access to the Fedora package. That doesn't "ship [...] package maintainership responsibility over to the QA community", but only shows how open the Fedora Project is for commitment from interested people.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/23/2013 05:49 PM, "Jóhann B. Guðmundsson" wrote:
Greetings you all
After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own.
Now it pretty much boils down to this.
- Generic attitude of many maintainers is that reports either go
to the correct place ( upstream ) or they get their bugzilla ignored. 2. More often than not downstream maintainer as in packager does not know the code at all so filling the bug downstream makes no sense since it brings just unnecessary latency to the process. 3. Hosting our own bugzilla cost resources and does not solve 1. or 2.
I personally for many years have argued against this since to an reporter it might mean having thousand of accounts but given that we are going through new fase and the times are changing in the linux eco system I would like to get your opinion about we stop reporting altogether in Red Hat bugzilla and report only directly upstream as in kernel bugs to the kernel community, Gnome bugs to theirs, KDE to their etc.
The obvious benefit of doing this is that our bugs might actually get look at,dealt with as well as all that being done in a shorter time frame.
Thoughts and comment.
JBG
To Date I've seen several posts, but feel it appropriate to reiterate some of what I have read. First I've been a computer user/programmer for 39 years. I've been a Fedora User since Fedora 6 and a test monkey of sorts since Fedora 11. That said I still find it confusing at Bugzilla to know what package to file bugs against. Recently I filed an F20 Bug because the Network Manager Icon did not behave as expected. Network Manager Icon so I filed against NetworkManager. Turns out the icon is contolled by some gnome-nm-applet and the bug needed to be filed against that package. Using RH Bugzilla the package maintainers knew this and rerouted the bug which was addressed. In the world you suggest, I would have gone to NetworkManager and opened a bz account there or tried to remember the one I had from F18. Then when I got a "it's not our problem" response, tried gnome's bz and maybe have been directed to the applet bz. I can't begin to imagine how frustrating this will be for new users. When you choose distro X and it doesn't work you expect them to at least take your report and assist you making their distro work, whether the problem is theirs or upstreams or the users ineptitude. I am definitely opposed to a departure from the current bug reporting methods, unless the new method can be fully automated, and even then I would be skeptical. It may cost RH something to maintain BZ for Fedora in terms of infrastructure and support personnel. But trying to pass this buck to upstream is a wrong move, IMHO.
Sincerely, Bob Lightfoot
Jóhann B. Guðmundsson wrote:
After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own.
I don't chant that mantra.
I am a Fedora consumer, not a maintainer or programmer. My bug reports to bugzilla are a service to the Fedora community, to help make Fedora a better OS, even though it is often time-consuming and bothersome to me.
On Mon, 23 Sep 2013 21:49:23 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
Greetings you all
After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own.
There is also a thread on infra https://lists.fedoraproject.org/pipermail/infrastructure/2013-September/0134... The Jury is still out, along with the rest of the court.
On 09/24/2013 05:24 AM, Frank Murphy wrote:
On Mon, 23 Sep 2013 21:49:23 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
Greetings you all
After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own.
There is also a thread on infra https://lists.fedoraproject.org/pipermail/infrastructure/2013-September/0134... The Jury is still out, along with the rest of the court.
The jury is not out on that infra has already stated that we wont be having our own bug tracker due to lack of man power which means we cannot implement something like our own badges etc for reporting participation.
And the jury of this will end with vote so this matter will be settled once and for all and the outcome of be our ( QA communities ) focus for the next 10 years.
JBG
On Tue, Sep 24, 2013 at 09:55:40 +0000, ""Jóhann B. Guðmundsson"" johannbg@gmail.com wrote:
The jury is not out on that infra has already stated that we wont be having our own bug tracker due to lack of man power which means we cannot implement something like our own badges etc for reporting participation.
I would still be possible to implement badges using Redhat's bugzilla. It may not be as nice as what we could do with our own, but we can certainly do queries for Fedora bugs and do stuff with the returned information.
On 09/24/2013 07:33 PM, Bruno Wolff III wrote:
On Tue, Sep 24, 2013 at 09:55:40 +0000, ""Jóhann B. Guðmundsson"" johannbg@gmail.com wrote:
The jury is not out on that infra has already stated that we wont be having our own bug tracker due to lack of man power which means we cannot implement something like our own badges etc for reporting participation.
I would still be possible to implement badges using Redhat's bugzilla. It may not be as nice as what we could do with our own, but we can certainly do queries for Fedora bugs and do stuff with the returned information.
There is more then that we need the ability to "health" monitor components etc
JBG
On 09/23/2013 11:49 PM, "Jóhann B. Guðmundsson" wrote:
Greetings you all
After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own.
Now it pretty much boils down to this.
- Generic attitude of many maintainers is that reports either go to the
correct place ( upstream ) or they get their bugzilla ignored. 2. More often than not downstream maintainer as in packager does not know the code at all so filling the bug downstream makes no sense since it brings just unnecessary latency to the process. 3. Hosting our own bugzilla cost resources and does not solve 1. or 2.
I personally for many years have argued against this since to an reporter it might mean having thousand of accounts but given that we are going through new fase and the times are changing in the linux eco system I would like to get your opinion about we stop reporting altogether in Red Hat bugzilla and report only directly upstream as in kernel bugs to the kernel community, Gnome bugs to theirs, KDE to their etc.
The obvious benefit of doing this is that our bugs might actually get look at,dealt with as well as all that being done in a shorter time frame.
Thoughts and comment.
This kind of discussions have been beaten to death over the years Fedora exits.
That said, I regret having to tell you that your plan is dumb, naive, and far from being workable.
Ralf
That said, I regret having to tell you that your plan is dumb, naive, and far from being workable.
Ralf
That said, I regret having to tell you that insulting the OP instead of pointing out relevant arguments is dumb, naive and far from being helpful.
;-)
Jan
On 09/24/2013 10:25 AM, Jan Wildeboer wrote:
That said, I regret having to tell you that your plan is dumb, naive, and far from being workable.
That said, I regret having to tell you that insulting the OP instead of pointing out relevant arguments is dumb, naive and far from being helpful.
Well, sometimes, there are situations, where there is no other way but to resort to this kind of drastic language to have people comprehend what they are proposing.
Johan's proposal is such kind of beyond reason and applicability, it's not even worth being discussed.
Ralf
On 09/24/2013 09:17 AM, Ralf Corsepius wrote:
On 09/24/2013 10:25 AM, Jan Wildeboer wrote:
That said, I regret having to tell you that your plan is dumb, naive, and far from being workable.
That said, I regret having to tell you that insulting the OP instead of pointing out relevant arguments is dumb, naive and far from being helpful.
Well, sometimes, there are situations, where there is no other way but to resort to this kind of drastic language to have people comprehend what they are proposing.
Johan's proposal is such kind of beyond reason and applicability, it's not even worth being discussed.
I comprehend very well what I'm proposing ( given I've been on the same side of the fence that reporters are for the last 5 years or more ) but do you comprehend where we are heading?
You do know that atleast one desktop is going for supporting app bundles right so we need to test that functionality downstream with us as well as reporting that to relevant upstream.
So I think that you need to start thinking and speculating and asking yourself where will we be in 5 - 10 years time yes there are people that are responsive in bugzilla and do look at it from time to time but quite frankly the majority ignores it.
To give you an example I added a simple requirement patch for ca 50 component ( making the component FPG compliant ) in July as an stage 1 for migration of relevant cron jobs ( which are not the ones on that list ) to native systemd timer units( stage 2 being the actual migration for the rest of the components ) and still after all the time that has passed we got 24 open bugs with those patches just hanging there
On 09/24/2013 06:17 AM, "Jóhann B. Guðmundsson" wrote:
I comprehend very well what I'm proposing
Frankly, I don't think you do.
( given I've been on the same side of the fence that reporters are for the last 5 years or more )
Oh, so now we're trotting out credentials to make our case? How about this, then... I've been using and programming computers since 1981, when my family bought our shiny, new Apple ][+ (We even splurged for the 16K expansion card, giving us a whopping 60KB of RAM! As I recall, our computer cost around $2,000, which back then was a lot of money!). I've been the head maintainer or contributor to more FOSS projects than I can recall off the top of my head. I have a bachelor's degree from MIT, where I worked on Project Athena in just about every role in the software lifecycle, as well as spending six years working for the user help-desk as both a volunteer and paid user consultant (which means, frankly, that I have a hell of a lot more experience than you at understanding how novice users think and what they will and won't put up with). I helped write Kerberos, which means that code I wrote is running on pretty much every Linux, Mac, or Windows computer in the world. I've contributed to the Mozilla core. I was using Fedora long before it was Fedora. I was one of the original members of the Red Hat Beta Team, so long ago that most people on this list have probably never heard of it, and I have the "We kill bugs dead" T-shirt to prove it. I was, at one point, such a prolific submitter of bugs into RHBZ that for quite a while I had submitted far more bugs than anyone else (as of today I've reported 1,236 bugs to RHBZ).
So I think that you need to start thinking and speculating and asking yourself where will we be in 5 - 10 years time yes there are people that are responsive in bugzilla and do look at it from time to time but quite frankly the majority ignores it.
Do you have hard data to support that assertion, or just anecdotal stories about bugs you've filed that have been ignored?
In my experience, the majority of bugs that I've filed have received attention from package maintainers.
jik
On 09/24/2013 01:00 PM, Jonathan Kamens wrote:
Oh, so now we're trotting out credentials to make our case
No I was just making the point that I have been the nr1 arguing against what I'm proposing now for many years so I'm aware of all the inconvenience it will bring reporters.
You can go through the archives and see for yourself if you dont believe me.
JBG
On 23.09.2013 23:49, "Jóhann B. Guðmundsson" wrote:
Greetings you all
After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own.
Now it pretty much boils down to this.
- Generic attitude of many maintainers is that reports either go to the
correct place ( upstream ) or they get their bugzilla ignored. 2. More often than not downstream maintainer as in packager does not know the code at all so filling the bug downstream makes no sense since it brings just unnecessary latency to the process. 3. Hosting our own bugzilla cost resources and does not solve 1. or 2.
I personally for many years have argued against this since to an reporter it might mean having thousand of accounts but given that we are going through new fase and the times are changing in the linux eco system I would like to get your opinion about we stop reporting altogether in Red Hat bugzilla and report only directly upstream as in kernel bugs to the kernel community, Gnome bugs to theirs, KDE to their etc.
The obvious benefit of doing this is that our bugs might actually get look at,dealt with as well as all that being done in a shorter time frame.
Thoughts and comment.
JBG
Great idea, but how would one know all that upstream bug tracker URLs for all packages that are shipped with Fedora?
Is there any tag in RPM package spec file that could be used to provide such information and are you planning to extend package descriptions so people can easily find upstream bug tracker URLs?
Are there any plans to provide central information point (wiki, etc.) with all upstream bug trackers in place of old RH bugzilla?
Mateusz Marzantowicz
On 09/24/2013 10:45 AM, Mateusz Marzantowicz wrote:
Great idea, but how would one know all that upstream bug tracker URLs for all packages that are shipped with Fedora?
Is there any tag in RPM package spec file that could be used to provide such information and are you planning to extend package descriptions so people can easily find upstream bug tracker URLs?
Are there any plans to provide central information point (wiki, etc.) with all upstream bug trackers in place of old RH bugzilla?
We would have to build something like that as well as to how to debug these components.
Now there ofcourse is a different approach we could take as instead of always running after upstream and try to convince them to join our project we could move/migrate everything to github ( which is the largest social coding side afaik ), sync upstreams that dont already exist there to it [1]. and sync from there to koji to build (s)rpm.
We in QA could then use [2] harvest all the required info as well point reporters to report there.
From a QA and developer standpoint the perfect pony could be for developers to attach a patch or reporters to press build it ( after patch has been provide upstream ) to be able to consume and test the fix the upstream maintainer provided without the overhead of knowing how to rebuild complete upstream ( which more or less is the inconvenience that will make reporters give up ).
That rebuild could then be deployed in an isolated container on top of btrfs subvolume, then tested and reverted easially if necessary or kept and the older instance thrown away.
Ofcourse the above could be something we would work towards against achieving here in QA in the next 2 years.
JBG
1. https://help.github.com/articles/syncing-a-fork 2. ttp://developer.github.com/v3/issues/
JBG
On Sep 23, 2013 3:49 PM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
Greetings you all
After bit of irc discussion there is a compelling reason to move entirely
away from Red Hat bugzilla as well as away from concept of hosting our own.
Now it pretty much boils down to this.
- Generic attitude of many maintainers is that reports either go to the
correct place ( upstream ) or they get their bugzilla ignored.
- More often than not downstream maintainer as in packager does not know
the code at all so filling the bug downstream makes no sense since it brings just unnecessary latency to the process.
- Hosting our own bugzilla cost resources and does not solve 1. or 2.
I personally for many years have argued against this since to an reporter
it might mean having thousand of accounts but given that we are going through new fase and the times are changing in the linux eco system I would like to get your opinion about we stop reporting altogether in Red Hat bugzilla and report only directly upstream as in kernel bugs to the kernel community, Gnome bugs to theirs, KDE to their etc.
The obvious benefit of doing this is that our bugs might actually get
look at,dealt with as well as all that being done in a shorter time frame.
Thoughts and comment.
JBG
Bug trackers and maintainer triage are a service to both users and developers. Larger projects might accommodate providing this upstream, but not all can or wish to. Small projects might turn to fedorahosted, or OBS, or launchpad. Remove the service, and we are less appealing for developers to directly participate in. Send users to another service, and they begin to question our value. I have been pondering an allegory for you, enjoy:
I invite you to go camping. You are having fun, until I take a burning stick from the fire and poke you in the arm. You learn fire is hot, and know me as the one that burned you.
My campsite does not have a first aid kit. I tell you about therapeutic plants, and send you into the forest. As you search, you discover another campsite. They share their first aid kit. You might need further medical care, or not. You learn burns can heal, and know this party as the one that healed you.
As you visit, you learn that everyone that goes camping can get hurt sooner or later. When they invite you to stay, you accept, because I am still the one that burned you.
This proposal says that your arm is half cooked, and we're getting hungry anyway, so we cut the arm off and eat it.
--Pete
On Mon, 2013-09-23 at 21:49 +0000, "Jóhann B. Guðmundsson" wrote:
Greetings you all
After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own.
Now it pretty much boils down to this.
- Generic attitude of many maintainers is that reports either go to the
correct place ( upstream ) or they get their bugzilla ignored. 2. More often than not downstream maintainer as in packager does not know the code at all so filling the bug downstream makes no sense since it brings just unnecessary latency to the process. 3. Hosting our own bugzilla cost resources and does not solve 1. or 2.
I personally for many years have argued against this since to an reporter it might mean having thousand of accounts but given that we are going through new fase and the times are changing in the linux eco system I would like to get your opinion about we stop reporting altogether in Red Hat bugzilla and report only directly upstream as in kernel bugs to the kernel community, Gnome bugs to theirs, KDE to their etc.
The obvious benefit of doing this is that our bugs might actually get look at,dealt with as well as all that being done in a shorter time frame.
Thoughts and comment.
Well, that's going a bit far.
I don't know, none of this really seems like news to me. Whenever I'm about to file a bug, I ask myself if it's more appropriate to file it upstream or downstream, and then file it at the appropriate place. Neither filing all bugs upstream or filing all bugs downstream is the best way to go about things. As others have pointed out, we really need a Fedora bug tracker for bugs that really are bugs in *Fedora* - packaging bugs, bugs in patches we carry, 'this package needs updating' bugs - and for various tracking purposes (release blockers, mass rebuilds...)