[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Interesting comments

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



-- spambait
1aaaaaaa coco merseine nu  Z1aaaaaaa coco merseine nu
-- Advice

You cannot reply off-list:-)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]