1 |
On Thu, Feb 25, 2010 at 12:53 PM, Sebastian Pipping <sping@g.o> wrote: |
2 |
> Stop. |
3 |
> |
4 |
> Is introduction of such a high level of bureaucracy really a good idea? |
5 |
> |
6 |
> In my eyes it could backfire and make matters worse as people either |
7 |
> - start ignoring it due to high noise |
8 |
> - reduce people's activity below set permissions |
9 |
> |
10 |
> To summarize presented proposal has a few points that may not work well |
11 |
> with humans. To my understanding we have the assumption in Gentoo that |
12 |
> a Gentoo dev is at least willing to use his brain most of the time. To |
13 |
> me such a machine only makes sense when assuming the opposite(!) |
14 |
|
15 |
You mistake the intent I think. We deploy automation because humans |
16 |
fail; even when they have the best intentions. We make typos, copy |
17 |
and paste errors, accidentally leave whitespace, type commands into |
18 |
the wrong shell, hit the wrong key that kills our session, etc. Smart |
19 |
people avoid work by making a computer do parts that are easily |
20 |
automated; which is why the proposed system is so fine-grained. We |
21 |
can likely add some logic to our current toolset to remind the human |
22 |
that they may have further obligations than just typing repoman commit |
23 |
(like asking on a bug, a mailing list, irc, etc.) With a really |
24 |
simple system; we cannot easily automate when to do what because the |
25 |
criteria are so broad. I agree that a moderately complex system is |
26 |
useless for humans (I'd ignore it straight out) which is why we should |
27 |
write software to do the work for us. I am much more likely to |
28 |
respond to a message from repoman telling me I need to file a bug |
29 |
first as opposed to me looking at metadata.xml every time I commit |
30 |
something. Sure there are people who never read repoman output and |
31 |
commit utter crap to the tree; but I do not really expect 100% success |
32 |
from any system we deploy; I'd be happy with 60% honestly. |
33 |
|
34 |
> |
35 |
> So I would like to propose a much more loose and simple approach: A |
36 |
> distinction |
37 |
> - between major and minor changes |
38 |
> - need for prior interaction or not |
39 |
> |
40 |
> A sensible default may differ from developer to developer. I propose |
41 |
> collecting these defaults somewhere and make it overridable per |
42 |
> maintainer per package in metadata.xml (just as robbat2 did). |
43 |
> |
44 |
> One question to decide would be if access is allowed iff |
45 |
> - no one is objecting or |
46 |
> - everyone is acknowledging |
47 |
> Once all defaults are collected the options are equal, before they are not. |
48 |
> |
49 |
> How to best handle herds is not clear to me in detail, yet. |
50 |
> Anyone seing potential in this minimalistic with a natural extension on |
51 |
> herds in mind? |
52 |
> |
53 |
> |
54 |
> |
55 |
> Sebastian |
56 |
> |
57 |
> |