Re: [gentoo-dev] metadata.xml: <changepolicies>

[Alec Warner <antarus@gentoo.org>]

On Thu, Feb 25, 2010 at 12:53 PM, Sebastian Pipping <sping@gentoo.org> wrote:
> Stop.
>
> Is introduction of such a high level of bureaucracy really a good idea?
>
> In my eyes it could backfire and make matters worse as people either
> - start ignoring it due to high noise
> - reduce people's activity below set permissions
>
> To summarize presented proposal has a few points that may not work well
> with humans.  To my understanding we have the assumption in Gentoo that
> a Gentoo dev is at least willing to use his brain most of the time.  To
> me such a machine only makes sense when assuming the opposite(!)

You mistake the intent I think.  We deploy automation because humans
fail; even when they have the best intentions.  We make typos, copy
and paste errors, accidentally leave whitespace, type commands into
the wrong shell, hit the wrong key that kills our session, etc.  Smart
people avoid work by making a computer do parts that are easily
automated; which is why the proposed system is so fine-grained.  We
can likely add some logic to our current toolset to remind the human
that they may have further obligations than just typing repoman commit
(like asking on a bug, a mailing list, irc, etc.)  With a really
simple system; we cannot easily automate when to do what because the
criteria are so broad.  I agree that a moderately complex system is
useless for humans (I'd ignore it straight out) which is why we should
write software to do the work for us.  I am much more likely to
respond to a message from repoman telling me I need to file a bug
first as opposed to me looking at metadata.xml every time I commit
something.  Sure there are people who never read repoman output and
commit utter crap to the tree; but I do not really expect 100% success
from any system we deploy; I'd be happy with 60% honestly.

>
> So I would like to propose a much more loose and simple approach: A
> distinction
> - between major and minor changes
> - need for prior interaction or not
>
> A sensible default may differ from developer to developer.  I propose
> collecting these defaults somewhere and make it overridable per
> maintainer per package in metadata.xml (just as robbat2 did).
>
> One question to decide would be if access is allowed iff
> - no one is objecting or
> - everyone is acknowledging
> Once all defaults are collected the options are equal, before they are not.
>
> How to best handle herds is not clear to me in detail, yet.
> Anyone seing potential in this minimalistic with a natural extension on
> herds in mind?
>
>
>
> Sebastian
>
>