On Tue, 2009-09-29 at 18:21 -0700, 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. > > The downside of "release candidate", as Jesse has pointed out before, is > that it communicates the wrong thing to end-users. There's zero chance > that this cut is going to be the absolute final set of bits that we use > on release day so from an end-user perspective, it's not a release > candidate. > > 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. We've tried to address unclear terminology this summer with the milestone adjustment proposal. https://fedoraproject.org/wiki/Milestone_Adjustment_Proposal This tries to apply industry standard naming to our release process, and as such we had to rename some things. > > 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, I've always taken it to mean "Our experimental code is in, and we're ready to take end user testing feedback on it" which is different from "our code is in, but not really done, and we don't care if it's broken because we're going to re-write it again in a week". > > 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. > > 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 These seem like reasonable good starts and should find themselves in the wiki at some point. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
