Re: Drop Alphas and Betas (was Re: Releasing Alphas and Betas without "freezing")
On 06/18/2012 03:46 PM, Scott Kitterman wrote: > On Monday, June 18, 2012 03:42:49 PM Rodney Dawes wrote: >> Ditën e Mon, 18/06/2012 më 15.30 -0400, Scott Kitterman ka shkruar: >>> On Monday, June 18, 2012 01:30:34 PM Chris Wilson wrote: >>> ... >>> I also think adding the "Release Candidate (RC)" designation towards the end of the cycle would encourage more people who are quite wary of installing pre-release software on their computer to get involved with last minute testing since RC indicates that it's pretty much done and all that's left is to iron out some minor glitches. >>> >>> ... >>> We used to call what's now Beta 1 a "Release Candidate" for similar >>> reasons, but renamed it because it's not really a release candidate. >>> Generally "Release Candidate" means "Thing that will get released if no >>> new significant issues turn up". Our current usage matches that and we >>> should stick with it. I don't like the idea of turning Release Candidate >>> into a marketing term in order to encourage more testing. >> >> And I think the idea here is that every single daily image fits into >> that category of what we're calling a "Release Candidate." If we >> maintain high quality throughout the cycle, then at any point after >> the higher level freezes (feature, UI, string, etc…) we could >> theoretically point to any image and say "this is the release >> candidate." If we can't do that, then we should at least be able to >> isolate where and why we can't (particular packages not meeting the >> quality standards, introducing problems late in cycle, etc…), and >> work on preventing that from happening in the future. > > Up until the last translation import is finished, we know everything is not a > release candidate. After that, I agree. > > Scott K We typically need the last batch of outside-of-langpacks translation updates, a new batch of langpacks, a new base-files (for lsb_release), a new ubiquity (dropping any remaining alpha/beta warning) and matching debian-cd change (to actually mark the images as finals). Currently we consider that any of the above (including the debian-cd flag change) require re-testing of the images. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Drop Alphas and Betas (was Re: Releasing Alphas and Betas without "freezing")
On Monday, June 18, 2012 03:42:49 PM Rodney Dawes wrote: > Ditën e Mon, 18/06/2012 më 15.30 -0400, Scott Kitterman ka shkruar: > > On Monday, June 18, 2012 01:30:34 PM Chris Wilson wrote: > > ... > > > > > I also think adding the "Release Candidate (RC)" designation towards the > > > end of the cycle would encourage more people who are quite wary of > > > installing pre-release software on their computer to get involved with > > > last > > > minute testing since RC indicates that it's pretty much done and all > > > that's > > > left is to iron out some minor glitches. > > > > ... > > We used to call what's now Beta 1 a "Release Candidate" for similar > > reasons, but renamed it because it's not really a release candidate. > > Generally "Release Candidate" means "Thing that will get released if no > > new significant issues turn up". Our current usage matches that and we > > should stick with it. I don't like the idea of turning Release Candidate > > into a marketing term in order to encourage more testing. > > And I think the idea here is that every single daily image fits into > that category of what we're calling a "Release Candidate." If we > maintain high quality throughout the cycle, then at any point after > the higher level freezes (feature, UI, string, etc…) we could > theoretically point to any image and say "this is the release > candidate." If we can't do that, then we should at least be able to > isolate where and why we can't (particular packages not meeting the > quality standards, introducing problems late in cycle, etc…), and > work on preventing that from happening in the future. Up until the last translation import is finished, we know everything is not a release candidate. After that, I agree. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Drop Alphas and Betas (was Re: Releasing Alphas and Betas without "freezing")
Ditën e Mon, 18/06/2012 më 15.30 -0400, Scott Kitterman ka shkruar: > On Monday, June 18, 2012 01:30:34 PM Chris Wilson wrote: > ... > > I also think adding the "Release Candidate (RC)" designation towards the > > end of the cycle would encourage more people who are quite wary of > > installing pre-release software on their computer to get involved with last > > minute testing since RC indicates that it's pretty much done and all that's > > left is to iron out some minor glitches. > ... > We used to call what's now Beta 1 a "Release Candidate" for similar reasons, > but renamed it because it's not really a release candidate. Generally > "Release Candidate" means "Thing that will get released if no new significant > issues turn up". Our current usage matches that and we should stick with it. > > I don't like the idea of turning Release Candidate into a marketing term in > order to encourage more testing. And I think the idea here is that every single daily image fits into that category of what we're calling a "Release Candidate." If we maintain high quality throughout the cycle, then at any point after the higher level freezes (feature, UI, string, etc…) we could theoretically point to any image and say "this is the release candidate." If we can't do that, then we should at least be able to isolate where and why we can't (particular packages not meeting the quality standards, introducing problems late in cycle, etc…), and work on preventing that from happening in the future. signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Drop Alphas and Betas (was Re: Releasing Alphas and Betas without "freezing")
On Monday, June 18, 2012 03:30:27 PM Scott Kitterman wrote: > On Monday, June 18, 2012 01:30:34 PM Chris Wilson wrote: > ... > > > I also think adding the "Release Candidate (RC)" designation towards the > > end of the cycle would encourage more people who are quite wary of > > installing pre-release software on their computer to get involved with > > last > > minute testing since RC indicates that it's pretty much done and all > > that's > > left is to iron out some minor glitches. > > ... > We used to call what's now Beta 1 a "Release Candidate" for similar reasons, > but renamed it because it's not really a release candidate. Generally > "Release Candidate" means "Thing that will get released if no new > significant issues turn up". Our current usage matches that and we should > stick with it. I don't like the idea of turning Release Candidate into a > marketing term in order to encourage more testing. Correction: I meant Beta 2, not Beta 1. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Drop Alphas and Betas (was Re: Releasing Alphas and Betas without "freezing")
On Monday, June 18, 2012 01:30:34 PM Chris Wilson wrote: ... > I also think adding the "Release Candidate (RC)" designation towards the > end of the cycle would encourage more people who are quite wary of > installing pre-release software on their computer to get involved with last > minute testing since RC indicates that it's pretty much done and all that's > left is to iron out some minor glitches. ... We used to call what's now Beta 1 a "Release Candidate" for similar reasons, but renamed it because it's not really a release candidate. Generally "Release Candidate" means "Thing that will get released if no new significant issues turn up". Our current usage matches that and we should stick with it. I don't like the idea of turning Release Candidate into a marketing term in order to encourage more testing. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Drop Alphas and Betas (was Re: Releasing Alphas and Betas without "freezing")
On 18/06/12 13:30, Chris Wilson wrote: Therefore, I propose: 1) Beta 1-4 at the end of months 1-4 that sounds great, give a "beta" blessing to a daily iso after it has been confirmed to not mess up grub or eat kittens etc. and invite wider testing of these. 2) Release Candidate release at the end of month 5 a release candidate is supposed to be "we might release this actual code if it isn't broken" and that is not really the case at the end of month 5. 3) Full release at the end of month 6 yay 4) All the while with new test ISOs being spun up every 2 or 3 weeks (or greater if that's too fast) we have daily isos -- I work at http://libertus.co.uk -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Drop Alphas and Betas (was Re: Releasing Alphas and Betas without "freezing")
On 18 June 2012 07:36, Rick Spencer wrote: > Therefore, I propose we: > 1. Stop with the alphas and betas and win back all of the development > effort > 2. *Increase* the cadence of ISO testing to whatever we want or > whatever the community team can manage > 3. Spin a trial ISO near what is not beta time (maybe around current > kernel freeze?) > 4. Spin ISOs for release candidates > 5. Maintain the current Alpha and Beta designations as development > targets only (i.e. don't spin a special image for them). > >From the point of view of a community member: The term Alpha can be quite frightening to some people, given that it's traditionally been associated with unstable software in the early stages of development. The few times I've installed Alpha version of Ubuntu it was no more than a couple of days before I had to revert back to the previous stable release because it was so unusable. In the 12.04 cycle, that was no longer the case and the Alpha was quite usable, so I think that since we've broken with the instability during the release cycle, perhaps we should break with the Alpha designation as well. If we want to get more people involved in testing early on, then I think this would be the way to go. I also think adding the "Release Candidate (RC)" designation towards the end of the cycle would encourage more people who are quite wary of installing pre-release software on their computer to get involved with last minute testing since RC indicates that it's pretty much done and all that's left is to iron out some minor glitches. I think releasing more Betas would also go towards getting more people involved in testing, as most people would give a new Beta a test once it's released, but forget about it soon after. Releasing a Beta each month, based on the last successful test ISO build, would give more milestones for people to get excited about, and bring back people who had drifted away after some earlier testing. Therefore, I propose: 1) Beta 1-4 at the end of months 1-4 2) Release Candidate release at the end of month 5 3) Full release at the end of month 6 4) All the while with new test ISOs being spun up every 2 or 3 weeks (or greater if that's too fast) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Drop Alphas and Betas (was Re: Releasing Alphas and Betas without "freezing")
(I changed the subject to better represent this branch of the conversation) This discussion suggests that we don't need to release special alpha and beta ISOs, but we do need: 1. A cadence of testing 2. A trial run (or 2) of spinning ISOs 3. Development targets Therefore, I propose we: 1. Stop with the alphas and betas and win back all of the development effort 2. *Increase* the cadence of ISO testing to whatever we want or whatever the community team can manage 3. Spin a trial ISO near what is not beta time (maybe around current kernel freeze?) 4. Spin ISOs for release candidates 5. Maintain the current Alpha and Beta designations as development targets only (i.e. don't spin a special image for them). Cheers, Rick On Sun, Jun 17, 2012 at 11:25 PM, Robert Ancell wrote: > On 16/06/12 02:12, Rick Spencer wrote: >> In short, freezing the archive before an alpha or beta should not >> actually be contributing to either ensuring the installability of >> Ubuntu images or ensuring the quality of these images. This implies, >> therefore, that all the work around freezing, and all the productivity >> lost during a freeze, actually subtracts from the quality of Ubuntu by >> reducing our overall velocity for both features and bug fixes, since >> every day the image is good quality, and Alpha or Beta should be just >> that day's image tagged appropriately. > In particular I find the alpha freeze kills our velocity and I wonder > how more useful than a daily build the alpha release is (given it's so > early in the cycle anyway). I'd support dropping the alpha and pointing > at the dailies. > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
