1 |
On 24-02-2010 23:41:26 +0000, Robin H. Johnson wrote: |
2 |
> Proposed types: |
3 |
> --------------- |
4 |
> - version-bump |
5 |
> - trivial-version-bump |
6 |
> - trivial-fixes |
7 |
> - fixes |
8 |
> - enhancements |
9 |
> - qa-fixes |
10 |
> - trivial-qa-fixes |
11 |
|
12 |
Isn't the QA team by its definition allowed to fix QA issues? If so, I |
13 |
don't see a point in explicitly allowing qa-fixes of any kind, since |
14 |
it's implicit for the QA team that is supposed to do this. For QA its |
15 |
probably good to get people in the loop anyway, so they learn, instead |
16 |
of just find their packages fixed in one way or another. |
17 |
|
18 |
In general it feels like if you really want to allow a very high degree |
19 |
of modifications to your ebuilds as "maintainer", perhaps it is better |
20 |
to introduce a special group of ebuilds that have in the best case |
21 |
someone watching over them every now and then, but are not tied to |
22 |
"someone". Almost sounds like "maintainer-needed": looking for someone |
23 |
who really cares about this package, perhaps even users welcome for |
24 |
proxy maintenance. |
25 |
|
26 |
Another thing may be just the "maintainer-timeout" thing, that simply |
27 |
says that if the maintainer doesn't respond to requests for a |
28 |
change/update, you are allowed to perform the change. Normal sanity and |
29 |
responsibility rules apply of course. Some bugs just hang around for |
30 |
even years with multiple devs commenting on them, and the maintainers |
31 |
just not responding at all. Seems like in such case a time-out rule |
32 |
says more than a once written metadata element. |
33 |
|
34 |
Maybe we just shouldn't try to own something, but rather be the first to |
35 |
say something about it. Maybe we should try to identify (groups of) |
36 |
packages that are way more important than others (think of ... python?) |
37 |
and mark them as needing special care, treatment and barriers before any |
38 |
dev would feel like touching them. Perhaps that would just mean rings |
39 |
of developer ranks where the inner circle is QA or something? The more |
40 |
you are on the outside, the less you are allowed to touch by policy. As |
41 |
learning process, making the thin line of the Gentoo quizes too access |
42 |
all or nothing more fine-grained and hopefully community controlled? |
43 |
|
44 |
|
45 |
-- |
46 |
Fabian Groffen |
47 |
Gentoo on a different level |