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.  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.  https://projects.gentoo.org/council/meeting-logs/20140408-summary.txt -- Best regards, Michał Górny
Description: This is a digitally signed message part