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 |