Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o, David Seifert <soap@g.o>
Cc: council@g.o, qa@g.o
Subject: Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
Date: Mon, 23 Mar 2020 19:22:33
Message-Id: 1ae2728f8c7edd2da33e6b44fb9ad803a9c479a7.camel@gentoo.org
In Reply to: Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses by William Hubbs
1 On Mon, 2020-03-23 at 14:00 -0500, William Hubbs wrote:
2 > On Mon, Mar 23, 2020 at 07:36:13PM +0100, David Seifert wrote:
3 > > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
4 > > > Hey all,
5 > > >
6 > > > it has been brought to my attention that there have been several
7 > > > backward-incompatible changes made to the python eclasses lately.
8 > > >
9 > > > It is true that everything in ::gentoo has been fixed along with the
10 > > > changes to the eclasses; however, when a change like this goes into a
11 > > > widely used eclass it breaks overlays with little to no notice;
12 > > > especially since we do not require developers to be subscribed to this
13 > > > mailing list.
14 > > >
15 > > > I do agree that overlay authors are on their own to fix things, but we need to
16 > > > find a way to notify them when a breaking change is going into a widely
17 > > > used eclass and give them time to adjust their ebuilds.
18 > > >
19 > > > If the old way of doing things cannot be supported
20 > > > along side the new way the correct path forward is a new version of the
21 > > > eclass then a lastrites on the old version. That would give overlay
22 > > > authors time to switch to the new eclass.
23 > > >
24 > > > If the old and new way can be supported in the same code base, a
25 > > > reasonable way forward is to allow both ways to exist while ::gentoo is
26 > > > migrated to the new code path then do the equivalent of a lastrites for
27 > > > the old code path so overlay authors can adjust their ebuilds.
28 > > >
29 > > > Thoughts?
30 > > >
31 > > > William
32 > > >
33 > >
34 > > All of this was announced with a 3 month timeout, using the right channels. Have
35 > > you checked all python-related eclasses changes submitted to the ML? In this
36 > > case, eqawarn would not have been possible, because the change involved
37 > > dereferencing a variable.
38 >
39 > This is the change that broke us today.
40 >
41 > https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258
42 >
43 > Where is the three month timeout for it?
44 >
45
46 This is *not* a breaking API change. No public API changes, only
47 a warning message is added. Private API functions aren't removed
48 either.
49
50 Don't you think it would be more appropriate to do some research or
51 simply *ask* before spreading FUD?
52
53 --
54 Best regards,
55 Michał Górny

Attachments

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