Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: council@g.o, qa@g.o
Subject: Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
Date: Wed, 25 Mar 2020 09:29:36
In Reply to: [gentoo-dev] rfc: backward-incompatible changes in eclasses by William Hubbs
1 William,
3 So many things are wrong with this e-mail, I'm not even sure where to
4 start. In my opinion, this mail shouldn't have ever happened. While
5 I believe you had a good intent, this does not justify sending such
6 mails without verifying your claims first.
9 On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
10 > it has been brought to my attention that there have been several
11 > backward-incompatible changes made to the python eclasses lately.
13 The mail starts with an accusation. While it doesn't name it
14 explicitly, I think it's pretty clear that all the recent changes
15 in the eclasses were done by me. As such, it is an accusation that I've
16 done *multiple* 'backward-incompatible changes'. This either implies
17 that I've deliberately broke something, or that I've been careless,
18 incompetent. Either way is bad for me.
20 Now, as we established there was only one backwards-incompatible change,
21 not *several*. Furthermore, FWICS this mail isn't even about that one.
22 It's about changes that were fully backwards compatible and under normal
23 circumstances couldn't have broken any overlays.
25 Don't you think that if someone is going to publicly make such
26 an accusation, the absolutely minimal thing to do would be to verify it?
27 As I'm pretty sure you're aware, I'm available practically every day
28 and it would be sufficient to *ask* to make it clear what the problem
29 is. However, in this case it seems that the accusation was built on top
30 of misunderstood rumors coming from a third party, that were turned into
31 public mailing list discussion without any kind of verification.
33 Of course, you could say that the matter could be corrected in reply to
34 this mail. However, this does not change the fact that it is entirely
35 possible that someone will make an opinion about my actions without
36 verifying your claims or skimming replies to the thread to see that they
37 are entirely unfounded. In other words, this mail is slanderous.
39 > It is true that everything in ::gentoo has been fixed along with the
40 > changes to the eclasses; however, when a change like this goes into a
41 > widely used eclass it breaks overlays with little to no notice;
43 Just to be clear, the only reason that 'overlays' were broken is that
44 the overlay in question was forking one of the python eclasses without
45 forking the others. As a result, the change in *internal* eclass API
46 has caused a missync between eclasses effectively used by the overlay
47 in question.
49 More specifically, the overlay in question was forking python-utils-r1.
50 When new function (_python_export) was introduced in it, the forked
51 eclass did not provide it and other eclasses failed to call it.
53 I'm not aware of any clean way of introducing new internal functions
54 that won't break this case. I don't believe it makes sense to expect
55 developers to cope with that. Moreover, I think it is entirely unfair
56 to complain that I haven't predicted that someone could be doing this.
58 > especially since we do not require developers to be subscribed to this
59 > mailing list.
61 From 20140408 Council meeting summary:
63 | * While it is any developer's choice not to participate on the gentoo-
64 | dev and gentoo-project mailing lists, they nevertheless serve as main
65 | communication channels. If something has been discussed there,
66 | and then action has been taken, the council regards ignorance
67 | of the discussion not as a good foundation for protests against
68 | the actions. [1]
70 The remaining part of the mail is written with the assumption that
71 a breaking change has occurred, so I'm going to skip it.
73 Finally, I don't understand why Council is CC-ed to the mail. Since
74 I haven't been approached with any problem, I don't think there is any
75 reason to request Council intervention here.
78 [1]
80 --
81 Best regards,
82 Michał Górny


File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses William Hubbs <williamh@g.o>