On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote: > Kevin Kofler via devel wrote: > > Still, it gives an extremely bad impression of rushing this through > > without giving anybody the chance to object. > > > > I also do not see why this needed to be approved for F38 on such a short > > notice and could not wait for F39. > > PS: The impression I get is that everything was deliberately rigged so that > the vote would end up the way it did: You're mixing up two things: a vote being "rigged" with a result you don't like. Absolute majority (6 out of 9) of voting members voted in favour. The rules in Fedora are that FESCo gets to vote on certain things. There is a time reserved for public discussion, but at some point a vote is scheduled, and at that point we often discuss things in a meeting and vote one way or another without futher input from outside. It does happen occasionally that repeat votes happen, for example a resolution is approved, but somebody immediately raises some additional concern so it is amended. At that point we don't seek repeat opinions from all stakeholders. Things would take forever, and most stakeholders wouldn't change their opinion anyway for some minor detail. The changes to this Change proposal were not considered major changes that would require a repeat discussion on fedora-devel, but were instead a narrowing and clarification of the proposal, so the vote was held at the earliest convenience. It is important that *FESCo members* know about the vote, which obviously they did in this case because absolute majority did vote. If you were to look at FESCo meeting logs, this happens every once in a while: a proposal is made, it get's a few +1 votes but not enough and is effectively rejected, so a different-but-similar proposal is made and the vote repeats. Sometimes we go through a few of those in one meeting. In this case this was split over two meetings, but is not substantially different. Discussion was ongoing all that time, both publicly and privately, and there is nothing that says that FESCo members must not change their votes based on new information. The intent of this particular proposal is to learn and adjust based on the feedback from the initial implementation. The specific flags on different architectures can and should be adjusted to get the desired result. An interesting phenomenon is that before the Change was approved, most of the feedback on fedora-devel was about whether we need the change at all, and how horrible the performance degradation will be, and what distribution to switch to. After it was approved, the feedback immediately became more technical, with suggestions about specific flags and architecture differences. If we had approved the Change 3 months ago, we would have gotten that useful part of the feedback much earlier. For me the lesson is that we shouldn't dawdle on high-stakes controversial votes, but instead approve ambitious proposals early and have more time to adjust or even revert if it turns out necessary. Zbyszek > 1. A new ticket was filed, in order to exclude the participants of the > previous discussion. > 2. The people watching the old ticket were NOT notified. > 3. The Tools Team was NOT notified. > 4. The proponents of the Change, on the other hand, WERE notified. > > So, with all of the above, the discussion participants were preselected to > only include people in favor of the change. > > 5. The ticket was filed in the middle of the holiday season. Many people in > Europe are on vacation until today. > 6. There was NO thread about the reopening of the discussion on the mailing > list. The first message that mentioned the issue on the mailing list was > "Schedule for Tuesday's FESCo Meeting (2023-01-03)" from 2023-01-03 09:39 > UTC, only 7 hours 21 minutes before the meeting. This is in contrast to the > Change policy requiring at least a week between the mailing list > announcement and opening the FESCo ticket. > 7. Only 4 days had elapsed between the (unannounced) opening of the ticket > and the vote. This is clearly insufficient. The one week in the Change > policy that I cited above is designed as a minimum time for discussion. > 8. The change was approved only 2 weeks before the mass rebuild, leaving > little to no time to revert it in the contigency case. > > So, this ensured that whoever was deliberately NOT invited had no chance to > find out by themselves and intervene before it was too late. > > This strikes me as extremely intransparent and undemocratic. > > Therefore, I hereby request that the vote be annulled as having happened in > violation of the Change policy. > > Kevin Kofler > _______________________________________________ > 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, report it: https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
