Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

[Michał Górny]

William,

So many things are wrong with this e-mail, I'm not even sure where to
start.  In my opinion, this mail shouldn't have ever happened.  While
I believe you had a good intent, this does not justify sending such
mails without verifying your claims first.


On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
> it has been brought to my attention that there have been several
> backward-incompatible changes made to the python eclasses lately.

The mail starts with an accusation.  While it doesn't name it
explicitly, I think it's pretty clear that all the recent changes
in the eclasses were done by me.  As such, it is an accusation that I've
done *multiple* 'backward-incompatible changes'.  This either implies
that I've deliberately broke something, or that I've been careless,
incompetent.  Either way is bad for me.

Now, as we established there was only one backwards-incompatible change,
not *several*.  Furthermore, FWICS this mail isn't even about that one. 
It's about changes that were fully backwards compatible and under normal
circumstances couldn't have broken any overlays.

Don't you think that if someone is going to publicly make such
an accusation, the absolutely minimal thing to do would be to verify it?
As I'm pretty sure you're aware, I'm available practically every day
and it would be sufficient to *ask* to make it clear what the problem
is.  However, in this case it seems that the accusation was built on top
of misunderstood rumors coming from a third party, that were turned into
public mailing list discussion without any kind of verification.

Of course, you could say that the matter could be corrected in reply to
this mail.  However, this does not change the fact that it is entirely
possible that someone will make an opinion about my actions without
verifying your claims or skimming replies to the thread to see that they
are entirely unfounded.  In other words, this mail is slanderous.

> It is true that everything in ::gentoo has been fixed along with the
> changes to the eclasses; however, when a change like this goes into a
> widely used eclass it breaks overlays with little to no notice;

Just to be clear, the only reason that 'overlays' were broken is that
the overlay in question was forking one of the python eclasses without
forking the others.  As a result, the change in *internal* eclass API
has caused a missync between eclasses effectively used by the overlay
in question.

More specifically, the overlay in question was forking python-utils-r1. 
When new function (_python_export) was introduced in it, the forked
eclass did not provide it and other eclasses failed to call it.

I'm not aware of any clean way of introducing new internal functions
that won't break this case.  I don't believe it makes sense to expect
developers to cope with that.  Moreover, I think it is entirely unfair
to complain that I haven't predicted that someone could be doing this.

> especially since we do not require developers to be subscribed to this
> mailing list.

From 20140408 Council meeting summary:

| * While it is any developer's choice not to participate on the gentoo-
| dev and gentoo-project mailing lists, they nevertheless serve as main
| communication  channels. If something has been discussed there,
| and then action has been taken, the council regards ignorance
| of the discussion not as a good foundation for protests against
| the actions.  [1]

The remaining part of the mail is written with the assumption that
a breaking change has occurred, so I'm going to skip it.

Finally, I don't understand why Council is CC-ed to the mail.  Since
I haven't been approached with any problem, I don't think there is any
reason to request Council intervention here.


[1] https://projects.gentoo.org/council/meeting-logs/20140408-summary.txt

-- 
Best regards,
Michał Górny