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

[Markos Chandras]

On Friday 26 February 2010 18:40:47 Alec Warner wrote:
> On Thu, Feb 25, 2010 at 12:53 PM, Sebastian Pipping <sping@g.o>
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
In my eyes, we don't need a smarter repoman to check whether we are supposed 
or not to do a specific commit. What we need are rules ( stricter or not ) 
which DO apply to all developers, and a team ( devrel ) which will be 
responsible to do that. Repoman will not help the situation but it will add a 
new level of complexity into our already complex "communication" system. 
We need an active devrel team which will postpone commit access to those 
developers who are repeatedly fail to behave correctly whatever that means.

That said, i am totally again messing with metadata.xml as long as there 
problem resides in a much higher level
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org