On Mon, 21 Oct 2013 15:32:10 +0200
Jeroen Roovers <j...@gentoo.org> wrote:

> On Sun, 20 Oct 2013 12:41:02 +0100
> Markos Chandras <hwoar...@gentoo.org> wrote:
> 
> > No I never meant broken depgraphs. Well for broken deps, repoman
> > does not let you commit. If you use --force to workaround broken
> > deps, well, then you get what you deserve.
> 
> No, apparently tomwij can get not only away with this (and apparently
> others as well on a regular basis). Not just that: he gets to write a
> lengthy "apology" that merely blames others / documentation / common
> sense, and then proceeds to call me "unprofessional" for pointing out
> in public the several mistakes he made. I feel very much that he's not
> getting it (what he deserves).

This is a first time I mask an USE flag on a package for a very small
single issue, please do not get upset over it. If I do it perfectly on
other achitectures which do not point anything out about it; then there
must be a reason as to why this happened *, please assume good faith
and do not see my explanation as a way to blame people or words. You or
your comment is not the reason to it, rather my misinterpretation of it.

My replies are rather intended to make sure "apparently others" do not
experience this again in the future; by introducing consistency,
deciding on policy, clarifying documentation and so on...

It simply does not work to say to me that "you're supposed to" when
that doesn't reflect what other arches do as well as the docs; I have
learned early on to not be convinced by inviduals, but rather to base
myself on consensus as to avoid people telling me conflicted matters.

To some extent I might be trying to be too professional; but, I'm
rather scared of not being professional enough, so I try not to be
careless when checking whether there is a consensus on matters.

You very well know that this is not intended, that I apologize and that
I will not let it happen again; so, the only thing left I ask from
Gentoo and you is to bring more consistency in this matter so all of us
do not have to go through this again.

If there's no consistency, no policy for the HPPA exception and missing
documentation; then ask yourself, what alerts and/or prevents the next
new developer from making this mistake again once he gets to USE flag
dependencies that need to be masked?

Nothing, and that concerns me.

As for blaming you; it is quite the opposite, I have actually been
trying to become friends with you because we share some common concerns
(bug wrangling, keeping #gentoo clean, ...) but I find it much harder
to do that these days running into these roadblocks ("atrocity" when
making a mistake because of an unexpected comment, changing the patch
name in tinyproxy, getting away and getting what I deserve, ...) that
are the result of us not communicating in a professional way.

I very well respect your position as an arch member, your concerns to
keep maintaining the arch easy and more; I'm not bothered by you, even
rather admire some of the work you do.

I do speak up to improve our maintenance to be more efficient, to
improve Gentoo and to increase the general user experience; then if
problems or complexity sits in the way of that, I want to
explain, discuss and improve it. When that is reasonably possible.

Please note that I however do not insist on it; if nobody's interested,
then I am okay with that. What I didn't get here is why that comment is
in place in the HPPA package.use.mask; my confusion on this should be
clear from the other reply I gave on your example.

I'm not at all here to convince you; rather, I'm here to try to
understand its meaning. If you do not want to clarify that or provide
facts or references; then I agree to disagree with your opinion for
adding that comment. Regardless of that, the mistake won't happen again.

Thank you for the great work, your understanding and have a nice day.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Attachment: signature.asc
Description: PGP signature

Reply via email to