Gentoo Archives: gentoo-dev

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy
Date: Thu, 16 Jan 2014 20:19:25
Message-Id: 52D83EAA.4020300@gmail.com
In Reply to: Re: [gentoo-dev] rfc: revisiting our stabilization policy by Peter Stuge
1 On 16/01/2014 20:26, Peter Stuge wrote:
2 > Alan McKinnon wrote:
3 >> "Respecting bug priority" feels like that corporate BS I have to put up
4 >> with every day.
5 >
6 > Gentoo is incorporated so maybe that fits. ;)
7 >
8 > On a more serious note, please try to understand what I meant rather
9 > than just what I wrote.
10 >
11 > I wrote both "assigning" and "respecting"; your gripe with "corporate BS"
12 > may be a result of how priority was assigned to your bugs, and likely
13 > amplified if you can't do much to influence that process. If you only
14 > get a priority shoved down your throat you of course can't really
15 > respect it.
16 >
17 > For priority to have any meaning on bugs.g.o there would need to be
18 > some buy-in among developers to actually want to work together to
19 > assign the proper priority to each bug.
20 >
21 > Bug trackers aren't management command and control tools, they are
22 > hive minds which just remember what workers agree on anyway.
23 >
24 >
25 >> the only bugs that get any attention at all are ones where some
26 >> fool of a manager thinks he can shout louder than anyone else.
27 >
28 >> We have nothing to offer maintainers except fuzzy-feel-good and
29 >> recognition; we have to trust them to do the right thing.
30 >
31 > Nobody will do the right thing if they don't know what it is.
32 >
33 > Recognition can certainly communicate that higher priority bugs are
34 > more important, but honestly, I wouldn't want someone who needs to
35 > be told that explicitly on my (the Gentoo) team in the first place..
36 >
37 > Disclaimer for anyone who might find this upsetting: Of course people
38 > always have limited scope, and it is perfectly fine if high priority
39 > bugs can simply not be fixed by whoever has time to work on bugs at
40 > any given moment.
41 >
42 > IMO, closing bugs without having the right fix has negative value.
43 >
44 > I know that it can be depressing and demotivating to have too many
45 > bugs, just like it is to live in a too messy room, but I really do
46 > think that the best solution is simply to pick one thing up at a
47 > time. It may take a long time, but in the end the room is clean. :)
48
49
50 When relying on folk's goodwill (like in the open source world), I find
51 there are really only two priorities
52
53 1. the bug breaks stuff
54 2. everything else
55
56 with possibly a #3 - stuff that doesn't matter, can be done whenever.
57
58 Gentoo devs have shown time and again that they do take #1 seriously.
59 After all, they are themselves Gentoo users. The team that is dealing
60 with the bug may of course assign priority as they see fit as long as
61 they mostly agree on what it is.
62
63 I reckon the cardinal rule is "avoid as much as possible having priority
64 set by someone who is not solving the problem". I think that comes close
65 in my words to what you are saying.
66
67
68 --
69 Alan McKinnon
70 alan.mckinnon@×××××.com

Replies

Subject Author
Re: [gentoo-dev] rfc: revisiting our stabilization policy Peter Stuge <peter@×××××.se>