[MPlayer-dev-eng] uau - svn account removal

[Michael Niedermayer]

Hi

On Sat, Feb 24, 2007 at 02:50:27PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Saturday, 24 February 2007 at 14:18, Reimar Döffinger wrote:
> > Hello,
> > On Sat, Feb 24, 2007 at 01:45:40PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> > > On Saturday, 24 February 2007 at 13:07, Attila Kinali wrote:
> > > > We, ie root at mphq, were asked to remove uau's svn account
> > > > for serious breaking of the svn commit policy. Even by someone
> > > > i place large trust in.
> > > > 
> > > > Thus, i would like to ask the MPlayer developers (excluding
> > > > uau in this case) to vote whether uau's account should be
> > > > removed or not.
> > > 
> > > The one asking for this should step up and reveal his reasons. Or is he
> > > a coward? I don't like such underhanded tactics.
> > 
> > I object to the use of the term "coward". Completely ignoring that the
> > reasons here were completely different, Some things may or may not be
> > suitable to be discussed in the public.
> 
> True. But no such reasons exist in this case.
> 
> > We do not hold public discussion about whom to grant SVN access
> > on the mailing lists either.
> 
> I seem to remember a couple of nominations being discussed.
> 
> > No matter how much you personally feel something should be discussed
> > publicly, this is something that others can easily and with good reasons
> > have a different opinion.
> > So I please request things being made public without using terms like
> > "coward" or "underhanded".
> 
> My point was (and Michael confirmed it) about going behind people's backs
> to have their account removed. And that's what Michael was trying to do. He
> didn't write (for example, in a reply in -cvslog) that he'd propose to
> suspend Uoti's write access if Uoti didn't start behaving. No, he mailed
> root at mphq directly, saying he didn't want to risk being ignored. That's
> what I call underhanded. So I apologize for suspecting Michael of cowardice,
> but I stand by my other statement.

i did not want uaus account to be disabled for all eternity, i wanted it to
be closed/suspended, he continued to commit code over the changes even though
he was asked not to and he was asked to reverse things which he also ignored

IMHO suspending his account at that point would have been appropriate to
reduce the amount of work needed to clean this up

this was how arpi handled it and it worked very well, uau has ignored
everyones complaints, i doubt he would have stoped after a warning from
me to _ask_ root to close his account its not as if me asking would
lead to his account being closed immedeatly

my intent was and is to minimize the mess and suspending his account after
he ignored everyone repeatly seemed and seems more effective then asking
again and again and hoping

also it could create a big mess if there are absolutely no consequences
for breaking policy like uau did, anyone minds if i do that too? if
everyone does that?
if you agree here then you should understand why i was affraid of root
ignoring me, violating policy vs. violating policy and root approving it
against the developers oppinion

also

develA: breaks a rule
develB: develA hey what did you do reverse this!
develC: develA yes seconded revert it
develA: breaks next rule
develB: develA stop and REVERT IT!!!!!
develD: develA yes and stop commitng over these until we have disscussed this
develA: commits over the changes
develA: commits more over the changes

so what should we do now, dont you think that suspending develAs account
first and then disscussing the next steps would be best?

[...]
-- 
The underhander GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070224/8df86aed/attachment.pgp>