Adam Williamson wrote:
On Wed, 2009-03-04 at 07:53 -0500, Paul W. Frields wrote:
http://lwn.net/Articles/321473/
I don't think there's been a lot of discussion yet about any future,
larger triage event. But in any case before we get there, we might
want to see what lessons we can draw from this thread. Perhaps
there's something constructive from which we can learn for daily
triage?
I've seen similar threads before. The thing I generally take out of
them, which I really tried to get MDV bug triagers to buy into, is
follow up. Triaging isn't a drive-by operation, you have to follow up
the bug. You really should be in CC for any bug you triage.
What Ubuntu users get frustrated about is when a triager touches one of
their bugs, then never comes back, and basically makes it *less* likely
to be addressed by the developer.
I had a quick look at some of the bugs. I'd be pretty disappointed
either as a developer or as a user. For example, someone complained that
changes to /boot/grub/menu.lst got wiped. There were several
suggestions, none really cleaning it up.
Looking at it, I would expect a triager to have read the description,
read the documentation and closed it, highlighting the user's error.
Debian, and so Ubuntu, included metadata as comments, and comments about
the metadata have two hashes. The kopt statement requires a leading hash
(it's used to provide kernel options) and is interpreted by update-grub.
I know John is big on this too. Our job is to be an ongoing interface
between the reporter and the maintainers, to make it easier and more
efficient for the right information to flow in both directions. We're
not just blindly touching bugs and moving on.
I wondered to what extent the comments that followed applied to Fedora.
In an office environment, I'd have beginner triagers recommending
actions to someone with a bit more experience, but not making changes to
anything on their own initiative. I would also _not_ want them looking
at everything.
These following remarks have no bearing on how Fedora actually works, I
don't know and I don't think I want to know;-) If it causes people to
reflect on how things are done now and consider alternatives, that is good.
I used to work in an IBM mainframe environment, and the area I worked in
mostly was responsible for
1. Installing and maintaining operating system software. In a Linux
environment, this would be the kernel, startup, filesharing and so on.
At the last place I did this, we had 18 people.
2. Installing and maintaining software for applications developers. This
would include compilers and other development tools.
3. Developing, installing and maintaining local applications development
aids.
4. Since this last was me, I also spent time advising teams how to do
their own, further, customisations so they fit in with everything else.
Modifying vendor software was generally strongly discouraged, especially
when there was a straightforward way of doing what was wanted.
In Linux I would separate out GNOME, KDE, and each of the other
desktops, and then maybe recombine some depending on the workload for each.
There is much to learn in Linux, way more than we had in the 80s, and I
would expect triagers to choose areas of interest, to be assigned
someone to mentor them and stay within their area.
So discussions remain public, but without lots of irrelevant
information, each area might have its own communication channels, - a
mailing list, a forum, an IRC channel. I suspect the mailing list is
easiest, I rather think Forums require heavy maintenance from time to
time (think software upgrade), and I don't think I've every found
archives of IRC channels when googling for answers to my numerous questions.
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
