Peter Boy <pboy(a)uni-bremen.de> via
lists.fedoraproject.org:
We now have the problem of preserving our users from harm
unfortunately done intentionally or, at best, negligently by some of our own members who
are owners of the Change Proposal. Unfortunately, the perpetrators do now not care how
harm can be averted from our users with Release 37 and do not even bother to attend the
meeting on this topic to find a suitable resolution if the issue.
This is inappropriate. And I don't accept that this is some sort of
language barrier issue either because of the consistently inflammatory
language you regularly use. You're as capable as anyone to do a Google
translate and figure out that the only purpose for using words like
this is to be escalatory and attention seeking. If you want to solve
problems, maybe ask questions instead of using emotionally charged
words.
schaden=harm, vorsätzlich=intentionally, fahrlässige=negligently,
Täter=perpetrator, culprit, offender.
I am a listed change owner, and I was present for the meeting on the
topic, the minutes show this. Therefore it is incorrect to say the
feature owners didn't show up, let alone with language as if this is
some cavalier no show. The conversation about the feature proposal
happens on the devel@ list. That's where changes appear and critical
discussion is supposed to happen. If you expressly want certain people
to show up at your meeting, you need to extend them an invitation and
see what times work for them. It's not like most people have the
ability to just drop what they're doing to attend a SIG's meeting
without knowing their attendance is needed well in advance.
At the meeting, there really was no discussion about finding a
resolution, but rather how to go about blocking the feature. I
mentioned there is no release criterion to justify blocking the
feature, but the discussion moved on without addressing that, or how
the server working group could go about making "bootable degraded
RAID" setups a release requirement. Right now there's nothing in the
server working group documents or historical discussions with Fedora
QA about this being a product or release requirement.
Necessarily there need to be developers available to make sure such
functionality continues to work, because it's untenable to
indefinitely delay release or features. Both the bootloader and
Anaconda teams should be approached, probably on devel@, to see if
there's interest and resources available. Possibly also get some
assessment of CoreOS/bootupd for timeframe and momentum both within
and outside of CoreOS development, because this is a generic problem
that needs a generic solution, including on UEFI where it also doesn't
work out of the box without some kind of firmware RAID enablement. Is
that really the best we can do in the near term? If so then that
becomes the requirement: firmware RAID. I don't like such a
limitation, but at least it's a clear requirement that sets
expectations for users and testing.
--
Chris Murphy