debian at herakles.homelinux.org
Thu Mar 5 03:01:37 UTC 2009
Adam Williamson wrote:
> On Wed, 2009-03-04 at 07:53 -0500, Paul W. Frields wrote:
>> 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
> 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
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
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.
1aaaaaaa at coco.merseine.nu Z1aaaaaaa at coco.merseine.nu
You cannot reply off-list:-)
More information about the fedora-test-list