* Hans de Goede:
Hi,
On 7/7/21 1:08 PM, Florian Weimer wrote:
> * Neal Gompa:
>
>> Wait, why don't we have guile 3.0?
>
> We have a mandate from Fesco that the core toolchain must depend on
> Guile. Naturally that makes updates rather difficult.
So I've gone and checked the Fesco issue where dropping guile
support from make + gdb was discussed:
https://pagure.io/fesco/issue/2558
And I must say that I find the argumentation for rejecting the
change very very weak. I would really expect Fesco to make better
motivated decisions then this one.
I'm especially shocked about how Fesco is in essence mandating
a group of maintainers to spend time maintaining a feature
where they clearly have indicated they don't want to maintain
that feature.
I guess this is partly on us (on the toolchain side). We missed the
meeting, and no one pointed out that the make change in particular meant
that instead of writing $(guile …), the user arguing for this feature
would have to write $(shell guile …). The make/Guile integration is
simply not very deep. It's not that you can rewrite recipes, have
access to the dependency engine, or anything like that.
(There is deeper integration for GDB, but no one seemed to be concerned
about that for some reason.)
My being shocked here is not so much about the guile issue,
but about a IMHO much bigger issue underlying this decision:
Since when does Fesco get to mandate on which features our
volunteer maintainers get to spend there time ?
Most of us Fedora toolchain maintainers aren't volunteers in the actual
sense of the word, so we shouldn't play the volunteer card (and Fesco
probably knew this too). I know that several members of the Red Hat
Platform Tools team (who maintain the toolchain downstream) have Fedora
work as goals or key responsibilities.
We removed Guile from the downstream toolchain, and we wanted to
upstream this change, and that didn't work out. As far as I know, this
did not have any consequence how Fedora work on the affected components
is treated by the relevant maintainers' managers. (They didn't turn
volunteers over night.)
I think that in general, if community requirements diverge this way, we
just consider it the cost of doing business. Clearly there is no
tangible return on investment for this kind of work, it's just something
that has to be done, given how the productization work for Red Hat
Enterprise Linux is structured. In this particular instance, the cost
isn't particularly high, so we moved on.
Obviously I disagree with Fesco's decision, but I don't think it matters
that much in the grand scheme of things.
Now if dropping this feature would cause major breakage this
would a different story, But in the whole discussion about
this, at least as documented in the Fesco issue, no actual
users of this feature have been indentified and nothing will
break by disabling this as far is is known.
One user showed up in the Fesco meeting, and because we weren't there,
that was enough to block the change. I don't have a link to the IRC
minutes right now, but I remember reviewing them after the fact.
Thanks,
Florian