User: Password:
|
|
Subscribe / Log in / New account

Fedora and bug tracking

Fedora and bug tracking

Posted Oct 3, 2013 11:17 UTC (Thu) by johannbg (subscriber, #65743)
Parent article: Fedora and bug tracking

Given that Red Hat slapped the community hard in the face yesterday on the fesco meeting with " basically if whatever they come up with doesn't work for RH, it's a non-starter." in relation to setting the "new" direction of Fedora. An clear cut message across the community as well to potentially new contributors that says...

"Here come and join Fedora we will allow you to do everything but influence or participate in anykind of direction that project might take but we do our best effort making you feel like you actually are making a difference"

An truly a dark day in Fedora community history taking place there with Red Hat essentially acting as Canonical towards the Fedora community.
I feel compelled to point I have been part of Fedora QA longer then the entire current Red Hat's Fedora QA staff.

That staff is made entirely out of individuals outside the community that come and go as people do in any regular job and the community cant rely on so I ask of you in your future articles to make an clear distinction of the Fedora QA community members and Red Hat hired and planted staff to work on Fedora QA under various made up titles within that company that have no meaning out in the community.

Adam Williamson for example is not from the Fedora community, he never was but was hired and planted into the community through a made up position from within the ranks of Red Hat.

An position that now is being shared by two individuals ( or the new one which has replaced Adam which means he's leaving either Red Hat or to do something else).

And dont mistake me, he and a lot of RH employees go on and beyond their corporate duty and try to do their best to make Fedora succeed ( both within the community as well as fight for it's right within Red Hat ) and stay true to the community spirit so one cannot blame it's entire staff but people should be aware of how Red Hat operates as a company and how in reality it's treating the community.

Now the article is mostly spot on with the exception that you failed to mentioned that the triaging efforts within the distribution have failed 4 times which I'm pretty sure Bill was already aware of when he responded with "triagers".

As well as Matthias response which makes a point which I do believe many share

"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."

It was also pointed out outside the mailinglist ( irc ) that in Gnome for example they need an upstream report for most fixes since a lot of gnome modules require commits reference to an upstream bug report in the commit message.

Another point was made ( on irc ) that we as an downstream are giving our users binaries but upstream usually can only debug using source, which points out another problem that a lot of people can't rebuild complete upstream code outside the the distribution.

And this problem is not limited to distribution.

If we take for example kernel.org bugzilla it's an hit an miss for reporters depending on subsystem.

In the end of the day( as got pointed out as well on irc ) the only thing that matters is talking to your devs through the interface they find effective by the person which can reproduce it locally ( be it the reporter,the triager,the packager ).

Our part in Fedora QA is to find the most effective way of having the bug reported in our distribution fixed for our userbase not let them rot in our bug tracker like many do [1].


(Log in to post comments)

Fedora and bug tracking

Posted Oct 4, 2013 14:52 UTC (Fri) by ovitters (subscriber, #27950) [Link]

If bugs are reported quickly upstream (e.g. GNOME), then more people are aware. We can track the bug, nominate it as a blocker. Figure out the state of the project, etc.

But that doesn't really matter in this topic. The discussion is related to if the upstream bug should be filed by the package maintainer, or by the person reporting the bug.

Going through the article, it seems that there are multiple needs and it is expected that you can only have one solution. I think that's wrong.

For Fedora, you want to have an overview of important big impact bugs. It doesn't matter if this is a list compiled via upstream bugs or not. You need to be aware of big issues and work on them. Part of those bugs are purely upstream bugs, but you will still need to be aware of them.

Then for any release, the QA process also needs to handle releasing a new image. I don't get why suddenly this is mixed together with the other needs. If QA would write this down on a paper, used a telephone to call people and that works for the QA process, then why not use that?

Then you have packages with either an overworked maintainer, or a package which plainly does not differ from upstream (no patch). Why not just send this upstream directly?

You could have a real packaging bug (error in description, URL, whatever). That is another need.

IMO the various needs need to be written down. Don't immediately look for technical solutions.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds