[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Buyer Beware: A Major Change in NFS is about to happen

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...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]