On Wed, Jul 7, 2021 at 9:38 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > 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 ? > There are three major purposes for Changes: 1. Marketing 2. Transparency 3. Coordination Every time a Change gets proposed, we get the benefit of all three. For sure, there are plenty of things that happen in Fedora releases that don't go through this process, but increasingly people are leveraging the benefits of this process to support their work. A huge part of why Fedora is considered an innovative, well-run open source project is because of this. > > 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. > This is often a matter of perspective. I won't go into how much hell I went through last year with my changes in Fedora Linux 33. It worked out in the end because I was patient and actively communicating with everyone, but I can definitely say that was not a fun experience. But it was *important* because the end result is that we have a solid platform. > 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. > It can seem like that at first glance and then turn out to not be so. That was the case with the debuginfod Change[1]. I was not the one that slowed that Change down, in fact I was *very* enthusiastic about it. However, Zbigniew had concerns[1] that led to further development upstream that made a better feature overall for when it was finally approved. [0]: https://fedoraproject.org/wiki/Changes/DebuginfodByDefault [1]: https://pagure.io/fesco/issue/2597#comment-728404 > 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. > We lazy approve after three weeks of no objections from the time it was posted to the list. This is true for both system-wide and self-contained changes. That is not what happened with this change. I objected in the original thread[2], and my concerns were not satisfactorily resolved on-list, so I objected again in the issue[3]. I stated in the meeting discussion[4] that I was okay with being overruled, but I still felt strongly enough about it to object. Nobody brought up any information that would have changed my mind then or convinced everyone else strongly to overrule my objection. Now I learn that folks using Guile integration actually *can* still use their Makefiles in Make-without-Guile with minimal tweaks, so now I don't care, and we would probably approve it if it were proposed again. [2]: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/LSUFO6NOE27YDJBDB2SNUVJGUBWWX3EH/ [3]: https://pagure.io/fesco/issue/2558 [4]: https://meetbot.fedoraproject.org/teams/fesco/fesco.2021-02-03-15.00.log.html -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
