Gentoo Archives: gentoo-dev

From: William Hubbs <williamh@g.o>
To: David Seifert <soap@g.o>
Cc: gentoo-dev@l.g.o, council@g.o, qa@g.o
Subject: Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses
Date: Mon, 23 Mar 2020 19:14:16
Message-Id: 20200323191406.GB4294@linux1.home
In Reply to: Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses by David Seifert
1 On Mon, Mar 23, 2020 at 08:03:47PM +0100, David Seifert wrote:
2 > On Mon, 2020-03-23 at 14:00 -0500, William Hubbs wrote:
3 > > On Mon, Mar 23, 2020 at 07:36:13PM +0100, David Seifert wrote:
4 > > > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
5 > > > > Hey all,
6 > > > >
7 > > > > it has been brought to my attention that there have been several
8 > > > > backward-incompatible changes made to the python eclasses lately.
9 > > > >
10 > > > > It is true that everything in ::gentoo has been fixed along with the
11 > > > > changes to the eclasses; however, when a change like this goes into a
12 > > > > widely used eclass it breaks overlays with little to no notice;
13 > > > > especially since we do not require developers to be subscribed to this
14 > > > > mailing list.
15 > > > >
16 > > > > I do agree that overlay authors are on their own to fix things, but we
17 > > > > need to
18 > > > > find a way to notify them when a breaking change is going into a widely
19 > > > > used eclass and give them time to adjust their ebuilds.
20 > > > >
21 > > > > If the old way of doing things cannot be supported
22 > > > > along side the new way the correct path forward is a new version of the
23 > > > > eclass then a lastrites on the old version. That would give overlay
24 > > > > authors time to switch to the new eclass.
25 > > > >
26 > > > > If the old and new way can be supported in the same code base, a
27 > > > > reasonable way forward is to allow both ways to exist while ::gentoo is
28 > > > > migrated to the new code path then do the equivalent of a lastrites for
29 > > > > the old code path so overlay authors can adjust their ebuilds.
30 > > > >
31 > > > > Thoughts?
32 > > > >
33 > > > > William
34 > > > >
35 > > >
36 > > > All of this was announced with a 3 month timeout, using the right channels.
37 > > > Have
38 > > > you checked all python-related eclasses changes submitted to the ML? In this
39 > > > case, eqawarn would not have been possible, because the change involved
40 > > > dereferencing a variable.
41 > >
42 > > This is the change that broke us today.
43 > >
44 > > https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258
45 > >
46 > > Where is the three month timeout for it?
47 > >
48 > > Thanks,
49 > >
50 > > William
51 > >
52 >
53 > Oh I thought you meant the python-single-r1 change from a month ago.
54
55 The other one that is being pointed out to me is this one:
56
57 https://archives.gentoo.org/gentoo-dev/message/4bf9f0250115c57779f93817356df871
58
59 Is that the python-single-r1 change you were talking about?
60
61 If it is, what do we consider the appropriate channels for api change
62 announcements to be?
63
64 Thanks,
65
66 William

Attachments

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

Replies

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