On 09/29/2009 05:38 PM, Steve Dickson wrote: > On 09/29/2009 08:17 PM, John Poelstra wrote: >>>> [...snip...] >>>> >>>> I want to be perfectly clear that I'm not sounding an "all clear" on >>>> this by any means. If your answer here means that this change hasn't >>>> been thoroughly tested, you're going to have a hard time convincing >>>> anyone that it should be turning over on Beta freeze day. >>>> >>> By no means did I interpret that at all... but here lies the >>> problem... I had no idea I would have to convenience *anybody* >>> of *anything* because I thought I made the dead line... again all >>> following was the schedule in: >>> >>> http://www.linux-archive.org/fedora-development/372823-all-features-need-100-beta-freeze-2009-09-29-a.html >>> >>> >>> And Today I am %100 finished... Please point out which part of that >>> did I misinterpret, because the last thing I want to do is cause >>> problems... >>> >>> steved. >>> >>> >> Thanks, >> John >> >> https://www.redhat.com/archives/fedora-devel-announce/2009-July/msg00027.html >> >> >> Many of us were assuming that "testable" and "significantly complete" >> would be enough to imply that a change like this should be done so it >> could be tested during the Alpha. >> >> How should we word things differently in the future so it is clearer? > Again, John, that is a wonderful question... From my perspective I > had my head down working as hard as I could to make this deadline... > I knew about the alpha deadline and this dealing... > > I my past, added things of this size in a beta release was actually > common.. In alpha release you get the software married to the hardware > (i.e. barely booting) and in beta release you added everything else... > Now the post beta release is when the door close... nothing but bug fixes.. > 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. 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. 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 et al. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
