Re: Releasing Alphas and Betas without "freezing"
On 06/15/2012 11:19 AM, Stéphane Graber wrote: On 06/15/2012 10:46 AM, Scott Kitterman wrote: On Friday, June 15, 2012 10:28:55 AM Stéphane Graber wrote: On 06/15/2012 10:12 AM, Rick Spencer wrote: Hello all, At UDS I had some "hallway discussions" about why we freeze for Alphas and Betas, and the fact that I think it is time to drop this practice and rather focus on making Ubuntu good quality each day. Sadly, there was no session on this, thus this email to this list for discussion. I think it is time drop our "Freeze" practices for the alphas and betas. Here is my reasoning: 1. We are developing tools that allow us to efficiently use -proposed in a way that will ensure we will not have partially built or incompatible components in the release pocket ... ever. Including days we release Alphas and Betas: These blueprints tools to ensure that Ubuntu is not uninstallable or have other problems due to partially built components and such: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upload-interme diary https://blueprints.launchpad.net/ubuntu/+spec/other-q-freeze-use-of-propo sed I have been assured that the tools necessary to automate the work of moving components correctly from -proposed to the release will be ready before Alpha 2. 2. We are investing heavily in the daily quality of Ubuntu. For example ... We run the same automated tests on an alpha as we run on a daily: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/ We tend to archive issues each day: http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html We ran all the manual ISO tests *before* we released Alpha 1, and we have the capability of doing this at will: http://iso.qa.ubuntu.com/qatracker/milestones/221/builds 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. AIUI, A1 was delivered in such a manner, though without the tooling to ensure that moving from -proposed to the release pocket was efficient and automated. Cheers, Rick Hi Rick, We certainly want to allow people to upload stuff to -proposed during a milestone week, but I don't agree that we should automatically copy from -proposed to the release pocket during a milestone week. We usually try to release all our images with the same versions of the packages, considering it takes us hours to rebuild everything, having seeded packages land during that time, will lead to images having different version of packages. As for what happened with Alpha 1, we simply asked everyone to upload their packages to -proposed and then cherry picked the packages we actually needed for the release from -proposed and copied them into the release pocket before rebuilding the images (we did that 3 times). As I understand it, the plan going forward is to have the release pocket be an alias of -proposed on upload, so that everything always lands into -proposed. After something lands in -proposed, is properly built and passes whatever other criteria we'll have, the package will be automatically copied to the release pocket. That last part (copy to the release pocket) would be what we'd block during a milestone week for any package that's seeded. These would be copied on a case by case basis by the release team and the images rebuilt afterwards. That'd essentially allow any non-seeded package to still flow to the release pocket and be available for everyone. All the others will be available for people running with -proposed enabled or will be available when we manually copy them to the release pocket or right after we release the milestone and we copy everything left in -proposed to the release pocket. This looks complicated. Maybe it will be easier in practice. Well, it'd be easier during hard freeze as things that aren't supposed to be frozen would still be automatically let through (but still preventing any archive skew). It also looks like a big shift of work from developers to the release team. Currently it's up to developers to decide what needs uploading to get to the milestone. During a soft freeze there's no action from the release team except coordination. With this mechanism, developers can upload whatever and it's up to the release team to figure out. Yes, that's a bit of extra work, though it also gives us the guarantee that we won't have any accidental upload that might break the archive or require a respin. Packages that need to land in the release pocket for a milestone already need to be listed on the release team pad (as respin trigger), so I don't t
Re: Patch Pilot Report 20120615
Excerpts from James Page's message of 2012-06-15 05:57:41 -0700: > Hi Daniel > > On 15/06/12 13:31, Daniel Holbach wrote: > > On 15.06.2012 14:08, James Page wrote: > >>> SRU's which have been uploaded but not accepted are hard to > >>> differentiate on the report - they don't require any further > >>> sponsor action so it would be good to be able to filter those > >>> out if possible. > > That's a good point. I usually set the bug to 'fix committed', > > subscribe myself and unsubscribe ubuntu-sponsors, so I can follow > > up if necessary. > > > > Maybe this could be clearer on > > https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews? > > I don't think this is a challenge with bugs (although it could be more > explicit in the Code Review docs). Merge proposals create more of a > challenge as I'm unable to set 'Fix Committed' in the same way so they > just lurk around until they get 'Merged' which could take some time. > > Not sure we can do to much about that. > Can we change them to 'Approved' ? If so, that would be a good status to filter out of the sponsoring report, and something to be careful to only set after uploading to the -proposed queue. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
On 06/15/2012 10:26 AM, Sebastien Bacher wrote: > Le 15/06/2012 17:05, Scott Kitterman a écrit : >> I don't think you get to have it both ways. Either we stabilize an >> image and >> put a stamp on it and we need some kind of freeze or we don't. Trying >> to let >> developers continue to do their work while ignoring the milestone just >> pushes >> the problem of getting things fixed for the milestone on the release >> team. > Hey, > > Yeah, you are right there, so if we get working dailies every day do we > still need alphas at all? > > Ideally we would have the automatic testing flagging isos "green" when > they have no issue (with the goal to always have them good) and we would > recommend people to just pick the current green iso. > > Can we just drop the image rolling part of milestones? We still probably > want fixed checkpoints in the cycle to review the features, etc but they > don't especially need to be linked with a special image... > With our dailies, I've found that the milestones are most useful for planning bug fix landings and feature deliverables. I'd be +1 on dropping alphas all together. If we need some specific test feedback on a given image, we can always issue calls for testing like we've done in the past. However, if we drop alphas, I think we might want to keep a single beta and consider an earlier RC in place of the Beta 2. These releases are typically aimed at getting the less developer savy/bug tolerant users to test and provide feedback, so I could see perhaps a more strenuous QA process put in place for them, i.e. for system integrated/stress testing, versus the typical Unit/Functional automated testing we have reporting to jenkins. It would also be good for the release team to have a couple practice runs before the real deal ;). Just my $0.02 -Robbie -- Robbie Williamson robbiew[irc.freenode.net] "Don't make me angry...you wouldn't like me when I'm angry." -Bruce Banner -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
Le 15/06/2012 17:05, Scott Kitterman a écrit : I don't think you get to have it both ways. Either we stabilize an image and put a stamp on it and we need some kind of freeze or we don't. Trying to let developers continue to do their work while ignoring the milestone just pushes the problem of getting things fixed for the milestone on the release team. Hey, Yeah, you are right there, so if we get working dailies every day do we still need alphas at all? Ideally we would have the automatic testing flagging isos "green" when they have no issue (with the goal to always have them good) and we would recommend people to just pick the current green iso. Can we just drop the image rolling part of milestones? We still probably want fixed checkpoints in the cycle to review the features, etc but they don't especially need to be linked with a special image... Cheers, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Kubuntu and main/universe
On Mon, Jun 04, 2012 at 11:52:20AM +0100, Jonathan Riddell wrote: > I think the practicalities of it are Colin running change-override > lots and updating livefs and cdimage to use universe. This is now done. Source packages moved to universe in their entirety: amarok analitza ark avogadro bluedevil calligra calligra-l10n cdrdao cfitsio3 choqok create-resources dragon ebook-tools eigen2 enscript eyed3 facile filelight fonts-dustin fortune-mod ggz-client-libs gle gnugo gtk2-engines-oxygen gwenview ibus-qt jovie juk k3b kaccessible kalgebra kalzium kamera kanagram kbruch kcalc kcharselect kcm-gtk kcolorchooser kde-base-artwork kde-l10n-ar kde-l10n-bg kde-l10n-bs kde-l10n-ca kde-l10n-ca-valencia kde-l10n-cs kde-l10n-csb kde-l10n-da kde-l10n-de kde-l10n-el kde-l10n-engb kde-l10n-eo kde-l10n-es kde-l10n-et kde-l10n-eu kde-l10n-fa kde-l10n-fi kde-l10n-fr kde-l10n-fy kde-l10n-ga kde-l10n-gl kde-l10n-gu kde-l10n-he kde-l10n-hi kde-l10n-hr kde-l10n-hu kde-l10n-ia kde-l10n-id kde-l10n-is kde-l10n-it kde-l10n-ja kde-l10n-kk kde-l10n-km kde-l10n-kn kde-l10n-ko kde-l10n-lt kde-l10n-lv kde-l10n-mai kde-l10n-mk kde-l10n-ml kde-l10n-nb kde-l10n-nds kde-l10n-nl kde-l10n-nn kde-l10n-pa kde-l10n-pl kde-l10n-pt kde-l10n-ptbr kde-l10n-ro kde-l10n-ru kde-l10n-si kde-l10n-sk kde-l10n-sl kde-l10n-sr kde-l10n-sv kde-l10n-tg kde-l10n-th kde-l10n-tr kde-l10n-ug kde-l10n-uk kde-l10n-vi kde-l10n-wa kde-l10n-zhcn kde-l10n-zhtw kde-wallpapers kdeadmin kdeartwork kdegames kdegraphics-mobipocket kdegraphics-strigi-analyzer kdegraphics-thumbnailers kdenetwork kdepim kdeplasma-addons kdesudo kdetoys kdewebdev kdf kgamma kgeography kgpg khangman kig klettres kmag kmix kmousetool kmouth kmplot kolourpaint konversation kopete-message-indicator kremotecontrol kross-interpreters kruler ksaneplugin ksnapshot kstars ktimer ktorrent ktouch kturtle kubuntu-default-settings kubuntu-docs kubuntu-firefox-installer kubuntu-meta kubuntu-netbook-default-settings kubuntu-notification-helper kubuntu-web-shortcuts kvkbd kwallet kwordquiz language-pack-kde-aa language-pack-kde-aa-base language-pack-kde-af language-pack-kde-af-base language-pack-kde-am language-pack-kde-am-base language-pack-kde-an language-pack-kde-an-base language-pack-kde-ar language-pack-kde-ar-base language-pack-kde-as language-pack-kde-as-base language-pack-kde-ast language-pack-kde-ast-base language-pack-kde-az language-pack-kde-az-base language-pack-kde-be language-pack-kde-be-base language-pack-kde-bg language-pack-kde-bg-base language-pack-kde-bn language-pack-kde-bn-base language-pack-kde-bo language-pack-kde-bo-base language-pack-kde-br language-pack-kde-br-base language-pack-kde-bs language-pack-kde-bs-base language-pack-kde-ca language-pack-kde-ca-base language-pack-kde-crh language-pack-kde-crh-base language-pack-kde-cs language-pack-kde-cs-base language-pack-kde-csb language-pack-kde-csb-base language-pack-kde-cy language-pack-kde-cy-base language-pack-kde-da language-pack-kde-da-base language-pack-kde-de language-pack-kde-de-base language-pack-kde-dv language-pack-kde-dv-base language-pack-kde-el language-pack-kde-el-base language-pack-kde-en language-pack-kde-en-base language-pack-kde-eo language-pack-kde-eo-base language-pack-kde-es language-pack-kde-es-base language-pack-kde-et language-pack-kde-et-base language-pack-kde-eu language-pack-kde-eu-base language-pack-kde-fa language-pack-kde-fa-base language-pack-kde-fi language-pack-kde-fi-base language-pack-kde-fil language-pack-kde-fil-base language-pack-kde-fo language-pack-kde-fo-base language-pack-kde-fr language-pack-kde-fr-base language-pack-kde-fur language-pack-kde-fur-base language-pack-kde-fy language-pack-kde-fy-base language-pack-kde-ga language-pack-kde-ga-base language-pack-kde-gd language-pack-kde-gd-base language-pack-kde-gl language-pack-kde-gl-base language-pack-kde-gu language-pack-kde-gu-base language-pack-kde-gv language-pack-kde-gv-base language-pack-kde-ha language-pack-kde-ha-base language-pack-kde-he language-pack-kde-he-base language-pack-kde-hi language-pack-kde-hi-base language-pack-kde-hne language-pack-kde-hne-base language-pack-kde-hr language-pack-kde-hr-base language-pack-kde-hsb language-pack-kde-hsb-base language-pack-kde-ht language-pack-kde-ht-base language-pack-kde-hu language-pack-kde-hu-base language-pack-kde-hy language-pack-kde-hy-base language-pack-kde-ia language-pack-kde-ia-base language-pack-kde-id language-pack-kde-id-base language-pack-kde-is language-pack-kde-is-base lan
Re: Releasing Alphas and Betas without "freezing"
On 06/15/2012 10:46 AM, Scott Kitterman wrote: > On Friday, June 15, 2012 10:28:55 AM Stéphane Graber wrote: >> On 06/15/2012 10:12 AM, Rick Spencer wrote: >>> Hello all, >>> >>> At UDS I had some "hallway discussions" about why we freeze for Alphas >>> and Betas, and the fact that I think it is time to drop this practice >>> and rather focus on making Ubuntu good quality each day. Sadly, there >>> was no session on this, thus this email to this list for discussion. >>> >>> I think it is time drop our "Freeze" practices for the alphas and >>> betas. Here is my reasoning: >>> >>> 1. We are developing tools that allow us to efficiently use -proposed >>> in a way that will ensure we will not have partially built or >>> incompatible components in the release pocket ... ever. Including days >>> we release Alphas and Betas: >>> >>> These blueprints tools to ensure that Ubuntu is not uninstallable or >>> have other problems due to partially built components and such: >>> https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upload-interme >>> diary >>> https://blueprints.launchpad.net/ubuntu/+spec/other-q-freeze-use-of-propo >>> sed >>> >>> I have been assured that the tools necessary to automate the work of >>> moving components correctly from -proposed to the release will be >>> ready before Alpha 2. >>> >>> 2. We are investing heavily in the daily quality of Ubuntu. For example >>> ... >>> We run the same automated tests on an alpha as we run on a daily: >>> https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/ >>> >>> We tend to archive issues each day: >>> http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html >>> >>> We ran all the manual ISO tests *before* we released Alpha 1, and we >>> have the capability of doing this at will: >>> http://iso.qa.ubuntu.com/qatracker/milestones/221/builds >>> >>> 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. >>> >>> AIUI, A1 was delivered in such a manner, though without the tooling to >>> ensure that moving from -proposed to the release pocket was efficient >>> and automated. >>> >>> Cheers, Rick >> >> Hi Rick, >> >> We certainly want to allow people to upload stuff to -proposed during a >> milestone week, but I don't agree that we should automatically copy from >> -proposed to the release pocket during a milestone week. >> >> We usually try to release all our images with the same versions of the >> packages, considering it takes us hours to rebuild everything, having >> seeded packages land during that time, will lead to images having >> different version of packages. >> >> As for what happened with Alpha 1, we simply asked everyone to upload >> their packages to -proposed and then cherry picked the packages we >> actually needed for the release from -proposed and copied them into the >> release pocket before rebuilding the images (we did that 3 times). >> >> >> As I understand it, the plan going forward is to have the release pocket >> be an alias of -proposed on upload, so that everything always lands into >> -proposed. >> After something lands in -proposed, is properly built and passes >> whatever other criteria we'll have, the package will be automatically >> copied to the release pocket. >> >> That last part (copy to the release pocket) would be what we'd block >> during a milestone week for any package that's seeded. These would be >> copied on a case by case basis by the release team and the images >> rebuilt afterwards. >> >> That'd essentially allow any non-seeded package to still flow to the >> release pocket and be available for everyone. >> All the others will be available for people running with -proposed >> enabled or will be available when we manually copy them to the release >> pocket or right after we release the milestone and we copy everything >> left in -proposed to the release pocket. > > This looks complicated. Maybe it will be easier in practice. Well, it'd be easier during hard freeze as things that aren't supposed to be frozen would still be automatically let through (but still preventing any archive skew). > It also looks like a big shift of work from developers to the release team. > Currently it's up to developers to decide what needs uploading to get to the > milestone. During a soft freeze there's no action from the release team > except coordination. With this mechanism, developers can upload whatever and > it's up to the release team to figure out. Yes, that's a bit of extra work, though it
Re: Releasing Alphas and Betas without "freezing"
On Friday, June 15, 2012 04:57:57 PM Rick Spencer wrote: > On Fri, Jun 15, 2012 at 4:48 PM, Scott Kitterman wrote: > > On Friday, June 15, 2012 04:41:51 PM Rick Spencer wrote: > > ... > > > >> The essential point is, Ubuntu should be good every day. There should > >> be nothing special about an alpha or beta, it's simply the daily image > >> on some chosen day. Making them special doesn't buy us anything, but > >> has costs. > > > > ... > > Then cancel the whole milestone process, grab a daily and call it done. > > Kinda what I'm saying, yeah. I think we probably still need milestones > for targeting bug fixes and features, but we could change that to be > keyed off of months. I think there are also widespread external > expectations that there are alphas and betas in a software project so > I'm not quite ready to advocate for "no alpha and betas" at all. I don't think you get to have it both ways. Either we stabilize an image and put a stamp on it and we need some kind of freeze or we don't. Trying to let developers continue to do their work while ignoring the milestone just pushes the problem of getting things fixed for the milestone on the release team. 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: Releasing Alphas and Betas without "freezing"
On Fri, Jun 15, 2012 at 4:48 PM, Scott Kitterman wrote: > On Friday, June 15, 2012 04:41:51 PM Rick Spencer wrote: > ... >> The essential point is, Ubuntu should be good every day. There should >> be nothing special about an alpha or beta, it's simply the daily image >> on some chosen day. Making them special doesn't buy us anything, but >> has costs. > ... > Then cancel the whole milestone process, grab a daily and call it done. Kinda what I'm saying, yeah. I think we probably still need milestones for targeting bug fixes and features, but we could change that to be keyed off of months. I think there are also widespread external expectations that there are alphas and betas in a software project so I'm not quite ready to advocate for "no alpha and betas" at all. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
On Friday, June 15, 2012 04:41:51 PM Rick Spencer wrote: ... > The essential point is, Ubuntu should be good every day. There should > be nothing special about an alpha or beta, it's simply the daily image > on some chosen day. Making them special doesn't buy us anything, but > has costs. ... Then cancel the whole milestone process, grab a daily and call it done. 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: Releasing Alphas and Betas without "freezing"
On Friday, June 15, 2012 10:28:55 AM Stéphane Graber wrote: > On 06/15/2012 10:12 AM, Rick Spencer wrote: > > Hello all, > > > > At UDS I had some "hallway discussions" about why we freeze for Alphas > > and Betas, and the fact that I think it is time to drop this practice > > and rather focus on making Ubuntu good quality each day. Sadly, there > > was no session on this, thus this email to this list for discussion. > > > > I think it is time drop our "Freeze" practices for the alphas and > > betas. Here is my reasoning: > > > > 1. We are developing tools that allow us to efficiently use -proposed > > in a way that will ensure we will not have partially built or > > incompatible components in the release pocket ... ever. Including days > > we release Alphas and Betas: > > > > These blueprints tools to ensure that Ubuntu is not uninstallable or > > have other problems due to partially built components and such: > > https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upload-interme > > diary > > https://blueprints.launchpad.net/ubuntu/+spec/other-q-freeze-use-of-propo > > sed > > > > I have been assured that the tools necessary to automate the work of > > moving components correctly from -proposed to the release will be > > ready before Alpha 2. > > > > 2. We are investing heavily in the daily quality of Ubuntu. For example > > ... > > We run the same automated tests on an alpha as we run on a daily: > > https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/ > > > > We tend to archive issues each day: > > http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html > > > > We ran all the manual ISO tests *before* we released Alpha 1, and we > > have the capability of doing this at will: > > http://iso.qa.ubuntu.com/qatracker/milestones/221/builds > > > > 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. > > > > AIUI, A1 was delivered in such a manner, though without the tooling to > > ensure that moving from -proposed to the release pocket was efficient > > and automated. > > > > Cheers, Rick > > Hi Rick, > > We certainly want to allow people to upload stuff to -proposed during a > milestone week, but I don't agree that we should automatically copy from > -proposed to the release pocket during a milestone week. > > We usually try to release all our images with the same versions of the > packages, considering it takes us hours to rebuild everything, having > seeded packages land during that time, will lead to images having > different version of packages. > > As for what happened with Alpha 1, we simply asked everyone to upload > their packages to -proposed and then cherry picked the packages we > actually needed for the release from -proposed and copied them into the > release pocket before rebuilding the images (we did that 3 times). > > > As I understand it, the plan going forward is to have the release pocket > be an alias of -proposed on upload, so that everything always lands into > -proposed. > After something lands in -proposed, is properly built and passes > whatever other criteria we'll have, the package will be automatically > copied to the release pocket. > > That last part (copy to the release pocket) would be what we'd block > during a milestone week for any package that's seeded. These would be > copied on a case by case basis by the release team and the images > rebuilt afterwards. > > That'd essentially allow any non-seeded package to still flow to the > release pocket and be available for everyone. > All the others will be available for people running with -proposed > enabled or will be available when we manually copy them to the release > pocket or right after we release the milestone and we copy everything > left in -proposed to the release pocket. This looks complicated. Maybe it will be easier in practice. It also looks like a big shift of work from developers to the release team. Currently it's up to developers to decide what needs uploading to get to the milestone. During a soft freeze there's no action from the release team except coordination. With this mechanism, developers can upload whatever and it's up to the release team to figure out. I can see this being particularly a problem where a small fix is needed for the milestone, but the developer's work would naturally flow to a larger update. With no freeze and it being up to the release team, as Rick says, developer flow would continue and the release team would get stu
Re: Releasing Alphas and Betas without "freezing"
>> Cheers, Rick > > Hi Rick, > > We certainly want to allow people to upload stuff to -proposed during a > milestone week, but I don't agree that we should automatically copy from > -proposed to the release pocket during a milestone week. > > We usually try to release all our images with the same versions of the > packages, considering it takes us hours to rebuild everything, having > seeded packages land during that time, will lead to images having > different version of packages. > > As for what happened with Alpha 1, we simply asked everyone to upload > their packages to -proposed and then cherry picked the packages we > actually needed for the release from -proposed and copied them into the > release pocket before rebuilding the images (we did that 3 times). If you have to go in and cherry pick packages to copy over, would it not make more sense to simply automatically copy everything over? Everything will be properly built before it is copied over anyway, right? > > > As I understand it, the plan going forward is to have the release pocket > be an alias of -proposed on upload, so that everything always lands into > -proposed. > After something lands in -proposed, is properly built and passes > whatever other criteria we'll have, the package will be automatically > copied to the release pocket. > > That last part (copy to the release pocket) would be what we'd block > during a milestone week for any package that's seeded. These would be > copied on a case by case basis by the release team and the images > rebuilt afterwards. This sounds exactly like a freeze. You upload a package and it doesn't land in the distro for a week. That's a serious drag on velocity, and I don't see that it buys us anything but lost productivity and busy work as I described in my initial mail. The essential point is, Ubuntu should be good every day. There should be nothing special about an alpha or beta, it's simply the daily image on some chosen day. Making them special doesn't buy us anything, but has costs. > > That'd essentially allow any non-seeded package to still flow to the > release pocket and be available for everyone. > All the others will be available for people running with -proposed > enabled or will be available when we manually copy them to the release > pocket or right after we release the milestone and we copy everything > left in -proposed to the release pocket. I thought it was specifically an anti-goal for people to run proposed during the development release. It would just expose developers to all the problems that we have without having proposed at all, and furthermore means that some developers are using proposed, while others aren't, splitting attention and sewing confusion. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
On 06/15/2012 10:12 AM, Rick Spencer wrote: > Hello all, > > At UDS I had some "hallway discussions" about why we freeze for Alphas > and Betas, and the fact that I think it is time to drop this practice > and rather focus on making Ubuntu good quality each day. Sadly, there > was no session on this, thus this email to this list for discussion. > > I think it is time drop our "Freeze" practices for the alphas and > betas. Here is my reasoning: > > 1. We are developing tools that allow us to efficiently use -proposed > in a way that will ensure we will not have partially built or > incompatible components in the release pocket ... ever. Including days > we release Alphas and Betas: > > These blueprints tools to ensure that Ubuntu is not uninstallable or > have other problems due to partially built components and such: > https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upload-intermediary > https://blueprints.launchpad.net/ubuntu/+spec/other-q-freeze-use-of-proposed > > I have been assured that the tools necessary to automate the work of > moving components correctly from -proposed to the release will be > ready before Alpha 2. > > 2. We are investing heavily in the daily quality of Ubuntu. For example ... > We run the same automated tests on an alpha as we run on a daily: > https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/ > > We tend to archive issues each day: > http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html > > We ran all the manual ISO tests *before* we released Alpha 1, and we > have the capability of doing this at will: > http://iso.qa.ubuntu.com/qatracker/milestones/221/builds > > 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. > > AIUI, A1 was delivered in such a manner, though without the tooling to > ensure that moving from -proposed to the release pocket was efficient > and automated. > > Cheers, Rick Hi Rick, We certainly want to allow people to upload stuff to -proposed during a milestone week, but I don't agree that we should automatically copy from -proposed to the release pocket during a milestone week. We usually try to release all our images with the same versions of the packages, considering it takes us hours to rebuild everything, having seeded packages land during that time, will lead to images having different version of packages. As for what happened with Alpha 1, we simply asked everyone to upload their packages to -proposed and then cherry picked the packages we actually needed for the release from -proposed and copied them into the release pocket before rebuilding the images (we did that 3 times). As I understand it, the plan going forward is to have the release pocket be an alias of -proposed on upload, so that everything always lands into -proposed. After something lands in -proposed, is properly built and passes whatever other criteria we'll have, the package will be automatically copied to the release pocket. That last part (copy to the release pocket) would be what we'd block during a milestone week for any package that's seeded. These would be copied on a case by case basis by the release team and the images rebuilt afterwards. That'd essentially allow any non-seeded package to still flow to the release pocket and be available for everyone. All the others will be available for people running with -proposed enabled or will be available when we manually copy them to the release pocket or right after we release the milestone and we copy everything left in -proposed to the release pocket. -- 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
Releasing Alphas and Betas without "freezing"
Hello all, At UDS I had some "hallway discussions" about why we freeze for Alphas and Betas, and the fact that I think it is time to drop this practice and rather focus on making Ubuntu good quality each day. Sadly, there was no session on this, thus this email to this list for discussion. I think it is time drop our "Freeze" practices for the alphas and betas. Here is my reasoning: 1. We are developing tools that allow us to efficiently use -proposed in a way that will ensure we will not have partially built or incompatible components in the release pocket ... ever. Including days we release Alphas and Betas: These blueprints tools to ensure that Ubuntu is not uninstallable or have other problems due to partially built components and such: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upload-intermediary https://blueprints.launchpad.net/ubuntu/+spec/other-q-freeze-use-of-proposed I have been assured that the tools necessary to automate the work of moving components correctly from -proposed to the release will be ready before Alpha 2. 2. We are investing heavily in the daily quality of Ubuntu. For example ... We run the same automated tests on an alpha as we run on a daily: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/ We tend to archive issues each day: http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html We ran all the manual ISO tests *before* we released Alpha 1, and we have the capability of doing this at will: http://iso.qa.ubuntu.com/qatracker/milestones/221/builds 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. AIUI, A1 was delivered in such a manner, though without the tooling to ensure that moving from -proposed to the release pocket was efficient and automated. Cheers, Rick -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Patch Pilot Report 20120615
Hi Daniel On 15/06/12 13:31, Daniel Holbach wrote: > On 15.06.2012 14:08, James Page wrote: >>> SRU's which have been uploaded but not accepted are hard to >>> differentiate on the report - they don't require any further >>> sponsor action so it would be good to be able to filter those >>> out if possible. > That's a good point. I usually set the bug to 'fix committed', > subscribe myself and unsubscribe ubuntu-sponsors, so I can follow > up if necessary. > > Maybe this could be clearer on > https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews? I don't think this is a challenge with bugs (although it could be more explicit in the Code Review docs). Merge proposals create more of a challenge as I'm unable to set 'Fix Committed' in the same way so they just lurk around until they get 'Merged' which could take some time. Not sure we can do to much about that. -- James Page Ubuntu Core Developer Debian Maintainer james.p...@ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Patch Pilot Report 20120615
Hello, On 15.06.2012 14:08, James Page wrote: > SRU's which have been uploaded but not accepted are hard to > differentiate on the report - they don't require any further sponsor > action so it would be good to be able to filter those out if possible. That's a good point. I usually set the bug to 'fix committed', subscribe myself and unsubscribe ubuntu-sponsors, so I can follow up if necessary. Maybe this could be clearer on https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews? Have a great day, Daniel -- Get involved in Ubuntu development! developer.ubuntu.com/packaging And follow @ubuntudev on identi.ca/twitter.com/facebook.com/gplus.to -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot Report 20120615
Report for my patch piloting today: https://code.launchpad.net/~veger/ubuntu/quantal/jsch/fix-for-803492-v2/+merge/104706 - Made minor tweak to OSGi manifest for new upstream release and uploaded. https://code.launchpad.net/~gandelman-a/ubuntu/precise/openldap/proposed-rebuild/+merge/104814 - Checked bug report for SRU details (now present). Changelog entry still needs to be more verbose and versioned Build-Depends in not present - provided further feedback to proposer. https://code.launchpad.net/~smoser/ubuntu/precise/tgt/lp977621-start-on-install/+merge/101321 - Already uploaded elsewhere - requested rejection of MP in -devel. https://bugs.launchpad.net/ubuntu/+source/nova/+bug/989241 https://bugs.launchpad.net/ubuntu/+source/nova/+bug/989242 - Pushed debdiff to the folsom-proposed branch that feeds the OpenStack CI environment and is the basis for the next archive upload. Unsubscribed Ubuntu Sponsors. https://code.launchpad.net/~takluyver/ubuntu/quantal/python-tz/merge-py3/+merge/105551 - Already uploaded - marked as 'Merged'. https://bugs.launchpad.net/ubuntu/+source/munin/+bug/598385 - Unsubscribed sponsors - nothing todo at this point in time. https://code.launchpad.net/~logan/ubuntu/quantal/keystone/fix-for-998991-and-new-upstream/+merge/109963 - Provided feedback to proposer about how new upstream releases of openstack components are managed by the server-dev team. Asked them to re-submit the branch as the bug fix is OK still. Marked WIP. https://code.launchpad.net/~racb/ubuntu/precise/modsecurity-apache/988819/+merge/109378 https://code.launchpad.net/~racb/ubuntu/precise/apache2/988819/+merge/109379 - Already uploaded to -proposed for SRU testing - not sure how to make these disappear from the sponsoring report. https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/951343 - Proposed merges for linked branches and un-subscribed sponsors from main bug. https://code.launchpad.net/~christopherarges/ubuntu/precise/nss-pam-ldapd/nss-pam-ldapd/+merge/110491 https://code.launchpad.net/~christopherarges/ubuntu/oneiric/nss-pam-ldapd/nss-pam-ldapd/+merge/110492 - Both merges lacking sufficient changelog detail and incorrect version numbers - provided feedback and set to WIP. https://bugs.launchpad.net/ubuntu/+source/redis/+bug/1009767 - Nothing for ubuntu-sponsors TODO - unsubscribed. Pending mentor upload in Debian. https://bugs.launchpad.net/ubuntu/+source/libvdpau/+bug/1010920 - Merged OK - uploaded https://code.launchpad.net/~gandelman-a/ubuntu/quantal/netcat-openbsd/merge/+merge/108072 - Already merged - marked appropriately. https://bugs.launchpad.net/ubuntu/+source/libglib-perl/+bug/935525 - Removed task for precise - not appropriate; Reporter already asked to submit to Debian; unsubscribing ubuntu-sponsors as no further action required. https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/1003535 - Uploaded and synced from Debian already - marked 'Fix Released' with comment. https://bugs.launchpad.net/ubuntu/+source/ginn/+bug/769959 - Uploaded https://code.launchpad.net/~geoubuntu/ubuntu/precise/gnomeradio/1004761/+merge/107506 https://bugs.launchpad.net/ubuntu/+source/gnomeradio/+bug/1004761 - Already uploaded to -proposed - added comment to bug report to re-iterate requirement for SRU documentation. https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1004018 - Un-subscribed ubuntu-sponsors - no action currently required. https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/1006565 - Checked with cjwatson this was OK (new upstream release) tested and uploaded. https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1011708 - Not actually a bug; responded to reporter and thanked the contributor for preparing the patch but its not required. https://code.launchpad.net/~kroq-gar78/ubuntu/precise/mod-proxy-html/fix-1005425/+merge/109766 - Added an extra comment about the apache2 change already in -proposed which enables this to be fixed. https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-1007408/+merge/110498 - Uploaded. Comment for the day: SRU's which have been uploaded but not accepted are hard to differentiate on the report - they don't require any further sponsor action so it would be good to be able to filter those out if possible. Cheers James -- James Page Ubuntu Core Developer Debian Maintainer james.p...@ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
