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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
