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 

        Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to