Jan Kurik wrote:
This is going to follow the Change process, so if at certain point
in
time the Change will not be ready it will go to FESCo to review the
progress and weight risks and benefits of the Change. It is then up to
FESCo to decide. Anyone from the Fedora community can join FESCo
meetings and express his/her concerns about any Change. You might see
risks others do not see, so you can try to describe those concerns to
FESCo providing them with broader information to make qualified
decision then.
FESCo does not have a history of actually getting broken changes reverted,
see the NetworkManager 0.9 fiasco in Fedora 15. (For those who do not
remember: Fedora 15 shipped with a NM 0.9 prerelease despite the KDE tools
not being ready for it, they ended up patching in a NM 0.8 compatibility API
into it, but NM updates were alternating between breaking the new API and
breaking the old API, and each time they went into stable very quickly
because the users of the desktop that was fixed were very quickly giving +1
votes. The KDE NM frontend then had to be updated to an NM 0.9 version when
it was still under development upstream and had issues with migrating
existing configurations, because the 0.8 compatibility API had just broken
down completely in an NM update and was not getting fixed anymore. The NM
0.8 compatibility API also only supported the exact feature set that that
particular snapshot of the KDE NM frontend happened to use, so we were
unable to upgrade to newer snapshots until the branch targeting NM 0.9 was
created upstream.) So I do not think they will actually get those Changes
withdrawn if they are broken, especially considering how they have been
forced through so far.
No-more-alphas is not forced by F27 schedule. It is a goal we were
talking about for some time (there were realistic discussions at least
from the time of F23 release). The infrastructure is getting ready for
it step by step, i.e. development of new "pungi" allowing us to do
nightly builds, the development and enhancement of automated CI
pipeline (Taskotron, OpenQA) etc. were prerequisites for the
No-more-alphas Change which were put in place before we decided to
skip the Alpha. I see your point and I agree that due to slip of F26
for five weeks we are in the pressure for F27, but it has nothing to
do with the No-more-alphas Change. We were aiming to implement this
Change for a long time.
There seems to be a misunderstanding: I am not claiming that No-more-alphas
was invented specifically for the short F27 schedule. I am only pointing out
that the F27 schedule assumes No-more-alphas and that such a short schedule
is not possible without it. Fedora has never had such a short schedule
before.
Kevin Kofler