[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: frustration: mailing lists and bugzilla reports
- From: Alexander Larsson <alexl redhat com>
- To: fedora-test-list redhat com
- Subject: Re: frustration: mailing lists and bugzilla reports
- Date: 13 Nov 2003 09:54:24 +0100
On Wed, 2003-11-12 at 21:00, Gene C. wrote:
> While this message will ultimately meet the "requirements" for reporting to
> this list ("is this a bug"==fedora-list, "here is a proposed
> patch"==fedora-devel-list, and "here are some rpms to
> test"==fedora-test-list), I am going to take the opportunity to comment on a
> couple other items.
> First, I can empathize with those posting to this list about bugs rather than
> fedora-list because the fedora-list has a too low signal-to-noise ratio. The
> problem described below has been posted to the fedora-list but has received
> little in comments. Few Red Hat folks seem to read the list (noteable
> exception is Bill Nottingham) and I cannot blame them due to the S/N ratio.
> Second, I have a question concerning bugzilla reports. Many reports appear to
> stay in a "NEW" status for a very long time (sometimes forever). While some
> individuals may be away due to circumstances such as vacation, being sick,
> etc., I would expect that some attention would be paid to these reports. It
> is frustrating when they appear to be ignored and the bug continues ... like,
> why bother reporting it when the report is ignored.
I do understand what you're saying, but you have to look at it from our
side too. Take gnome bugs for instance, I and three other basically
handle all the gnome packages, and together we have many hundred open
bugs for them, and furthermore we all work in gnome upstream where there
are thousands of bugs in the gnome bugzilla, many that we own, being
maintainers for core upstream packages.
Our daily work consists of many things, like following redhat and gnome
upstream mailing list discussions (thousands of email a day), replying
to bugreports we get in the redhat and gnome bugzillas, helping people
on irc, actually spend time trying to track down and fix bugs, working
on new features for redhat, working on upstream development gnome
features, work on gnome organizational or sysadmin issues, etc.
Now, the balance between these are very tricky, you don't want to spend
all your day reading email, but at the same time its important to keep
up to speed and reply to peoples problems, to help people, to keep the
mailing lists useful, and to keep the projects on track. Its important
to fix bugs, since bugs irritate people and make software suck, but at
the same time there *has* to be new work on features, rewrites, etc,
since these are what really drive software forward (and in many cases
help fix the cause of many bugs you otherwise could spend lots of time
working around). At the end of the day, a new major feature in the next
release might be more important than a bugfix in the current release
that only affects a few people.
This balance act is made even harder by the fact that you really can't
context switch between these different things often. To write new code
you have to have a large chunk of uninterupted time, or things take a
lot more time. Even fixing bugs can take quite som time too, so you
can't be interrupted by mail/irc all the time.
The way I try to handle this is to make the different schedules (gnome,
fedora, rhel) i work under control what focus my work has. So, during
the heavy beta period, say test1 to test3 I work mainly on fixing bugs
in bugzilla, but as we reach the "deeply frozen" part after the last
beta has shipped I target only extremely bad stop-ship bugs (common
crashers, really ugly things in the default setup, etc). Much of this is
tracked via the shouldfix and mustfix buglists in bugzilla, but I also
have a general feel of what is important of the thousands of bugs i'm
responsible for in rh/gnome bugzilla.
So, when the release is freezing and eventually shipped I start to ramp
up my feature work. We're lucky with our schedules this time, so this
means I get some real time to spend in the gnome 2.5 development phase
before the 2.6 feature freeze. During this time I spend much less time
on bugzilla, I glance over my bugzilla mails, and read a few that seem
important, but I don't spend any real time fixing stuff unless its
really really bad (security, etc).
No matter what phase i'm in I try to follow the mailing lists, but when
in deep coding mode I tend to do so less detailed and not reply as
often. However, just reading email takes me several hours a day, so
sometimes when coding I don't even do this for a couple of days.
However, just because I don't immedately work on fixing a bug doesn't
mean its "ignored". Eventually the feature development phase will end
and we'll reach a stabilization phase again. Then I'll start looking
seriously at the reports in bugzilla again, and hopefully I can fix a
fair share of the important and the easy bugs.
Even if the bug gets fixed upstream after the release, I don't typically
spend time doing an updated package. Hundreds of bugs get fixed in gnome
every week, and building, testing and pushing out an updated package
takes a large chunk of time. I could easily spend all my time doing
that, but that would mean I could do no upstream development at all.
This is also the reason that we want people to report bugs upstream, or
refile them ourselves. We're not that many, and we own a lot of code, so
we can't spend much time on less important issues. But a bug filed
upstream goes directly to the person responsible for the application,
who hopefully cares a lot about his app, is more focused on it, and
knows it better. (Of course, in some cases we're the upstream owner
What it all comes down to is that bugzilla is a tool to help developers
manage their work. There is no guarantee that a bug will be fixed when
its in bugzilla, thats all depending on how much time the responsible
developer has, how he prioritizes his time, etc. However, if the bug is
in bugzilla, there is a better chance of the bug being fixed. The bug
won't be forgotten, all information about the bug is stored in the same
place, other people can report more info in the bug, and its even
possible for other people to help fix the bug.
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a war-weary day-dreaming matador moving from town to town, helping folk
in trouble. She's a tortured tempestuous former first lady married to the Mob.
They fight crime!
[Date Prev][Date Next] [Thread Prev][Thread Next]