Interesting comments

[John Summerfield]

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 at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu
-- 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:-)