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.