Re: [gentoo-dev] rfc: backward-incompatible changes in eclasses

[William Hubbs]

On Mon, Mar 23, 2020 at 02:14:06PM -0500, William Hubbs wrote:
> On Mon, Mar 23, 2020 at 08:03:47PM +0100, David Seifert wrote:
> > On Mon, 2020-03-23 at 14:00 -0500, William Hubbs wrote:
> > > On Mon, Mar 23, 2020 at 07:36:13PM +0100, David Seifert wrote:
> > > > On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
> > > > > Hey all,
> > > > >
> > > > > it has been brought to my attention that there have been several
> > > > > backward-incompatible changes made to the python eclasses lately.
> > > > >
> > > > > 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;
> > > > > especially since we do not require developers to be subscribed to this
> > > > > mailing list.
> > > > >
> > > > > I do agree that overlay authors are on their own to fix things, but we
> > > > > need to
> > > > > find a way to notify them when a breaking change is going into a widely
> > > > > used eclass and give them time to adjust their ebuilds.
> > > > >
> > > > > If the old way of doing things cannot be supported
> > > > > along side the new way the correct path forward is a new version of the
> > > > > eclass then a lastrites on the old version. That would give overlay
> > > > > authors time to switch to the new eclass.
> > > > >
> > > > > If the old and new way can be supported in the same code base, a
> > > > > reasonable way forward is to  allow both ways to exist while ::gentoo is
> > > > > migrated to the new code path then do the equivalent of a lastrites for
> > > > > the old code path so overlay authors can adjust their ebuilds.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > William
> > > > >
> > > >
> > > > All of this was announced with a 3 month timeout, using the right channels.
> > > > Have
> > > > you checked all python-related eclasses changes submitted to the ML? In this
> > > > case, eqawarn would not have been possible, because the change involved
> > > > dereferencing a variable.
> > >
> > > This is the change that broke us today.
> > >
> > > https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258
> > >
> > > Where is the three month timeout for it?
> > >
> > > Thanks,
> > >
> > > William
> > >
> >
> > Oh I thought you meant the python-single-r1 change from a month ago.
>
> The other one that is being pointed out to me is this one:
>
> https://archives.gentoo.org/gentoo-dev/message/4bf9f0250115c57779f93817356df871
>
> Is that the python-single-r1 change you were talking about?
>
> If it is, what do we consider the appropriate channels for api change
> announcements to be?

Sorry about sending too quickly on this message.

We have mostly fixed this one by now.

Thanks,

William