* 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
