On Fri, Jun 3, 2022 at 7:37 PM Emmanuel Seyman <emmanuel(a)seyman.fr> wrote:
Yes, the discussion in the last meeting quickly turned to the topic
of
blocking the Change. After you've tried to find a resolution, being
mostly ignored by the Change owners and the Change has been approved
by FESCO, I'm not sure what else one can reasonably expect.
I'll take note of the fact that it took the threat of blocking the
Change to get the owners to engage in the conversation we should
have started having 2 or 3 weeks ago, which is really not the way
I think we should handle Change proposals.
May 14: the GPT on BIOS by default proposal appears on devel@ list
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
May 26: FESCo reaches 3 votes in favor of the feature with no
descents, this qualifies the feature to be fast tracked and approved.
May 29: Peter Boy responds to the GPT on BIOS devel@ thread (mentioned
above) saying Server WG insists the proposal be deferred.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
May 29: I respond to Peter's email on devel@
So I agree that the way to handle change proposals that you have
concerns. I propose that as soon as you had concerns, it should have
been raised in the FESCo ticket itself, but having raised it on devel@
would have been adequate, because all FESCo members monitor change
proposal threads very strictly.
https://pagure.io/fesco/issue/2797
I don't see any other complaints about the feature in the devel@
thread. It's not adequate to complain about the feature in either
working group or SIG meetings, those complaints need to go in either
the feature's devel@ thread or they need to be presented to FESCo in a
ticket, typically the FESCo ticket for the feature.
If Server SIG folks feel ignored, well that's probably true, but it
would seem the bulk of the questions and complaints happened somewhere
else than the devel@ thread, which isn't the correct procedure.
--
Chris Murphy