On Wed, Jul 07, 2021 at 03:09:47PM +0200, Hans de Goede wrote: > Hi, > > On 7/7/21 2:14 PM, Florian Weimer wrote: > > * 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 > > Yes that was less then ideal OTOH since there was no majority to > either reject or accept it would have been better IMHO for Fesco > to simply postpone the decision and explicitly invite you for the > next meeting. I wonder if the process we're following (as it is defined today) is actually beneficial for self-contained changes ? Did having a vote which rejected the change actually improve Fedora, or was it just busy work that is better eliminated in the common/simple case ? The announcement of the change on this list resulted in minimal discussion and no show stopper objections. The points raised in the FESCo meeting could have just been discussion in the change announcement email thread. Did we actually need an interactive meeting for it at a specific time where only a tiny set of people are actually present to participate ? Any time there is a voting process, people are divided into winners/loosers. Even if the vote rejects something through a technicality, that can easily leave a negative impression. In most communities I work in, the need to apply something as formal as voting would be considered a failure. Agreement should be achieved through discussion, so we don't formally divide people. Voting a last resort only when discussion fails to come to acceptable consensus. None the less I can see value in formal FESCo approval for system-wide changes that have a broad impact across the distro. In that area FESCo is not so much acting as a gate keeper, but rather as the designated leadership for the project's overall technical vision/direction. I'm far less convinced FESCo formally voting is beneficial for (uncontroversial) self-contained changes, where the goal of the maintainer is largely just to make sure people have awareness of what's coming down the pipe. Is there scope for having self-contained changes implicitly approved 2 weeks after being posted to Fedora devel list in absence of controversy ? In that 2 week period, if someone raises an objection that does not get a satisfactorily resolved through discussion, they could raise an explicit request for a FESCo vote on the change as a last resort. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
