On Wed, 7 Jul 2021 at 08:54, Hans de Goede <hdegoede(a)redhat.com> wrote:
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.
I believe there is an 'unspoken' expectation that if you propose a
change, you are responsible for that change and go to various FESCO
meetings until the change is acted on. I don't like
'unspoken/unwritten' expectations but I am guessing it has worked for
FESCO because it is rare when I have sat in on Change Requests that
the people proposing things aren't there. It would be better if
A) Expectations and responsibilities of change owners were written out.
B) Powers of FESCO to tell or not tell people what they are to work on
were written out.
C) This proposal was reviewed and pushed again for F35 even if it is
'too late' because well this just doesn't sit well.
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on BBS...
time to reboot.