rfc: backward-incompatible changes in eclasses

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

rfc: backward-incompatible changes in eclasses

William Hubbs
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


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

Joonas Niilola

On 3/23/20 8:23 PM, William Hubbs wrote:
> 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.
>
>
> Thoughts?
>
Subscribe to this mailing list.

AFAIK all major changes have been posted here and pushed with some delay.

-- juippis



signature.asc (655 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

Aisha Tammy

On 3/23/20 2:27 PM, Joonas Niilola wrote:

> On 3/23/20 8:23 PM, William Hubbs wrote:
>> 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.
>>
>>
>> Thoughts?
>>
> Subscribe to this mailing list.
>
> AFAIK all major changes have been posted here and pushed with some delay.
>
> -- juippis
>
>
Indeed, that's what I'm doing with my popcorn `kernel`s (and also what
most others have advised, even on the irc's).

It's quiet enough to not clutter but useful.


Aisha



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

David Seifert
In reply to this post by William Hubbs
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.

Check the git-2 debacle: 6.5 years of deprecation, and still a bunch of overlays
exploded. There comes a point where you just have to suck it up and move on.


Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

haelwenn (lanodan) Monnier
In reply to this post by Joonas Niilola
[2020-03-23 20:27:51+0200] Joonas Niilola:

> On 3/23/20 8:23 PM, William Hubbs wrote:
> > 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.
> >
> >
> > Thoughts?
> >
> Subscribe to this mailing list.
>
> AFAIK all major changes have been posted here and pushed with some delay.

If this one would be taken it would be nice to have breaking changes
be noted as so in the Subject.

I probably should but for packages in my overlay, I have no idea what
eclasses are used and doesn't have much quality needs if any that
I would read eclass changed to potentially improve the ebuilds in it.

(I do read them for the eclasses that I use in the gentoo & guru repos)

Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

William Hubbs
In reply to this post by David Seifert
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


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

David Seifert
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.


Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

William Hubbs
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?

Thanks,

William


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

Michał Górny-5
In reply to this post by William Hubbs
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.

Does 'several' in this case mean more than one?  Please correct me if
I'm mistaken but the only change I can think of were the changes
in python-single-r1.

> 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.
>
The lesson was learned.  If a similar change would be necessary
in the future, I will bump the eclass instead.  I don't understand why
you bring that today.

--
Best regards,
Michał Górny


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

Michał Górny-5
In reply to this post by William Hubbs
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?
>
This is *not* a breaking API change.  No public API changes, only
a warning message is added.  Private API functions aren't removed
either.

Don't you think it would be more appropriate to do some research or
simply *ask* before spreading FUD?

--
Best regards,
Michał Górny


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

William Hubbs
In reply to this post by Michał Górny-5
On Mon, Mar 23, 2020 at 08:19:20PM +0100, Michał Górny 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.
>
> Does 'several' in this case mean more than one?  Please correct me if
> I'm mistaken but the only change I can think of were the changes
> in python-single-r1.
>
> > 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.
> >
>
> The lesson was learned.  If a similar change would be necessary
> in the future, I will bump the eclass instead.  I don't understand why
> you bring that today.
The change that blew us up today was

https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258

and this is the reason I brought it to the ml.

The previous change that blew us up was

https://archives.gentoo.org/gentoo-dev/message/4bf9f0250115c57779f93817356df871

Thanks,

William


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

Michał Górny-5
On Mon, 2020-03-23 at 14:26 -0500, William Hubbs wrote:

> On Mon, Mar 23, 2020 at 08:19:20PM +0100, Michał Górny 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.
> >
> > Does 'several' in this case mean more than one?  Please correct me if
> > I'm mistaken but the only change I can think of were the changes
> > in python-single-r1.
> >
> > > 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.
> > >
> >
> > The lesson was learned.  If a similar change would be necessary
> > in the future, I will bump the eclass instead.  I don't understand why
> > you bring that today.
>
> The change that blew us up today was
>
> https://archives.gentoo.org/gentoo-dev/message/aa45f4f86f9b865eb0fe7344d83a7258
I'm not sure if you're referring to that specific patch or the whole
thread.  Because I don't see how that patch could break anything.  It's
switching between two methods of getting scriptdir that were added
simultaneously.

> and this is the reason I brought it to the ml.
>
> The previous change that blew us up was
>
> https://archives.gentoo.org/gentoo-dev/message/4bf9f0250115c57779f93817356df871

I don't understand how that could break anything either.  Before
the change, '${PYTHON_USEDEP}' wasn't valid (anymore) in dep strings,
so I don't see how anything could be more broken after the change.
In any case, there could be a little chance it could *fix* some old
ebuilds that just happened to use the right combination.

--
Best regards,
Michał Górny


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

Michał Górny-5
In reply to this post by William Hubbs
William,

So many things are wrong with this e-mail, I'm not even sure where to
start.  In my opinion, this mail shouldn't have ever happened.  While
I believe you had a good intent, this does not justify sending such
mails without verifying your claims first.


On Mon, 2020-03-23 at 13:23 -0500, William Hubbs wrote:
> it has been brought to my attention that there have been several
> backward-incompatible changes made to the python eclasses lately.

The mail starts with an accusation.  While it doesn't name it
explicitly, I think it's pretty clear that all the recent changes
in the eclasses were done by me.  As such, it is an accusation that I've
done *multiple* 'backward-incompatible changes'.  This either implies
that I've deliberately broke something, or that I've been careless,
incompetent.  Either way is bad for me.

Now, as we established there was only one backwards-incompatible change,
not *several*.  Furthermore, FWICS this mail isn't even about that one.
It's about changes that were fully backwards compatible and under normal
circumstances couldn't have broken any overlays.

Don't you think that if someone is going to publicly make such
an accusation, the absolutely minimal thing to do would be to verify it?
As I'm pretty sure you're aware, I'm available practically every day
and it would be sufficient to *ask* to make it clear what the problem
is.  However, in this case it seems that the accusation was built on top
of misunderstood rumors coming from a third party, that were turned into
public mailing list discussion without any kind of verification.

Of course, you could say that the matter could be corrected in reply to
this mail.  However, this does not change the fact that it is entirely
possible that someone will make an opinion about my actions without
verifying your claims or skimming replies to the thread to see that they
are entirely unfounded.  In other words, this mail is slanderous.

> 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;

Just to be clear, the only reason that 'overlays' were broken is that
the overlay in question was forking one of the python eclasses without
forking the others.  As a result, the change in *internal* eclass API
has caused a missync between eclasses effectively used by the overlay
in question.

More specifically, the overlay in question was forking python-utils-r1.
When new function (_python_export) was introduced in it, the forked
eclass did not provide it and other eclasses failed to call it.

I'm not aware of any clean way of introducing new internal functions
that won't break this case.  I don't believe it makes sense to expect
developers to cope with that.  Moreover, I think it is entirely unfair
to complain that I haven't predicted that someone could be doing this.

> especially since we do not require developers to be subscribed to this
> mailing list.

From 20140408 Council meeting summary:

| * While it is any developer's choice not to participate on the gentoo-
| dev and gentoo-project mailing lists, they nevertheless serve as main
| communication  channels. If something has been discussed there,
| and then action has been taken, the council regards ignorance
| of the discussion not as a good foundation for protests against
| the actions.  [1]

The remaining part of the mail is written with the assumption that
a breaking change has occurred, so I'm going to skip it.

Finally, I don't understand why Council is CC-ed to the mail.  Since
I haven't been approached with any problem, I don't think there is any
reason to request Council intervention here.


[1] https://projects.gentoo.org/council/meeting-logs/20140408-summary.txt

--
Best regards,
Michał Górny


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

William Hubbs
On Wed, Mar 25, 2020 at 10:29:23AM +0100, Michał Górny wrote:
> William,
>
> So many things are wrong with this e-mail, I'm not even sure where to
> start.  In my opinion, this mail shouldn't have ever happened.  While
> I believe you had a good intent, this does not justify sending such
> mails without verifying your claims first.

I apologize for being vague in my initial email about what
my claims were. It would have been better to link the changes up front
instead of later in the thread and give more information about what was
broken, and I will do this next time around.

Also, I do agree that cc'ing QA and the council was overkill for an
rfc message.

I hope we can move on from this thread. Let me know what you think.

From my pov, the incident that prompted this highlights some concerns about
our eclass patch handling process, so expect a separate thread from me
soon about this process.

Thanks,

William


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: rfc: backward-incompatible changes in eclasses

Kent Fredric-2
In reply to this post by Joonas Niilola
On Mon, 23 Mar 2020 20:27:51 +0200
Joonas Niilola <[hidden email]> wrote:

> AFAIK all major changes have been posted here and pushed with some delay.

In my experience, "Some delay" is usually short, as developers making
the change are eager to push it through.

But the people maintaining the overlays are much more likely to have a
bigger expectation of what that "delay" should be, because many of them
don't have the time to read -dev every day, and they have other things
to do than rework their overlay with regards to patches on ::gentoo.

So what's more likely to happen is the breakage isn't noticed till
users are affected and complaining, and that's not ideal.

( Though at the end of the day, this problem ends up being a "not
enough devs to man the pumps", I have stuff I've let rot because I've
got too many things to do, and nobody really is taking up the slack )

attachment0 (849 bytes) Download Attachment