Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Samuli Suominen <ssuominen@gentoo.org>]

On 07/04/14 11:26, Patrick Lauer wrote:
> On Monday 07 April 2014 11:02:44 Samuli Suominen wrote:
>
>>>> at least as safe kludge to avoid disrespect like this:
>>> I wonder if you noticed that I've been a dev since 2004 ...
>>>
>>> and disrespect, well, you actively work towards breaking things.
>>>
>>> Even when told, multiple times, that you're breaking things,
>>>
>>> And that we will revert breakage when detected ...
>> What you told was you will impose your personal opinions as policies,
>> and you will use the
>> QA team membership as a cover to enforce it upon others.
> I don't even know what words I could use to change your mind.

You can get me to change mind by writing up a policy that says
dynamic deps can't be relied upon, and getting rest of the QA
team, perhaps council, on board with it.

#gentoo-qa, yesterday:

17:50 < floppym> Hmm... documenting when to revbump in relationship to
RDEPEND is not a bad idea. However, I think the rules would
be a little more subtle than "always". We would also need some way of
dealing with eclasses which generate
RDEPEND, and also with revbumping stable ebuilds.


>
> The only way I see right now to avoid you breaking stuff is removing your 
> commit rights, because you actively do not show signs of common sense or an 
> ability to learn.

Likewise, while dynamic deps are the default, and I, as a binary package
user, are aware of the pitfall, I can't understand
your line of thinking process at all.
Read above, get the policy estabilished, and people, including me, will
follow it.
Meanwhile it's plain rude to bother me with this, since it's nothing
more than your own opinion, and I'm allowed to
disagree with it.
Meanwhile it's plain rude to users of non-binary packages to force
useless rebuilds upon, I'm tempted to leverage
it with an 'DoS', but that would go a bit too far.

>  
>> Instead of actually working towards getting it written down somewhere,
>> making it official,
>> so there is something for you to reference, and something for others to
>> follow.
> Policy suggestion:
>
> "Don't break no shit. If you do, fix it. If you don't someone else will, and 
> you don't whine at them because you be not doing a good job."
>
> ... do we really need to write that down? Explicitly, in a few ten thousand 
> words to reduce ambiguity? 

I read this as flamebait, not worth replying.

>> This is why the last team died, and now you are repeating the mistake.
> No, last team got torn apart by the "Do something ... Noooo! NOT THAT OMG WTF"
>
> That stress made it basically impossible to get anything done, and the ensuing 
> frustration soured the interpersonal reason until QA was mostly passive and 
> angry.

This wasn't the case at all, we had no issues within the team before one
particular disagreement where an QA member tried to force others, including
other QA members, to act upon his personal view on things without an proper
written down policy.
Now that it's written down, and the tools have been updated accordingly,
we have no issues at all. It's what should have happened as a first step.

>
> I just don't care about the whining and continue my anti-breakage crusade. And 
> so far there's only been about three people that got upset about masking 
> broken stuff. The easiest way to get me to ignore you is to not cause any 
> trouble, where trouble means "things not working". 
>
> I'm busy enough with repoman-visible breakage, so don't expect me to be in a 
> good mood if you actively cause more breakage: Current average is about 2-3 
> new bugs I have to file every single day (mostly because no one else seems to 
> have enough motivation)
>
> Again, as stated on IRC: This is not personal. It's just that some of us have 
> basic expectations of things working, so it's in your best interest not to 
> violate these basic ideas. Make it personal and it will be personal, which I'm 
> not really in the mood for ... such a waste of time that could be used for 
> much more interesting things. 
>

This is not personal. This is merely what's the right way to move
forward to avoid
mistakes from the past.
Yes, this is an huge waste of everyones time. Just use the normal ways
of getting things,
like policies, guidelines, changed and we don't have to continue with
this at all.

- Samuli