On Thu, 2014-07-17 at 20:56 +0100, Allan Day wrote:
A good first step would be to draw up a list of ARBT bugs that we
are critical for the Workstation user experience (this one 
immediately springs to mind.) We should also ensure that any critical
issues have been reported. It would be fantastic if someone could take
OK. My list of critical bugs is small, but each one is very serious. You
already mentioned . I will add to that  and .  is fairly new
but occurs immediately nearly every time I report a bug, causing the
report to fail.  used to cause reports to fail at the very end of the
(excruciatingly long) bug report process roughly 50-80% of the time, but
nowadays I cannot get past .
 looks like a duplicate of , but I list it here because I filed
 specifically regarding Epiphany crashes, but (prior to the
introduction of  it would) regularly occurs for other programs as
 is the "bug of general slowness" I mentioned earlier. I need to make
a correction: earlier in this thread I claimed reporting a WebKit bug
took me 40 minutes, and a gnote bug 15 minutes. In fact, reporting a
Nautilus bug took 40 minutes, and the gnote bug a much more reasonable 5
minutes. (I haven't timed a WebKit bug like I thought I had, but I
estimate it to be comparable in length.)
So that's four distinct bugs that I consider critical. I'll add on ,
which doesn't happen to me very often, but I feel is worth mentioning
here. Beyond these, there are several design issues and minor bugs with
ABRT's GUI that need work, but I don't think are sufficiently serious to
block on or mention here. I've reported bugs for a few of few of these
in the past, and I'll do a couple more today.
Second, we (or I...) need to do a design review to see where we are
and where we want to be with regards to the problem reporting user
experience. There is a lot of background material that we can draw on
Once we've done these two steps, we'll be in a position to have a
constructive conversation with the ABRT team.
My apologies to the ABRT team if my comments were at times too harsh or
nonconstructive. I'm hoping my comments help improve the default user
experience of Fedora Workstation and ABRT.
There is also a more general issue here: traditionally, the Fedora
release process has had a fairly limited definition of what
constitutes a blocker, and there isn't a huge amount of downstream bug
tracking in the run up to a release. If we want to raise the quality
of the overall workstation experience, we'll need to expand the range
of issues that are tracked for each release to include more general
user experience bugs. This might well require changes to the
workstation release process, as well as new release management roles.
Allan, I absolutely agree with you. Don't forget about updates, though:
all the pre-release validation in the world won't help if the updates
repository is the wild west.