Hi, On 7/7/21 1:53 PM, Neal Gompa wrote: > On Wed, Jul 7, 2021 at 7:38 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: >> >> 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. >> >> 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 ? >> >> I understand there need to be rules and I can understand >> Fesco denying approval for enabling / adding certain >> features for a wide set of reasons, thus in essence blocking >> volunteers from spending time on something because that >> something is deemed undesirable for Fedora. >> >> But this is different here Fesco is telling a group of >> maintainers that they must maintain a feature even though >> they have indicated that they find the benefits of that >> feature not worth the amount of time it costs to maintain >> support for that feature. So in essence Fesco is telling >> the maintainers that they MUST spend time maintaining this >> even though they don't want this. >> >> IMHO this is just outrageous and goes way way beyond the >> purview of Fesco. >> >> 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. So since there >> is no known breakage caused by this, I end up circling back >> to this basically telling Fesco that the make/gdb timers >> MUST spend them on maintaining this even though they >> don't want to (and have good reasons for not wanting to). >> >> Which again, is IHMO pretty outrageous really. >> >> Sorry Fesco, I know that you all do a lot of (hard) work >> as Fesco members and do your best when making decisions >> like this; and I don't doubt that your intentions where >> well, but you made a big booboo here (IMHO). >> >> I urge Fesco to reconsider this and I suggest that we >> (Fedora) take another serious look at implementing: >> https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolchain >> for Fedora 35. >> > > If you want to be outraged at FESCo about this, then read the meeting > log first[1]. > > My main point then is that *all* of the Change authors are upstream > developers in the GNU Toolchain, meaning that they have to do > maintenance effort around Guile support upstream anyway. That is not how upstreams work, I'm an upstream kernel maintainer that does not mean that I'm responsible for every feature which the kernel has. Just become some upstream make maintainers care about guile support enough to keep it alive upstream does not mean that the Fedora toolchain people work on it upstream. Also upstream maintenance != package maintenance. AFAIK having the guile dep in make leads to circular deps causing a whole bunch of work to update to a version which breaks the soname/ABI, as well as causing pain for bootstrapping. IOW even if the feature is 100% ready to go upstream there still is a downstream price to pay for enabling it. > If they want > to remove a feature that makes Fedora the best place to use the GNU > Toolchain, they should do it upstream first. And again you are telling other people what they should do, last time I checked Fesco was supposed to be about policy, not telling other people what they should do. With this same logic the Fedora kernel MUST support every feature which the upstream kernel supports, even features which the Fedora kernel maintainers explicitly do not want to support. Or for that matter every Fedora package MUST support every feature which upstream of that package support. Last time I checked we left such decisions to the package-maintainers. > I did not find their argumentation persuasive because they used > arguments that should be applied upstream and Fedora is not a special > case for any of those. > > I don't personally *care* much about Guile support beyond the fact I > have a few private projects that use it in Makefiles, so it'd be > annoying if it was gone. And I was comfortable with being overruled in > my objections. I stated as much in the meeting even! > > The fact was, the GNU Toolchain developers: > > 1. Did not show up to that FESCo meeting to try to persuade the rest > of the group to vote against me. > 2. Did not consider either alternative I proposed (remove it upstream, > split guile support out in some way) > > It was *barely* rejected by virtue of not reaching a majority vote to > pass. If they want to propose it again, then be my guest. > > [1]: https://meetbot.fedoraproject.org/teams/fesco/fesco.2021-02-03-15.00.log.html Maybe if the GNU Toolchain developers did not show up and there was no majority, then the right thing to do for Fesco would have been to postpone the decision and invite them to join the next meeting to discuss this? That would have been a much better decision then rejecting based on there not being a majority for approving. Actually it seems to me that that would have been the only right thing to do. Rejecting by default when there is no quorum seems like a weird thing to do for Change proposals. In my experience with the change process Fesco does not pro-activily invite Change proposal owners to show up during the meeting where discussing the Change has been put on the agenda, combining not actively inviting them with blaming change owners for not being there as you do above seems weird. Regards, Hans _______________________________________________ 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
