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