On 09/29/2009 09:21 PM, Toshio Kuratomi wrote: > One thing I think is unclear this cycle is the usage of the word "Beta". > It's been said many times that beta is not really beta but actually > final freeze. For instance: "If all goes as planned the Beta > (previously known as "Final Development") Freeze" in the message steved > linked to. And yet, no one actually expects that beta is the final > development freeze. Maybe we should just give up and not use the beta > moniker for it. As inaccurate as it is, "release candidate" is a > *better inaccuracy* in terms of communicating to developers. Developers > understand that by "release candidate" we're going to be very tough > about getting changes in, even if they appear to improve the experience. > Some things will just have to be deferred after a release candidate is > out the door. In the kernel world they have a number of RC releases... As the number increases the window of opportunity closes... and I believe after a certain rc release, no new features are allowed.. > > One possibility is to have a beta1 at feature freeze and a beta2 now. > This helps developers realize that nothing but bugfixes should be going > in from feature freeze on but lets end user's know that the release > we're making now is still not finished. It still doesn't give the sense > of urgency and finality that "release candidate" does, though, so I'm > not sure if that's enough. Yeah, agree with this... beta1 or beta2 meanings nothing.. is still a beta... > > Another thing that seems to be apparent in steved's complaint is that > what the expectations for Final Feature Freeze (in July) are not clear > enough. What is meant by testable? It seems that we mean, the Feature > should be in, enabled, and in final form at that point. Right or wrong.. I took "Final Feature Freeze" as the last chance of getting a feature into F12.. And I will be the first to admit I do not read all the rule and regulations of all the steps of a release... I look at dates.. When is the alpha and when is the beta. After a beta release I don't even try to get anything new in, just bug fixes... > > We want to be able to do integration testing from that point forward. > That means we're no longer testing the Feature in isolation, but as part > of the whole experience of installing and running the distro. Bugfixes > can be applied but nothing that changes the basic shape or architecture > of the distro as a whole. Plainly, changing the default from nfsv3 to > nfsv4 should happen at Feature Freeze rather than now for that testing > to be performed. But there's other meanings of testable. I'm sure that > steved considered the Feature testable at Feature Freeze... he just > wasn't applying the idea that it needed to be testable as part of the > whole distro experience. This issue for me was terminology.... As I said before, I took "Feature Freeze" as the day I had to get my feature in and approved... after that I figured I had a number of release deadline to the code in... > > Perhaps we need to list some examples of things that should not happen > after Feature Freeze as well as expectation of what should happen. > > Examples of what to do and not do from this point forward: > Do: Have something testable > Do: Have the the feature significantly complete > Do: submit bugfixes > Do not: Enable the feature by default > Do not: Make changes that cause other software to have to make changes Again from my prospective, if it was required to get kernel changes, including any and all packages (ala nfs-utils, udev, hal) that effect those kernel changes that would be a bit more clearer... steved. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
