Re: Requesting help/no response to pings
Hey Erich. I will of course handle the SRU, that is one of my priotity items for today. And I also noticed the inability of rebuilding studio, I saw the build being stuck on Rebuild. I will look into the tracker today as well. Sadly I am and will be working with limited capacity for a while with this broken hand. Using the mouse or keyboard takes three times longer for me. Cheers, On Tue, 27 Aug 2024 at 01:20, Erich Eickmeyer wrote: > > Hi release team and archive admins! > > For at least the past week, I and others have been pinging/highlighting > ubuntu-archive and ubuntu-release in #ubuntu-release on IRC trying to > get a response for help. Here are some examples: > > * I am unable to do an ISO rebuild request from the ISO tracker (this > has never occurred before), I suspect an issue with cdimage, but > this needs release team attention. > * Kubuntu and Ubuntu Studio are still in the process of transitioning > to Plasma 6 for Oracular, and are blocked by packages needing > removal [1]. > * Ubuntu Studio's oracular builds are failing due to a preinst script > error in the usbmuxd package and I cannot figure out why since they > are *not* failing in Kubuntu, so I have been requesting assistance. > * Ubuntu Studio has an ongoing SRU for users to be in the audio group > by default[2] with an adduser wrapper, targeted for 24.04.1 this > Thursday. While the SRU team is involved, this needs to be expedited > for the release. > * Many others have had requests for package removals, FFes, and other > requests have been done in #ubuntu-release and have gone completely > unanswered/unacknowledged, including an FFe by Rico Tzschichholz for > LibreOffice 24.8.x for oracular [3]. > > These are just examples that I know off the top of my head because they > affect my projects, but there have been plenty more. I understand you've > all been busy this cycle, and we've all heard radio silence on IRC for > more than a week. However, since many of these are time-sensitive asks, > I wanted to ask, perhaps on behalf of the rest of the community, if > there's a better way to request assistance than IRC these days? We all > very much need answers and acknowledgements on these issues. > > Thanks in advance! > Erich > > [1] https://launchpad.net/bugs/2077506 > [2] https://launchpad.net/bugs/2063899 > [3] https://launchpad.net/bugs/2077516 > > -- > Erich Eickmeyer > Ubuntu MOTU > Project Leader - Ubuntu Studio > Technical Lead - Edubuntu > > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Ubuntu Budgie August release duties for 22.04 and 24.04
Hey David! I can make sure that happens. However, I see that Mauro isn't part of the ubuntubudgie-dev. I would prefer if he was when picking up such responsibility. Cheers, On Thu, 8 Aug 2024 at 14:13, David Mohammed wrote: > > Hi all, > > this is a quicknote to say that fellow team members Sam Lane and > Mauro Gaspari will be undertaking all Ubuntu Budgie release duties for > both the 22.04 and 24.04 releases in August > > Sam is available via samlane on IRC #ubuntu-release. Both Mauro and > Sam are pingable via matrix 'ubuntu flavors' > > Can I also ask that Sam & Mauro be granted the right to confirm the > release on https://iso.qa.ubuntu.com/qatracker - many thanks in > advance. > > cheers > > David (Project Lead) > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Lubuntu LTS Requalification: 24.04 Noble Numbat
Hey Simon! Your LTS requalification application checks out so I'm fine with starting a Technical Board vote on this. My vote is of course +1. Other TB members please vote as well! Regarding your comments and concerns: I'm sorry you had to go through these various frustrating situations before end-of-year. I agree: we all need to communicate more, communicate better. It's certainly something we need to get better at - especially all the Ubuntu teams at Canonical. That being said, I don't think this is anything the technical board can help per-se. With my release team and archive admin hats on the only thing I can say is that I'll try improving my throughput regarding reviews this cycle. Around EOY is a very disruptive time, especially after such a busy year as 2023. Thank you and the Lubuntu team for all your hard work! Hoping for the vote to finish soon. Cheers, On Wed, 3 Jan 2024 at 04:56, Simon Quigley wrote: > > On behalf of the Lubuntu Team, and in my capacity as Lubuntu Release > Manager, this is our application for Long-Term Support requalification > for 24.04 (Noble Numbat). > > * The Lubuntu Team currently has five active developers[1] with upload > permissions to the Lubuntu packageset. Two of those developers are also > Ubuntu Core Developers (and one of them is a Debian Developer, who is on > the Debian Qt/KDE Team). Over several LTS cycles, we have proven that we > are willing and able to handle Stable Release Updates to `lubuntu` > packages. Our developers have also committed bug fixes upstream in LXQt, > Calamares, KDE, Qt, and core Ubuntu tooling so everyone can benefit. > Several examples include Calamares, our update notifier, and SDDM. > Therefore, we commit to providing bug fixes for 24.04, until 2027. > * Lubuntu has a Members team[2] with *ten* active members. The > difference between Ubuntu Members and Lubuntu Members are, Lubuntu > Members are only *active* contributors to Lubuntu, within the last year > (members have to explicitly renew with the Lubuntu Council, and it is > simply an activity check). These members provide support via multiple > avenues[3]. Most notably, in real-time we offer support via IRC, Matrix, > Discourse[4], and Telegram. The Lubuntu support channels are bridged to > reach a wider audience. Additionally, many of our members also assist in > other Ubuntu support avenues such as Matrix, IRC and Ask Ubuntu. > Therefore, we commit to providing support and a welcoming community for > 24.04, until 2027. > * In addition to developers, our Members also perform QA testing > throughout not only Lubuntu but all of Ubuntu. Several Lubuntu testers > are on top on the charts (the current #1 position is held by a (very > recently former) Lubuntu Member). They catch many bugs in the > development cycle before they appear in a stable release, following an > extensive checklist. After the release, our QA testers routinely test to > ensure stability. Therefore, we commit to testing for 24.04, until 2027. > * Our documentation team provides our fantastic manual which is > frequently referenced not only for Lubuntu but other distributions that > utilize LXQt. We currently provide the manual for both the current > stable interim release[5] and the LTS release[6]. We take the user from > download to installation to using every piece of software installed by > default. Therefore, we commit to providing documentation for the > upcoming LTS release for 24.04, until 2027. > * Our support lifespan is listed on every download on our downloads[7] > page and an easy to reference graph is at the bottom of the page. > Additionally, our support cycle is documented in every release > announcement posted on our blog[8] and is also linked in every Ubuntu > release note. > > Notes from the Release Manager > -- > > Lubuntu is the strongest it has been since our transition to LXQt in the > 18.10 cycle. Besides our technical goals, we aim to set an example by > training and maintaining impactful and meaningful contributors. As the > most active flavor team, we take great pride in our work, and aspire to > do our best, not just for Lubuntu, but for the wider community. We > recognize the sometimes-controversial technical decisions we make as a > flavor, and aim to minimize their impact on others, while improving the > story for our users. We may not agree on certain elements, such as Qt > being the best UI toolkit, but let me be clear: we are still an Ubuntu > flavor, and wish to be for a long time to come. We are a part of the > same family. > > For every Thursday through Monday following a release, I specifically > instruct all Lubuntu Members to take the weekend off, and do something > they enjoy. Whether it is enjoying a nice meal for the occasion, going > to a party, reading the book they finally want to read, having a great > cup of tea, whatever "floats their boat," go do it. I will take care of > any post-release housekeeping items. It is importa
Re: discontinuing source ISOs?
Hey Michael! I basically +1 what Steve said. To add a bit more to this, the current source-iso machinery doesn't take snaps into consideration, so the resulting isos weren't fully compliant anyway - especially after we adopted so many snaps on our images. The source iso codebase was in general unmaintained. I remember Laney once tried refactoring it to key on amd64 but that actually broke things even more, so we decided not to touch it if not needed. I think archive snapshotting is a much better solution in overall, or at least pointing people to the manifest + lists files as a means of source retrieval. Maybe even offer a tool that would consume a manifest + list file to download all the sources if needed. I feel like it's the right way to go. I'm not really knowledgeable about the licensing compliance bits here of course, but I'm sure we can achieve that in a better way than having to provide 6+ isos with source content, which in my opinion nowadays wasn't very useful anyway. Cheers, On Thu, 4 Jan 2024 at 05:55, Steve Langasek wrote: > > On Thu, Jan 04, 2024 at 04:41:43PM +1300, Michael Hudson-Doyle wrote: > > Hello release team, > > > In the course of recent refactorings of ubuntu-cdimage / debian-cd we > > somehow broke the building of source ISOs. I doubt this is anything very > > deep and can surely be fixed but there is another option: stop building > > source ISOs. > > > AFAIU the point of a source ISO is GPL-compliance: if you are hosting an > > ISO made out of GPL-licensed components you should really also host the > > source of those components. However, we put source ISOs on cdimage (e.g. > > https://cdimage.ubuntu.com/source/20231011.1/source/) not releases, so > > everyone (?) who mirrors the ubuntu ISOs for us does not mirror the source > > ISOs. > > > As our mirror operators have been working this way for approximately 20 > > years without issue, perhaps it's time to stop making source ISOs and > > delete even more code from debian-cd and ubuntu-cdimage. > > > WDYAT? > > As you know, I'm a fan of this. > > In principle, source images are useful for ensuring the distributors of our > install images are complying with the terms of the GPL. But this is only > true if they are *actually distributed together*, or if the source image is > somehow useful for a distributor to rely on for the "written offer" option > under the GPL. > > As you point out, the image files are not being distributed together. > Mirrors of releases.ubuntu.com don't get these source ISOs; and where > community flavors are running their own mirrors, AFAIK they aren't including > the source ISOs. So if they're not being distributed together, the ISOs are > no better than pointing at the apt archive for source (possibly with an > appropriate index - which we do as a matter of course archive as part of > point releases, so that it is possible to correctly reconstruct the list of > required source packages + versions for point release images as well, not > just GA images). > > And we ourselves long ago stopped distributing physical CDs, and I'm not > aware of anyone else doing so - and if someone does, I think it's unlikely > that they are also distributing > https://cdimage.ubuntu.com/releases/mantic/release/source/ on 6 DVDs! This > just isn't a useful structuring of corresponding-source-for-image anymore, > because we try to include the source for all flavors, and there are a lot > more flavors than there were when source ISOs started being built; yet we've > had zero bug reports from anyone asking to make these source ISOs more > useful. > > And as far as OEM preinstalled systems are concerned, well - those systems > use customized install media, so the "mainline" Ubuntu source ISOs don't > satisfy the "corresponding source" requirement there either. > > So I think in practice, the source ISOs are not useful in their current > state, haven't been for a long time, and therefore we should stop producing > them. > > > And as to whether there are costs in maintaining these: we basically only > build source ISOs once or twice every release cycle, so the machinery to do > so is very much the opposite of well-oiled. After the 23.10.1 respin of the > Ubuntu Desktop images, I found that the source ISOs appeared to have become > un-published, and I found it incredibly difficult to even work out the > correct invocation of the commands that would allow me to re-publish the > existing ISOs. debian-cd didn't even enter into it, I was just trying to > drive ubuntu-cdimage to re-publish the previously built images... > > Dropping the source ISO builds from the release process (and not having to > continue supporting them in the code) would be very nice. > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com
Re: latest Ubuntu LTS download link
Hey! It should work for the cdimage releases as well, for instance: http://cdimage.ubuntu.com/releases/jammy/release/ubuntu-22.04-latest-live-server-arm64.iso Those are redirects so they are not listed anywhere. We only added them to fix a casper PXE boot issues while retrieving images from the network. Indeed it wasn't properly announced, but yes, tooling can rather reliably use this at least for jammy+ series. The older ones do not have the redirects in place as the change is fairly recent. Cheers, On Mon, 4 Dec 2023 at 19:16, Jeremy Bícha wrote: > > On Mon, Dec 4, 2023 at 1:04 PM Lukasz Zemczak > wrote: > > > > Hey Jeremy! > > > > We already have something like that. There are automatic redirects set > > up to > > https://releases.ubuntu.com//ubuntu--latest-desktop-amd64.iso > > on cdimage, for instance: > > > > https://releases.ubuntu.com/jammy/ubuntu-22.04-latest-desktop-amd64.iso > > This feels like a secret because that link does not show at > https://releases.ubuntu.com/jammy/ > > For reference, > https://releases.ubuntu.com/jammy/ubuntu-22.04-latest-live-server-amd64.iso > works too > > Do similar links exist for the alternate architecture server ISOs at > https://cdimage.ubuntu.com/ubuntu/releases/jammy/release/ ? > > Thank you, > Jeremy Bícha -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: latest Ubuntu LTS download link
Hey Jeremy! We already have something like that. There are automatic redirects set up to https://releases.ubuntu.com//ubuntu--latest-desktop-amd64.iso on cdimage, for instance: https://releases.ubuntu.com/jammy/ubuntu-22.04-latest-desktop-amd64.iso And every release sets up the -latest- redirect automatically. We cannot use the -22.04- version numbers as the redirect as this is the version number we release as GA, meaning that at some moment checksums of this file will change - which is not something people would expect. But we set up the -latest- redirects for this purpose. Those are redirects so the end filename should be the actual point-release name, so easy to check checksums for etc. Cheers, On Mon, 4 Dec 2023 at 18:57, Jeremy Bícha wrote: > > The GNOME Boxes app has a "Download OS" feature where it can download > distro releases such as Ubuntu 22.04 LTS. This is powered by osinfo-db > which includes a download URL field. > > However, this feature breaks every time there is a new Ubuntu LTS > point release. For example, a few months ago, the 22.04.2 ISOs were > removed from https://releases.ubuntu.com/22.04/ and replaced with > 22.04.3 ISOs. > > Is it possible to add symlinks there so that there is an official > stable URL for the latest Ubuntu 22.04 LTS desktop amd64 ISO? > > Thank you, > Jeremy Bícha > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: ubuntu-advantage-tools SRU exception policy review
I have checked the newly added section regarding the Feature Freeze exception not applying (but other freezes, such as Beta Freeze, still do) and it all seems to make sense to me now. I think the wording is clear enough regarding the intentions. As I think Steve's concerns have been addressed, I'm signing this off on behalf of the Ubuntu Release Team. On Mon, 27 Nov 2023 at 12:25, Christian Ehrhardt wrote: > > > > On Sat, Nov 25, 2023 at 5:12 AM Steve Langasek > wrote: >> >> On Mon, Oct 23, 2023 at 04:26:53PM +0200, Christian Ehrhardt wrote: >> > > I have been reluctant to sign off on this as written because it could be >> > > taken to imply that all freezing in the development cycle is ignorable >> > > for >> > > these purposes. >> >> > As you can imagine that was not the purpose, good call to straighten that >> > before approval. >> > OTOH I do not want this to cause yet another 4 month detour, so let me try >> > to make a suggestion below. >> >> > > While FeatureFreeze starts out fairly relaxed, as we >> > > progress to the end of the development cycle the Release Team >> > > deliberately >> > > becomes more and more strict on exceptions until, around 3 weeks before >> > > release, the actual freeze is STRICTER than the requirements for SRUs >> > > with >> > > the simple rationale that unlike a bad SRU, we cannot roll back a bad >> > > freeze >> > > exception that finds its way into the release pocket and onto a release >> > > image if the breakage is discovered too late. >> >> > You are right, there is some freezing and deep freezing here :-) >> > We already have this statement in the document: >> >> > "However, beta freeze and final freeze will still apply in order to manage >> > risk in the release itself." >> >> > And of those, while Beta itself is short, it starts the mentioned ~3 strict >> > weeks before release. >> > If we'd just extend that statement to something like the following, do you >> > think that would work or do you expect wider modifications? >> >> > "However, beta freeze and final freeze will still apply in order to manage >> > risk in the release itself. In fact we consider the intentionally more >> > conservative three week period from beta freeze to release one that we can >> > not just ignore, we might have uploads but would expect them to be part of >> > the same scrutiny any upload gets at that time." >> >> I propose the following modified language, which I think captures the intent >> as simply as possible: >> >>Since these feature changes may land in stable releases at any time, >>adhering to feature freeze during the development cycle would be >>counterproductive as those changes would be forced to land after release >>instead. Therefore, feature freeze will not apply when the changes are in >>scope of this document. However, from beta freeze on uploads of this >>package will be subject to the same additional scrutiny by the Release >>Team as any other package. > > > That works perfectly fine for us. > The rest of [1] was already in the state that was discussed and agreed so > far, therefore I updated the paragraph in [1] to use your words and this > should now be complete. > > [1]: https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates > >> > But this all falls under "FeatureFreeze", we don't have any separate freeze >> > > checkpoints to externally communicate this gradual ratcheting, it's >> > > instead >> > > a judgement call by the Release Team. >> > > >> > > So by saying the feature freeze does not apply, I don't want to wrongly >> > > give >> > > an impression that these other issues are automatically ignorable, or >> > > that >> > > the Release Team is bound by agreement to ignore them. >> > > >> > > I do not immediately have proposed alternate language that I think >> > > appropriately addresses this concern, but as you've been waiting for a >> > > response for some time now, I wanted to make sure to surface this. (And >> > > apologies for not mentioning it sooner when considering the document, as >> > > I >> > > was focused on considering the proposed exception with an SRU lens at the >> > > time.) >> > > >> > > > Reference document: https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates >> >> Thanks, >> -- >> Steve Langasek Give me a lever long enough and a Free OS >> Debian Developer to set it on, and I can move the world. >> Ubuntu Developer https://www.debian.org/ >> slanga...@ubuntu.com vor...@debian.org > > > > -- > Christian Ehrhardt > Director of Engineering, Ubuntu Server > Canonical Ltd > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ub
Re: Status of the Noble archive opening
Hey Seb! I agree we should probably find a better way to make this process a bit more visible, maybe making sure that the engineer responsible for driving the opening gives regular updates somewhere. Maybe something like a tracking post on discourse, like what we have for releases. For now I recommend keeping track of the Release Team Planning Jira card: https://warthogs.atlassian.net/browse/RTMP-1274 Also, this board is publicly readable, even for those that are not logged in on Jira. So it should mean that it *IS* openly accessible. If it isn't, then that's a bug. But I was able to open this card in an incognito browser tab. Cheers, On Wed, 25 Oct 2023 at 11:09, Sebastien Bacher wrote: > > Dear Release Team, > > Would it be possible to have some status update on the Noble archive > opening? > > In the past days I've seen a bunch of people asking on Ubuntu IRC > channels (and I also got some direct messages) about 'when will the > archive open'/'can we upload yet'/'when will autosyncs start'. > Having the information would help people to plan their work and organize > better. > > We used to have a public checklist about the opening tasks and on some > occasion even emails on what to expect as this one > https://lists.ubuntu.com/archives/ubuntu-devel/2019-October/040817.html > > It would also be nice if we managed to find a way to make the process > more open again. Even with access to the board currently used (which > isn't openly accessible) I'm unclear on whether we are waiting on > toolchains changes/which ones/how long it will take and such I'm not > able to help people asking. > > Thanks, > Sébastien Bacher > > > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Mantic Minotaur (to be 23.10) Beta Freeze
As of now, mantic has entered the Beta Freeze, with a goal of releasing Beta images sometime late Thursday. *From now until the Beta is released, please only upload updates for packages on any release images if you /need/ to get them into the Beta itself.* Please hold off with everything else until after we release on Thursday. The queue freeze will last from now until the final release next month, which means that all seeded packages will now need a spot-check and review in the queue from a release team member before they are let into the archive. As with the previous releases, we have a bot in place that will accept uploads that are unseeded and don't affect images. Don't take this as an open invitation to break Feature Freeze on those components, this is just to reduce the burden on the release team, so we only review the uploads that need very serious consideration. If you find the bot is blocking an upload that you think should have been auto-accepted, let us know and we'll sort it out. We will be spinning a set of Beta candidates in the next 12 hours or so. We then encourage people to start testing ASAP for their favourite flavour(s) as they come off the line. Happy bug-hunting from now until the final release, and please do help out and test images, etc, where you can and let us know what's broken in your environment(s). As a reminder, the Beta images will appear on the ISO Tracker here: http://iso.qa.ubuntu.com/qatracker/milestones/448/builds On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: SRU bug references in upstream version bumps
I must say that I was certainly inconsistent in my approach here, requesting one of 2) or 3) depending on the particular package in mention. I'd say that my personal preference would be 2), and this is what I in general tried to push for in some cases. If someone decides to backport a new upstream version from a later series and decides to just do a 1:1 package backport, I think it's fair to also expect double-checking if the bugs attached to the upload are verified. More testing is something that's never a bad thing per-se. And if the exception for the new upstream release/backport has an extensive test-case that would potentially also already test the given scenario, those additional SRU bug reports can be then marked as verified quite easily. Since my thinking is: if someone doesn't think the bugs should warrant verification, they should not be included in the .changes file. However, there were times where I was doing 3), especially for big beefy backports like toolchain updates, as those have a big turnaround in preparation of the SRU packages (some are bin-copies). In those cases some of the 'additional' SRUs were hard to formulate into SRU bugs - and the verification for the toolchain itself would be good enough there. So I have no strong preferences, and to some degree I think 2) and 3) are quite alike, so any of those two would be my option. Cheers, On Sun, 18 Jun 2023 at 23:19, Michael Hudson-Doyle wrote: > > > > On Sat, 17 Jun 2023 at 00:30, Robie Basak wrote: >> >> In the case of an SRU using some kind of exception to bump to a newer >> upstream version (whether that's a microrelease, a feature changing >> major release or a backport of something) we can end up with: >> >> 1. Some kind of tracking bug that explains the exception, for which the >> SRU team agrees a QA process that doesn't require SRU verification of >> individually fixed bugs. >> >> 2. Some bugs that we're tracking in Launchpad that nevertheless will be >> fixed by the upload, but don't actually need individual verification >> because of the previous point. >> >> I've seen some inconsistency in how these are handled by SRU team >> members. I think we could save effort all round by clarifying this. >> >> Some options are: >> >> 1) Require that the second class of bugs are not referenced in a way >> that results them ending up in Launchpad-Bugs-Fixed. This way the >> pending-sru report won't mention them, and the SRU team won't expect >> them to be verified. >> >> 1b) Reference them but hack Launchpad-Bugs-Fixed to remove them again >> before signing and uploading. >> >> 2) Reference them normally but then require or expect that the bugs are >> verified anyway, even though that's not strictly necessary because of >> the agreed QA process as part of the exception. >> >> 3) Reference them normally but then just mark them >> verification-done- with an explanation that individual >> verification wasn't necessary as part of the exception. >> >> The downside of 1 is that they we don't get the auto-close function and >> we're effectively providing wrong metadata for the sake of an >> unnecessarily rigid SRU process. Except in the case of 1b, developers >> and users investigating the changelog won't get the benefit of the >> missing references. > > >> >> For 1b it's only automation that is likely to >> suffer from that latter issue. > > > Launchpad has code at least to parse the changelog for bug references as well > as looking at the changes file -- although I can't quickly understand which > gets used when -- so there is a chance having those be inconsistent may be > confusing. > >> >> The downside of 2 is that this creates unnecessary extra work for >> uploaders. >> >> The downside of 3 is that this could be confusing initially, except that >> hopefully the explanation will help? It's certainly obtuse regardless. >> >> IMHO, 3 is the least-worst option. > > > I agree. > > Cheers, > mwh > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [Cpc-gcp] Re: Seeking new Stable Release Update exceptions for Google cloud image agent packages - further amendments
Hey Phil! That sounds good to me. I would like for the team to try finding the changes lists for those vendored updates as frequently as possible, only missing out on them when it's really non-trivial to get this changeset. Please note that depending on the contents of the changelogs the SRU team might request additional testing! Please proceed. Cheers, On Tue, 11 Apr 2023 at 17:20, Phil Roche wrote: > > > This feels sensible to me. Do you have any proposal for the amendments > > to the MREs for the Google cloud packages? > > Yes your suggestions make sense > > I propose that the following policies > > * https://wiki.ubuntu.com/gce-compute-image-packages-Updates > * https://wiki.ubuntu.com/google-compute-engine-Updates > * https://wiki.ubuntu.com/google-compute-engine-oslogin-Updates > * https://wiki.ubuntu.com/google-guest-agent-Updates > * https://wiki.ubuntu.com/google-osconfig-agent-Updates > > be updated stating that if any of the vendored dependencies have changed in > the process of updating this package then: > > * Details of vendored package version changes are present in the SRU bug > * If possible, links to changelogs for the vendored packages are also present > in the SRU bug > > Would this be sufficient? > > Phil > > On Tue, 11 Apr 2023 at 16:07, Lukasz Zemczak > wrote: >> >> Hey Phil, Utkarsh, >> >> This feels sensible to me. Do you have any proposal for the amendments >> to the MREs for the Google cloud packages? >> I think it would be good if we required outlining the vendored package >> version changes in the SRU template, at least for documentation >> purposes. At least listing the changes of those vendor packages - >> maybe even a link to the changelogs, if possible. The latter might or >> might-not be difficult, so I wouldn't consider it a hard requirement >> though. >> >> Cheers, >> >> On Tue, 11 Apr 2023 at 16:52, Utkarsh Gupta >> wrote: >> > >> > Hi, >> > >> > On Tue, Apr 11, 2023 at 8:05 PM Phil Roche >> > wrote: >> > > Re-opening this topic seeking an amendment to the Stable Release >> > > Update exceptions for Google cloud image agent packages. >> > > The Google Guest agents are written in golang and have >> > > dependencies vendored. >> > > See https://github.com/GoogleCloudPlatform/guest-agent/blob/main/go.mod >> > > The amendment to the Stable Release Update exception is that the >> > > exception will explicitly cover the updating of the pinned dependencies >> > > too. >> > >> > https://bugs.launchpad.net/ubuntu/+source/google-guest-agent/+bug/1896246 >> > >> > This exists and was signed off in the past. I just want to make it >> > explicitly clear and document this so that there are no concerns from >> > the SRU team. :) >> > >> > >> > - u >> > >> > -- >> > Ubuntu-release mailing list >> > Ubuntu-release@lists.ubuntu.com >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release >> >> >> >> -- >> Łukasz 'sil2100' Zemczak >> Foundations Team >> Tools Squad Interim Engineering Manager >> lukasz.zemc...@canonical.com >> www.canonical.com >> ___ >> Cpc-gcp mailing list -- cpc-...@lists.canonical.com >> To unsubscribe send an email to cpc-gcp-le...@lists.canonical.com > > > > -- > Phil Roche > Staff Software Engineer > Canonical Public Cloud -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [Cpc-gcp] Re: Seeking new Stable Release Update exceptions for Google cloud image agent packages - further amendments
Hey Phil, Utkarsh, This feels sensible to me. Do you have any proposal for the amendments to the MREs for the Google cloud packages? I think it would be good if we required outlining the vendored package version changes in the SRU template, at least for documentation purposes. At least listing the changes of those vendor packages - maybe even a link to the changelogs, if possible. The latter might or might-not be difficult, so I wouldn't consider it a hard requirement though. Cheers, On Tue, 11 Apr 2023 at 16:52, Utkarsh Gupta wrote: > > Hi, > > On Tue, Apr 11, 2023 at 8:05 PM Phil Roche wrote: > > Re-opening this topic seeking an amendment to the Stable Release > > Update exceptions for Google cloud image agent packages. > > The Google Guest agents are written in golang and have > > dependencies vendored. > > See https://github.com/GoogleCloudPlatform/guest-agent/blob/main/go.mod > > The amendment to the Stable Release Update exception is that the > > exception will explicitly cover the updating of the pinned dependencies too. > > https://bugs.launchpad.net/ubuntu/+source/google-guest-agent/+bug/1896246 > > This exists and was signed off in the past. I just want to make it > explicitly clear and document this so that there are no concerns from > the SRU team. :) > > > - u > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Ubuntu Cinnamon for Official Flavor Status
Hey Joshua! I'm happy to inform you that, per the Technical Board votes seen above (and confirmed on today's TB meeting), Ubuntu Cinnamon has become an official Ubuntu flavor! Welcome to the family! Best regards, On Tue, 21 Mar 2023 at 10:26, Robie Basak wrote: > > On Thu, Mar 16, 2023 at 04:29:29PM +0100, Lukasz Zemczak wrote: > > Would it be possible for us to perform the vote online, via the ML? > > I'd appreciate TB members to participate here with questions or votes. > > From my side, as I already worked on the flavor bits from the > > release-team POV, I am +1 on Ubuntu Cinnamon joining the official > > flavors. > > +1, subject to approval from the Release Team. I appreciate that Steve > and Łukasz are on the release team and have also approved; is that also > the position of the release team as a whole? -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Ubuntu Cinnamon for Official Flavor Status
Hello Technical Board! Would it be possible for us to perform the vote online, via the ML? I'd appreciate TB members to participate here with questions or votes. From my side, as I already worked on the flavor bits from the release-team POV, I am +1 on Ubuntu Cinnamon joining the official flavors. Best regards, On Wed, 15 Mar 2023 at 15:46, Joshua Peisach wrote: > > Hello TB, > > Successful developments have been made. Ubuntu Cinnamon images have been > produced for the past week, and the needed changes to livecd-rootfs and > ubuntu-cdimage are mostly complete. Testcases are being made for the QA > tracker. Additionally, our packages are now in the official archive, our seed > is good, and we are in good shape for 23.04. > > If 23.04 is not approved as an official flavor for Ubuntu Cinnamon, 24.04 > will not be an LTS release, as per the rules (2 non-LTS for 1 LTS). > > I am requesting, as UI freeze approaches, and Beta will soon roll ahead, the > Technical Board’s approval for flavor status. After I send this email, I will > add this item to the Technical Board Agenda. > > As a full-time student, I am busy, but I am okay with voting or discussion > over ML or IRC. > > Thanks, > -Josh > > On Nov 28, 2022, at 12:34 PM, Joshua Peisach > wrote: > > Hello Technical Board, > > I’m Joshua Peisach, the lead of the Ubuntu Cinnamon Remix > (https://ubuntucinnamon.org, https://twitter.com/UbuntuCinnamon). For almost > three years now, the Ubuntu Cinnamon Remix team have maintained Ubuntu > Cinnamon through seven releases since 19.10. We have also maintained the > project through contributing to security uploads relevant to Cinnamon (see > caribou CVE-2021-3567), and have been maintaining Cinnamon in Debian with > Fabio Fantoni and the Debian Cinnamon Team. > (https://salsa.debian.org/cinnamon-team) > > Considering the amount of time that has passed, the current relationship with > Ubuntu Cinnamon and the Ubuntu community, we are applying for official flavor > status, starting with our 23.04 “Lunar Lobster” release. (Proposal: > https://wiki.ubuntu.com/UbuntuCinnamon/23.04/Proposal) > > We have many people on the team, along with several MOTUs. Other than myself, > fossfreedom has helped us with maintenance of the Nemo file manager, Jeremy > Bicha, Simon Quigley and Erich Eickmeyer are all MOTU’s for our uploads, and > I am also talking with Aaron Rainbolt as we both continue our Ubuntu journey > together. We also have worked with Phillipp and Monica from the Community > Team, all current existing leads (especially rs2009, Martin Wimpress and Rik > Mills), and work with the Yaru team towards maintaining Cinnamon theme > support. There is also Initu Castilhos, who has also helped with the > ‘Cinnamon’ color variant of the Yaru theme. There are plenty of developers > and contributors that will ensure Ubuntu Cinnamon Remix remains stable with > high quality assurance. > > I am looking forward towards the application process, and official flavor > status. > > Our launchpad team: https://launchpad.net/~ubuntucinnamon-dev > Our GitHub: https://github.com/Ubuntu-Cinnamon-Remix > > Thanks, > -Josh > > -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: oem-meta-packageset-sync broken and spamming devel-permissions@
Hey!
This was reported to me on IRC a few hours ago and I have then
disabled the job temporarily. The reason is related to the migration
of snakefruit to another host (this is happening on the new host that
we're migrating into).
Cheers,
On Fri, 10 Mar 2023 at 16:49, Robie Basak wrote:
>
> Documentation link:
> https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Canonical_OEM_metapackage_packageset
>
> devel-permissions@ is being spammed every few minutes with this, so I've
> taken the following emergency actions:
>
> 1) I've attempted to filter all emails from
> root@ubuntu-archive-toolbox.internal from reaching devel-permissions@
> using the list admin tools.
>
> 2) Since the agreement is that the DMB (via devel-permissions@) is
> notified of all changes to the canonical-oem-metapackages packagesets
> and that will no longer work, I attempted to temporarily change the
> owner of these packagesets to ~techboard to effectively disable the
> broken script being able to take any action until such notifications are
> fixed again. However, this didn't work since (I assume) I'm not a member
> of ~ubuntu-archive and to change the owner would need the person making
> the change to be a member of both teams.
>
> 3) So instead I temporarily disabled the _effect_ of the packagesets by
> removing ~canonical-oem-metapackage-uploaders from the packageset ACLs,
> which I do have permission to do.
>
> So right now the entire mechanism is temporarily disabled.
>
> Could someone in ~ubuntu-archive please:
>
> 1) Fix the script to make it work again (presumably, reauth it).
>
> 2) Adjust the script so that reports of changes still go to the DMB as
> agreed, but failures get notified to people who can fix it, rather than
> spamming the DMB who cannot.
>
> Once done we can undo the temporarily disablements I described above.
>
> Thanks!
>
> Robie
>
> On Fri, Mar 10, 2023 at 01:15:03PM +, Cron Daemon wrote:
> > The authorization page:
> >
> > (https://launchpad.net/+authorize-token?oauth_token=cfGWvrRnDPJ1QrTbZPlK&allow_permission=DESKTOP_INTEGRATION)
> > should be opening in your browser. Use your browser to authorize
> > this program to access Launchpad on your behalf.
> > Waiting to hear from Launchpad about your decision...
> > Traceback (most recent call last):
> > File
> > "/home/ubuntu-archive/oem-meta-packageset-sync/oem-meta-packageset-sync",
> > line 177, in
> > main()
> > File
> > "/home/ubuntu-archive/oem-meta-packageset-sync/oem-meta-packageset-sync",
> > line 168, in main
> > sync = OEMMetaPackagesetSync()
> > File
> > "/home/ubuntu-archive/oem-meta-packageset-sync/oem-meta-packageset-sync",
> > line 62, in __init__
> > self.lp = Launchpad.login_with("oem-generate", "production", "devel")
> > File "/usr/lib/python3/dist-packages/launchpadlib/launchpad.py", line
> > 564, in login_with
> > return cls._authorize_token_and_login(
> > File "/usr/lib/python3/dist-packages/launchpadlib/launchpad.py", line
> > 375, in _authorize_token_and_login
> > credentials = authorization_engine(credentials, credential_store)
> > File "/usr/lib/python3/dist-packages/launchpadlib/credentials.py", line
> > 600, in __call__
> > self.make_end_user_authorize_token(credentials, request_token_string)
> > File "/usr/lib/python3/dist-packages/launchpadlib/credentials.py", line
> > 692, in make_end_user_authorize_token
> > self.wait_for_end_user_authorization(credentials)
> > File "/usr/lib/python3/dist-packages/launchpadlib/credentials.py", line
> > 775, in wait_for_end_user_authorization
> > raise TokenAuthorizationTimedOut(
> > launchpadlib.credentials.TokenAuthorizationTimedOut: Timed out after 900
> > seconds.
> >
> > --
> > Devel-permissions mailing list
> > devel-permissi...@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/devel-permissions
> --
> Ubuntu-release mailing list
> Ubuntu-release@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
--
Łukasz 'sil2100' Zemczak
Foundations Team
Tools Squad Interim Engineering Manager
lukasz.zemc...@canonical.com
www.canonical.com
--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: MRE request for Bind9
Thank you for the additional feedback. I think this looks good to go. I would urge to re-enable build-time-tests as soon as possible, since the more automated testing is performed, the more confidence we can have for making sure everything works correctly for the series. If this can be done in one of the upcoming micro-releases, that would be great. In the meantime, let me approve this MRE and add it to the process page. Cheers, On Thu, 2 Mar 2023 at 18:20, Lena Voytek wrote: > > Hi Łukasz, > > Thanks for the response, here is the extra information you requested: > > On Thu, 2023-03-02 at 09:46 +0100, Lukasz Zemczak wrote: > > Hello Lena! > > > > Thank you for filling in the SRU MRE. I think your proposition makes > > sense, in general I do not object to having an MRE for this project. > > I > > do have some minor things I'd like us to touch first before > > proceeding: > > 1) Does upstream have a schedule for point-releases for stable > > versions? What is the average frequency of new minor releases > > happening, say, for 9.18.x? > > Point releases for development and stable versions happen around once a > month toward the beginning of each month. There is no set date for each > one though. In the upstream support policy they mention this as typical > behavior. I added this to the wiki page for clarity. > > > 2) This I wasn't quite 100% sure looking at the build logs - the > > tests > > in the source test/ directory: are those being run during package > > build or only via github CI? > > Tests are not currently run during package buildtime. In the > debian/rules directory dh_auto_test is overridden to be blocked. This > was done in Debian in 2019 since kyua was not available to them - > https://salsa.debian.org/dns-team/bind9/-/commit/766815911e02efd4f872d00b82f247b88388676b > > Using dh_auto_test in the way shown prior to this commit does allow the > tests to work at buildtime. So this could be added in an upcoming > release if we want some additional confidence in the MRE updates. > > > 3) As it is not entirely clear from the MRE, I'd like us to maybe > > explicitly state in the wiki page which kind of updates we would > > allow > > by this MRE: minor releases to already present releases. What I mean > > making it explicit that the idea of the MRE is that if a given Ubuntu > > series has version X.Y.Z, we will be updating to X,Y.Z+1 (and not, > > for > > instance, to X.Y+2.Z, as I think that's a different story). > Added this more explicitly in the Process section. > > > > > Cheers, > > > > On Wed, 1 Mar 2023 at 22:52, Lena Voytek > > wrote: > > > > > > Hello again, > > > > > > I would like to request another Microrelease Exception; this time > > > for > > > the Bind9 package in Ubuntu Kinetic, Jammy, and Focal. I created a > > > wiki > > > page with the relevant information here: > > > > > > https://wiki.ubuntu.com/Bind9Updates > > > > > > Having an MRE for bind9 would help a lot to clear out bugs that > > > have > > > been fixed upstream between 9.16.2-9.16.38 for Focal and up to > > > 9.18.12 > > > in Jammy and Kinetic. Some of these bugs include: > > > > > > - https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1258003 > > > - https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1970252 > > > - https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/2006972 > > > > > > It may also be worth noting that Debian has a similar method of > > > dealing > > > with bind9 through stable-backports. When there is a new release > > > upstream it is added to both unstable and bullseye-backports. As of > > > writing this the two are currently on 9.18.12 while bullseye is on > > > 9.16.27. > > > > > > Thank you for your consideration. Please let me know if you need > > > any additional information. > > > > > > Lena Voytek > > > > > > -- > > > Ubuntu-release mailing list > > > Ubuntu-release@lists.ubuntu.com > > > Modify settings or unsubscribe at: > > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release > > > > > > > -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: MRE request for Bind9
Hello Lena! Thank you for filling in the SRU MRE. I think your proposition makes sense, in general I do not object to having an MRE for this project. I do have some minor things I'd like us to touch first before proceeding: 1) Does upstream have a schedule for point-releases for stable versions? What is the average frequency of new minor releases happening, say, for 9.18.x? 2) This I wasn't quite 100% sure looking at the build logs - the tests in the source test/ directory: are those being run during package build or only via github CI? 3) As it is not entirely clear from the MRE, I'd like us to maybe explicitly state in the wiki page which kind of updates we would allow by this MRE: minor releases to already present releases. What I mean making it explicit that the idea of the MRE is that if a given Ubuntu series has version X.Y.Z, we will be updating to X,Y.Z+1 (and not, for instance, to X.Y+2.Z, as I think that's a different story). Cheers, On Wed, 1 Mar 2023 at 22:52, Lena Voytek wrote: > > Hello again, > > I would like to request another Microrelease Exception; this time for > the Bind9 package in Ubuntu Kinetic, Jammy, and Focal. I created a wiki > page with the relevant information here: > > https://wiki.ubuntu.com/Bind9Updates > > Having an MRE for bind9 would help a lot to clear out bugs that have > been fixed upstream between 9.16.2-9.16.38 for Focal and up to 9.18.12 > in Jammy and Kinetic. Some of these bugs include: > > - https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1258003 > - https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1970252 > - https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/2006972 > > It may also be worth noting that Debian has a similar method of dealing > with bind9 through stable-backports. When there is a new release > upstream it is added to both unstable and bullseye-backports. As of > writing this the two are currently on 9.18.12 while bullseye is on > 9.16.27. > > Thank you for your consideration. Please let me know if you need > any additional information. > > Lena Voytek > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Ubuntu Cinnamon for Official Flavor Status
Hello Joshua! Apologies for the longer wait. I was able to discuss it with some of the release team members and we seem to have an agreement. Welcome to the Ubuntu flavors! Initially at least I would like to be your point-of-contact - we'll see how it goes as we're not entirely compatible timezone wise. Let's start on some of the integration work at the start of next week. Cheers, On Tue, 10 Jan 2023 at 13:46, Joshua Peisach wrote: > > Release team should be aware - here is the information. I nominate myself to > coordinate with the release team. > > -Josh > > Begin forwarded message: > > From: Joshua Peisach > Subject: Ubuntu Cinnamon for Official Flavor Status > Date: November 28, 2022 at 12:34:10 PM EST > To: technical-bo...@lists.ubuntu.com > Cc: eeickme...@ubuntu.com > > Hello Technical Board, > > I’m Joshua Peisach, the lead of the Ubuntu Cinnamon Remix > (https://ubuntucinnamon.org, https://twitter.com/UbuntuCinnamon). For almost > three years now, the Ubuntu Cinnamon Remix team have maintained Ubuntu > Cinnamon through seven releases since 19.10. We have also maintained the > project through contributing to security uploads relevant to Cinnamon (see > caribou CVE-2021-3567), and have been maintaining Cinnamon in Debian with > Fabio Fantoni and the Debian Cinnamon Team. > (https://salsa.debian.org/cinnamon-team) > > Considering the amount of time that has passed, the current relationship with > Ubuntu Cinnamon and the Ubuntu community, we are applying for official flavor > status, starting with our 23.04 “Lunar Lobster” release. (Proposal: > https://wiki.ubuntu.com/UbuntuCinnamon/23.04/Proposal) > > We have many people on the team, along with several MOTUs. Other than myself, > fossfreedom has helped us with maintenance of the Nemo file manager, Jeremy > Bicha, Simon Quigley and Erich Eickmeyer are all MOTU’s for our uploads, and > I am also talking with Aaron Rainbolt as we both continue our Ubuntu journey > together. We also have worked with Phillipp and Monica from the Community > Team, all current existing leads (especially rs2009, Martin Wimpress and Rik > Mills), and work with the Yaru team towards maintaining Cinnamon theme > support. There is also Initu Castilhos, who has also helped with the > ‘Cinnamon’ color variant of the Yaru theme. There are plenty of developers > and contributors that will ensure Ubuntu Cinnamon Remix remains stable with > high quality assurance. > > I am looking forward towards the application process, and official flavor > status. > > Our launchpad team: https://launchpad.net/~ubuntucinnamon-dev > Our GitHub: https://github.com/Ubuntu-Cinnamon-Remix > > Thanks, > -Josh > > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: plasma-distro-release-notifier
Hey Erich! Basically my opinion is in line with Robie's - from the SRU POV it feels like something that would make a valid exception, but we'd probably want to know more details before giving a full +1. Which doesn't mean the info cannot be gathered in the SRU bug and the package uploaded to the jammy NEW queue for discussion. We can iterate on that there. From the release-team POV, this of course also feels doable. We'll try looking at the NEW package shortly and we'll be on a lookout for a FFe for the inclusion of this package in your images. This all sounds sensible to me, but I'd appreciate writing that all up in the FFe (along with the rationale, conclusions of the discussions and plan forward). Cheers, On Sat, 10 Sept 2022 at 12:44, Robie Basak wrote: > > Hi Erich, > > On Fri, Sep 09, 2022 at 05:32:45PM -0700, Erich Eickmeyer wrote: > > You may have seen my post and discussion in the MLs of ubuntu-devel, > > kubuntu- > > devel and ubuntu-studio-devel (really, those with the Plasma desktops) > > lacking > > a way to be notified when a new Ubuntu version is released. This is a huge > > detriment to our users, and I hope to correct this as soon as possible. > > Thank you for looking into this! I appreciate your concern about the UX. > > > This is where things get tricky. I realize this is a somewhat unusual > > request, > > but I believe this needs to be included in 22.04 as well. I know that > > entirely > > new packages are highly frowned-upon for stable releases, but I feel the > > detriment to users not getting a notification about a new release and > > getting > > stuck on an EOL release might be a bigger detriment than the small risk this > > small package might create. > > Speaking for the SRU team, I can't provide a hard answer without > consulting with other members first, but it sounds like this is the sort > of thing that we would make an exception for exactly because it relates > to the UX of moving to the next release. > > Exactly what would or would not be acceptable depends on the details > which I understand have yet to be figured out (or, at least, aren't laid > out in a bug yet). I encourage you to continue and I'll make sure we > give you feedback along the way as necessary so we end up with a > solution that's acceptable to everyone. > > Robie > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Call for testing: 20.04.5 release candidate images ready!
Hello everyone! Just a quick heads up: we respun most of the 20.04.5 images to fix the nvidia-390 driver situation (new kernel lrm). Please do some re-testing on the new images! Thank you! On Tue, 30 Aug 2022 at 00:02, Lukasz Zemczak wrote: > > Hello everyone! > > We just finished building our first official set of 20.04.5 release > candidate images. As always, those should be available via the ISO > tracker below: > > http://iso.qa.ubuntu.com/qatracker/milestones/438/builds > > Please pick your favorite flavor and start testing! And be sure to > report your results on the isotracker above. > > As with every recent release, we have a discourse thread for tracking > progress which we try to keep up to date as much as possible: > > https://discourse.ubuntu.com/t/focal-fossa-20-04-5-lts-point-release-status-tracking/29969 > > Best regards, > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > Tools Squad Interim Engineering Manager > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Call for testing: 20.04.5 release candidate images ready!
Hello everyone! We just finished building our first official set of 20.04.5 release candidate images. As always, those should be available via the ISO tracker below: http://iso.qa.ubuntu.com/qatracker/milestones/438/builds Please pick your favorite flavor and start testing! And be sure to report your results on the isotracker above. As with every recent release, we have a discourse thread for tracking progress which we try to keep up to date as much as possible: https://discourse.ubuntu.com/t/focal-fossa-20-04-5-lts-point-release-status-tracking/29969 Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Call for testing: 22.04.1 release candidate images ready!
Hello everyone! As you know, we had to delay 22.04.1 by a week to get an additional fix in. This has now happened and new release candidate images are building as we speak. Please start testing as soon as the new images for your favorite flavors appear on the tracker: http://iso.qa.ubuntu.com/qatracker/milestones/437/builds The ones with "(re-building)" in the name are still building, but many have already finished. Let's give those as much testing as possible and, hopefully, we'll have a swift release on Thursday. Thank you, On Tue, 2 Aug 2022 at 00:57, Lukasz Zemczak wrote: > > Hello everyone! > > We just finished building our first official set of 22.04.1 release > candidate images. From what we're seeing so far things seem to be > looking quite nice, so fingers-crossed for those being our final ones! > > http://iso.qa.ubuntu.com/qatracker/milestones/437/builds > > Please pick your favorite flavor and start testing! And be sure to > report your results on the isotracker above. > > As with every recent release, we have a discourse thread for tracking > progress which we try to keep up to date as much as possible: > > https://discourse.ubuntu.com/t/jammy-jellyfish-22-04-1-lts-point-release-status-tracking/29102 > > Best regards, > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > Tools Squad Interim Engineering Manager > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Call for testing: 22.04.1 release candidate images ready!
Hello everyone! We just finished building our first official set of 22.04.1 release candidate images. From what we're seeing so far things seem to be looking quite nice, so fingers-crossed for those being our final ones! http://iso.qa.ubuntu.com/qatracker/milestones/437/builds Please pick your favorite flavor and start testing! And be sure to report your results on the isotracker above. As with every recent release, we have a discourse thread for tracking progress which we try to keep up to date as much as possible: https://discourse.ubuntu.com/t/jammy-jellyfish-22-04-1-lts-point-release-status-tracking/29102 Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Issue with Manual ISO Rebuilds
Hey Simon! Interesting. Can you fill a bug under the https://bugs.launchpad.net/ubuntu-cdimage/ project? I'll investigate it now, since I think the rebuild gets queued but then something dies further in rebuild-requests. But a bug would be a welcome addition anyway. Cheers, On Thu, 30 Jun 2022 at 12:30, Simon Quigley wrote: > > Hello, > > Since Ubuntu Studio ran into this issue today, I figured I'd ask the > question so we can get this fixed. I can file a bug, just let me know where. > > When an ISO rebuild is occurring, and it *fails*, until the next daily > cron run for the ISO, it can not be manually rebuilt from the ISO QA > tracker. > > Steps to reproduce: > 1. Include a package on a daily ISO which fails to install for some > reason (duplicate files may be an example). > 2. Let the daily ISO cron run and watch it fail. > 3. Try to trigger a manual rebuild from the ISO QA tracker. > > Could someone at Canonical please provide some insight as to what is > happening on the server-side, perhaps providing some logs? > > Thanks. > > -- > Simon Quigley > si...@tsimonq2.net > tsimonq2 on LiberaChat and OFTC > @tsimonq2:linuxdelta.com on Matrix > 5C7A BEA2 0F86 3045 9CC8 > C8B5 E27F 2CF8 458C 2FA4 > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: MRE request for HAProxy
Hello Lucas! Thanks for submitting the MRE. It looks decent, I'm willing to approve it as it is. Checking the upstream CI tests, I like it that they have so many different tests running on Ubuntu - that's a plus for sure. But I guess they're all running on focal, right? Do you know if they're running any other Ubuntu versions for their various testing? It's certainly a bit unfortunate that the autopkgtest/buildtime testing story isn't great. I appreciate their upstream testing story on Ubuntu, but autopkgtests give us the power to know the testing state on the exact series and, also, whether other, dependent package changes won't regress haproxy itself. So please continue working on improving the ADT testing story for the future! Is there any exploratory testing one can do in the meantime? Or do the existing autopkgtests handle all the base testing already? Anyway, we can always improve on the process. I'll add this exception to the exception list now - you may proceed with preparing updates. Best regards, On Fri, 24 Jun 2022 at 17:01, Lucas Kanashiro wrote: > > Hi, > > I would like to request a Micro Release Exception for the HAProxy package in > all supported Ubuntu LTS releases. I put together a wiki page describing > everything I judged pertinent to the MRE here: > > https://wiki.ubuntu.com/HAProxyUpdates > > In all Ubuntu LTS releases we have LTS versions of HAProxy and upstream has > carefully fixed bugs in them. > > Unfortunately, the package does not run upstream tests during build time > because it relies on an external framework for testing (better explained in > the wiki page), however, upstream has defined some great CI pipelines which > run all the tests and more against all the supported branches. The package > does contain some DEP-8 tests, and we (Server team) have been working to > increase the coverage, for instance we have added a couple of SSL related > tests in Ubuntu and they are already merged in Debian (will be available in > the next upload). If the MRE is granted for HAProxy, all the new DEP-8 tests > will be included in the future releases. > > Thank you in advance for considering this request, and please let me know if > you need more information. > > -- > Lucas Kanashiro > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Call for testing: 22.04 release candidate images ready!
Hello everyone! We are now finishing building our latest batch of 22.04 release candidate images to the iso-tracker. From what we're seeing so far things seem to be looking quite nice, so fingers-crossed for those being our final ones! http://iso.qa.ubuntu.com/qatracker/milestones/432/builds Please pick your favorite flavor and start testing! And be sure to report your results on the isotracker. As with every recent release, we have a discourse thread for tracking progress which we try to keep up to date as much as possible: https://discourse.ubuntu.com/t/jammy-jellyfish-22-04-release-status-tracking/27763 Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: FFe for livecd-rootfs to enable bootable arm64 buildd images
It was approved by Steve I see + accepted by me into jammy-proposed. On Tue, 12 Apr 2022 at 11:40, Michał Sawicz wrote: > > May I please ask for a look at: > > [FFe] Update livecd-rootfs to add arm64 bootable buildd images Edit > > https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1966636 > > It's near zero risk, as it doesn't affect anything that exists today. > > Thanks, > -- > Saviq > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: overlap or pre-announcement for point release ISO downloads
It's as dann mentioned. This, of course, is only the case for our main Ubuntu flavor though. There is also an automatic redirect for http://releases.ubuntu.com/20.04.3/ to old-images. Cheers, On Wed, 2 Mar 2022 at 10:11, Anthony Kirby wrote: > > On Tue, 1 Mar 2022 at 19:09, dann frazier wrote: >> >> On Tue, Mar 01, 2022 at 03:44:17PM +, Anthony Kirby wrote: >> > Thank you for the recent point release of Focal, i.e. 20.04.4! >> > >> > When the 20.04.4 point release was announced ( >> > https://lists.ubuntu.com/archives/ubuntu-announce/2022-February/000277.html), >> > the previous point release server download i.e. >> > https://releases.ubuntu.com/focal/ubuntu-20.04.3-live-server-amd64.iso was >> > removed. >> > >> > Could you consider an overlap period, so that people who consume this have >> > an opportunity to update their processes? A week of overlap before the the >> > previous version is deleted would be really helpful. Or alternatively an >> > announcement that the switch was about to occur would give people a chance >> > to prepare. >> >> Hi Anthony! >> >> I'm not a release team member, but I'm curious about your use >> case. If you are e.g. scripting a download of the ISO, would it be >> possible to build in an automatic fallback to the old-releases >> archive? >> >> https://old-releases.ubuntu.com/releases/focal/ >> >> -dann > > > Hi dann, > thank you, that's a good solution, I wasn't aware that old-releases existed. > cheers > Anthony > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Call for testing: preliminary 20.04.4 release candidate images ready!
Follow up to this. I have now started building the first set of real release candidate images (aka ones that, if no blocking issues are found, should be good to be released). Once the rebuilds are finished, please be sure to test your favorite flavors as soon as possible. Thanks again! On Sat, 19 Feb 2022 at 00:34, Lukasz Zemczak wrote: > > Hello everyone! > > Some moments ago we published our first official release candidate > images for the 20.04.4 point-release. We seem to have most known > blocker issues out of the way, but these will not be final images - at > least not for the desktop variants (we're waiting for some OEM kernel > work to happen re: that). > As always, we have an ISO Tracker milestone set up for it: > > http://iso.qa.ubuntu.com/qatracker/milestones/430/builds > > Please pick your favorite flavor and start testing! And be sure to > report your results on the isotracker. The sooner we get testing done, > the earlier we'll catch any possible blockers. > > As with every recent release, we have a discourse thread for tracking > progress which we try to keep up to date as much as possible: > > https://discourse.ubuntu.com/t/focal-fossa-20-04-4-lts-point-release-status-tracking/26490 > > Let's go! > > Best regards, > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Call for testing: preliminary 20.04.4 release candidate images ready!
Hello everyone! Some moments ago we published our first official release candidate images for the 20.04.4 point-release. We seem to have most known blocker issues out of the way, but these will not be final images - at least not for the desktop variants (we're waiting for some OEM kernel work to happen re: that). As always, we have an ISO Tracker milestone set up for it: http://iso.qa.ubuntu.com/qatracker/milestones/430/builds Please pick your favorite flavor and start testing! And be sure to report your results on the isotracker. The sooner we get testing done, the earlier we'll catch any possible blockers. As with every recent release, we have a discourse thread for tracking progress which we try to keep up to date as much as possible: https://discourse.ubuntu.com/t/focal-fossa-20-04-4-lts-point-release-status-tracking/26490 Let's go! Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Call for testing: 20.04.3 release candidate images ready!
Hello everyone! Some moments ago we published our first official release candidate images for the 20.04.3 point-release. We seem to have all critical blockers resolved, so my hope is that these images will be the final ones we'll be releasing next week. http://iso.qa.ubuntu.com/qatracker/milestones/425/builds Please pick your favorite flavor and start testing! And be sure to report your results on the isotracker. As with every recent release, we have a discourse thread for tracking progress which we try to keep up to date as much as possible: https://discourse.ubuntu.com/t/focal-fossa-20-04-3-lts-point-release-status-tracking/22948 Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Ubuntu 20.04.3 delayed until August 26th
... and the footnotes for the earlier e-mail: [1] https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1937115 [2] https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1934548 On Tue, 10 Aug 2021 at 10:30, Lukasz Zemczak wrote: > > Hello, > > While working towards the 20.04.3 milestone, we received reports of > the currently available shim package causing daily builds of our > installation media to fail to boot on some devices[1]. A fix for that > is now in progress, but as we would like to make sure the new version > of the package is well tested before candidate images are built. > Subsequently, we decided more time is needed. In addition to that we > are also investigating an unrelated issue with our RISC-V images[2], > whose root cause is not yet fully understood. As we feel that rushing > things through is not the right way to go, we decided to play it safe > and delay the point-release date a week, to August 26th. > > That being said, we will be freezing the focal-updates pocket at the > same date as originally planned (on August 12th), afterwards only > releasing packages that are critical for the .3 milestone. Let’s all > use the additional week for further testing. > > Remember that the progress of the 20.04.3 release can be tracked at > any time via our release status tracking post on discourse: > https://discourse.ubuntu.com/t/focal-fossa-20-04-3-lts-point-release-status-tracking/22948 > > Thank you. > > On behalf of the release team, > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Ubuntu 20.04.3 delayed until August 26th
Hello, While working towards the 20.04.3 milestone, we received reports of the currently available shim package causing daily builds of our installation media to fail to boot on some devices[1]. A fix for that is now in progress, but as we would like to make sure the new version of the package is well tested before candidate images are built. Subsequently, we decided more time is needed. In addition to that we are also investigating an unrelated issue with our RISC-V images[2], whose root cause is not yet fully understood. As we feel that rushing things through is not the right way to go, we decided to play it safe and delay the point-release date a week, to August 26th. That being said, we will be freezing the focal-updates pocket at the same date as originally planned (on August 12th), afterwards only releasing packages that are critical for the .3 milestone. Let’s all use the additional week for further testing. Remember that the progress of the 20.04.3 release can be tracked at any time via our release status tracking post on discourse: https://discourse.ubuntu.com/t/focal-fossa-20-04-3-lts-point-release-status-tracking/22948 Thank you. On behalf of the release team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: fwupd SRU policy update request.
Hello! I had a quick look at the draft proposal - I have made a few small corrections here and there. That being said, one other change I did and that I would like to propose is to simply do the full QA process for *every* fwupd release. First of all, it's easier to remember which steps are needed if there is just one verification policy. Secondly - I personally think that the more tests are being performed on an update, the better. So I would like that both switches from 1.3.x to 1.4.x and regular 1.3.x to 1.3.y be following the same tests as outlined in the proposal. If that is fine, let's get this merged into the firmware-updates page. Cheers, On Wed, 23 Jun 2021 at 23:51, YC Cheng wrote: > > Hi, to support OEM cutting edge hardware in LTS, we need to upgrade fwupd > across dot release (ex: 1.3.x to 1.4.y) again (we did that in bionic, too) > based on the discussion on the roadmap sprint. > > Given this will be a repeated work, here is the fwupd-updates SRU policy draft > for final review. > > https://wiki.ubuntu.com/firmware-updates-draft > > fwupd has most of its role on hardware support and also has userspace > command-line utilities, a daemon that talks with ubuntu-store. So extra care > will be needed. > > The updated policy add the possibility of upgrading across dot release and > add MUST-RUN steps for such a case, to make sure we won't have regression. > > We've done our best to prepare the updated policy with contributions from > several engineers to make sure it has good coverage. Please kindly approve > or comment on how to make it better. > > Thank you. > -- > YC Cheng > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Handling upload queues of a new stable release
Hey Robie! What I think is usually done so early in the cycle is a forward binary-copy to the devel series when such an SRU is accepted. As for the NEW packages - since I've been working on these recently, I'll take care of them. Those are source syncs from a PPA so they will not be forgotten. Cheers, On Mon, 26 Apr 2021 at 10:34, Robie Basak wrote: > > On Mon, Apr 26, 2021 at 09:26:45AM +0100, Robie Basak wrote: > > As usual, there were some packages left over in the Unapproved and New > > queues and these will need to be handled specially. > > What's the normal process for handling these? As it stands, most of > these uploads have been left in Unapproved with a package version string > that is higher than the one in Impish when the Hirsute release pocket > got copied forward. > > I can think of a few approaches to resolving these, but I'd prefer to do > what is already established - but I don't think there's any > documentation for this. > > The packages affected are: > > nextcloud-desktop > murano-dashboard > usb-creator > update-notifier > libdrm > gdm3 > alsa-ucm-conf > update-manager > ceph > > There are also two packages in Hirsute New: > > xf86-video-armsoc-endlessm > xlnx-firmware > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Hirsute Hippo (21.04) Beta Freeze
As of a short while ago, hirsute has entered the Beta Freeze, with a goal of releasing Beta images sometime late Thursday. *From now until the beta is released, please only upload updates for packages on any release images if you /need/ to get them into the beta itself.* Please hold off with everything else until after we release on Thursday. The queue freeze will last from now until final release in April, which means that all seeded packages will now need a spot-check and review in the queue from a release team member before they are let into the archive. As with the previous releases, we have a bot in place that will accept uploads that are unseeded and don't affect images. Don't take this as an open invitation to break Feature Freeze on those components, this is just to reduce the burden on the release team, so we only review the uploads that need very serious consideration. If you find the bot is blocking an upload that you think should have been auto-accepted, let us know and we'll sort it out. We will be spinning a set of beta candidates most probably later today or tomorrow morning EU time, after the last few changes have migrated into hirsute. We then encourage people to do ASAP for their favourite flavour(s) as they come off the line. Happy bug-hunting from now until the final release, and please do help out and test ISOs, netboot, etc, where you can and let us know what's broken in your environment(s). As a reminder, the Beta images will appear on the ISO Tracker here: http://iso.qa.ubuntu.com/qatracker/milestones/422/builds On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Improvements to the point-release release process - stricter processes for fixes
Hello everyone, In an attempt to improve our processes and quality of the LTS point-release images, starting with 20.04.3 (in August) we will be trying a bit of a safer approach. Basically the main noticeable change is that we will now be following the SRU procedures even for any release blockers that we find during the point-release week. This means that, besides some very exceptional cases, every fix (even for a blocker) will have to follow the same verification, regression analysis and aging period process - in which case, if a bug is found in the release candidate images, we will be simply delaying the point release until the fix is verified, aged and only then released into updates. Delaying a point-release is unfortunate, but better than lowering our quality standards. We had a few cases already where our last minute fixes, fast-tracked under time pressure, were not tested thoroughly enough and introduced regressions (or, similarly annoying, appeared to be only partial fixes). As quality is the most important aspect of any Ubuntu release, we want to make sure users get the best experience of our point-release images. To accommodate this change, and to make sure as many release blockers are found as early as possible, we will also be switching -proposed off from the series daily image builds 2 weeks before release (so a week before the first release candidate images are planned). Previously we stuck with proposed-enabled daily images until one week before release (only switching those off for when release candidates are built), mainly as a legacy from old times when -proposed as a whole was flushed to -updates as part of the process. This has not been done since years already (as it's no longer safe), so leaving -proposed on dailies makes less sense than it had in the past. What does it all mean to you, developers? Please be sure to land any critical or important changes for the given point-release as soon as possible, preferably with release -2 weeks as the deadline. Every other last minute SRU will potentially be risking the delay of the release. Also, once -proposed is disabled for dailies, it would also be wonderful if the pre-point-release images could get as much testing as possible. The sooner critical issues are identified, the higher chances are we will not have to slip the release. I'm pretty confident that with these changes we will all benefit equally. Thank you! On behalf or the release team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Call for testing: 20.04.2 release candidate images ready!
Hello everyone! I'm only sending this e-mail now as previously we were still resolving some unexpected issues regarding the .2 point-release. After a rough start, we now have a *hopefully* stable set of 20.04.2 release candidate images built and published on the .2 milestone: http://iso.qa.ubuntu.com/qatracker/milestones/420/builds Please pick your favorite flavor and start testing! And be sure to report your results on the isotracker. As with every recent release, we have a discourse thread for tracking progress which we try to keep up to date as much as possible: https://discourse.ubuntu.com/t/focal-fossa-20-04-2-lts-point-release-status-tracking/ Best regards, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [SRU discussion] Renaming the 'Regression Potential' section
Thank you for bringing this up again Seb, Iain. You brought it up at the right moment as I just encountered the aforementioned problem while reviewing an SRU in the queue. Laney: I glimpsed through your proposition and this sound sane to me. The section name isn't super pretty, but at least it's understandable and straightforward. So a +1 from me with my SRU hat - we can always work on the wording afterwards and this feels like a decent start. If you're fine with it (and no one else from the SRU team disagrees), I'll commit your change and send the e-mail afterwards. Cheers, On Thu, 5 Nov 2020 at 16:41, Iain Lane wrote: > > A while ago I actually wrote some content for this, but I failed to > follow up to this thread to push it forward. Sorry about that and thanks > for the reminder. > > Here it is: > > Proposed change to the wiki page: > > > https://git.launchpad.net/~laney/+git/sru-regressions/commit/?id=91ebf1c2b65cb77637cdf1c8fe6339bfde64288a > > Proposed email to send to ubuntu-devel: > > https://git.launchpad.net/~laney/+git/sru-regressions/tree/email.txt > > If someone from the SRU team is willing to help now I think that would > be the best way to move this forward. Feel free to take my text and edit > it, ask for peer review if you want, and then ideally commit the change > to the wiki and send the mail. > > Cheers, > Iain > > On Thu, Nov 05, 2020 at 04:27:46PM +0100, Sebastien Bacher wrote: > > Hey there, > > > > I hit another of those bugs where the well intended controbutor spent > > time writing a 'low > downstream>', any chance to see the discussion leading to a conclusion. > > > > I was thinking maybe something around the line of > > 'Regression Testing Focus' > > it's a bit longer but you can't reply 'low' to it... > > > > Cheers, > > Sebastien Bacher > > > > Le 30/07/2020 à 13:40, Dan Streetman a écrit : > > > +1 this is incorrectly filled out most of the time, or at least it > > > feels that way. I'm not sure what exact wording will be clearer, > > > though. > > > > > > On Thu, Jul 30, 2020 at 5:36 AM Iain Lane wrote: > > >> Hiya, > > >> > > >> I often come across SRU bugs from developers that seem to treat the > > >> Regression Potential section as a place to argue why their upload is not > > >> risky and should be accepted. Like > > >> > > >> [ Regression Potential ] > > >> Low. This only changes X Y Z. > > >> > > >> I'm not going to bother repeating the arguments for why that's wrong. I > > >> find the wiki page > > >> > > >> https://wiki.ubuntu.com/StableReleaseUpdates/#SRU_Bug_Template > > >> > > >> quite clear on what's needed. But I think the message hasn't managed to > > >> get through to everybody yet, which to me indicates that we haven't yet > > >> achieved a universal culture of critically assessing our own work. > > >> Thinking "what if I'm wrong and this update is bad, where might that > > >> happen?" > > >> > > >> My *straw man* proposal is to rename the section to something like > > >> 'Where problems could occur' or something more explicit than what we > > >> currently have. > > >> > > >> This is obviously partly/mostly a problem that the expectations haven't > > >> gotten through to people, so while I think we should rename, any change > > >> will need to be communicated so that people know about it and then > > >> enforced by the SRU team for a little while. > > >> > > >> Thoughts welcome. > > >> > > >> Cheers, > > >> > > >> -- > > >> Iain Lane [ i...@orangesquash.org.uk ] > > >> Debian Developer [ la...@debian.org ] > > >> Ubuntu Developer [ la...@ubuntu.com ] > > >> -- > > >> Ubuntu-release mailing list > > >> Ubuntu-release@lists.ubuntu.com > > >> Modify settings or unsubscribe at: > > >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-release > > > > -- > > Ubuntu-release mailing list > > Ubuntu-release@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release > > -- > Iain Lane [ i...@orangesquash.org.uk ] > Debian Developer [ la...@debian.org ] > Ubuntu Developer [ la...@ubuntu.com ] > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Groovy Gorilla (20.10) Beta Freeze
As of a short while ago, groovy has entered the beta freeze, with a goal of releasing Beta images sometime late Thursday. *From now until the beta is released, please only upload updates for packages on any release images if you /need/ to get them into the beta itself.* Please hold off with everything else until after we release on Thursday. The queue freeze will last from now until final release in October, which means that all seeded packages will now need a spot-check and review in the queue from a release team member before they are let into the archive. As with the previous releases, we have a bot in place that will accept uploads that are unseeded and don't affect images. Don't take this as an open invitation to break Feature Freeze on those components, this is just to reduce the burden on the release team, so we only review the uploads that need very serious consideration. If you find the bot is blocking an upload that you think should have been auto-accepted, let us know and we'll sort it out. We will be spinning a set of beta candidates most probably tomorrow morning EU time, after the last few changes have migrated into groovy (one of which is the kernel). We then encourage people to do ASAP for their favourite flavour(s) as they come off the line. Happy bug-hunting from now until the final release, and please do help out and test ISOs, netboot, etc, where you can and let us know what's broken in your environment(s). On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Request : Sosreport - SRU Special Cases
Thanks for the exception! We'll probably make it a bit more shiny, but it's good as it is. Exception approved! On Mon, 22 Jun 2020 at 20:00, Eric Desrochers wrote: > > Hi, > > I'd like to request an SRU special case for the Sosreport project: > https://wiki.ubuntu.com/SosreportUpdates > > Regards, > Eric -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [Proposals] Consult with Flavor Leads before Beta Freeze / Flavors Underrepresented
Hello Erich! Sorry to hear that you are not satisfied with the release process so far. The last thing I, and possibly all other release team members, would want is for flavors and flavor leads to feel underrepresented and ignored. With most releases (point-releases) I tend to always check with flavors if they are satisfied with the current state-of-things before proceeding, which I might have not done explicitly yet, mostly due to the fact as we did not build candidate images just yet. The Beta Freeze is not a hard-stop, and the release team always makes sure to keep track of what lands in the queues, keeping an eye out for any important packages that might be needed for the milestone. Feel free to consult any of us whenever you, or anyone else, feels that there is an upload still missing. I agree with Steve's position here. Even though as you said, the world does not revolve around Ubuntu, being part of the Ubuntu family we all follow the same strictly time-based release schedule. Sometimes there are slips, sometimes there are slides, but generally we all try to strictly follow the schedule, at least to some extent. The dates are well known and we try to communicate the incoming freezes, sending reminders. Delaying a freeze is possible, but would need good reasoning for that to happen - as a delay here can cause the delay of the milestone release date. Which means the delay of all flavors involved. We are all tightly bound together, so we need to work together, considering the well-being of everyone. As Steve mentioned, Beta Freeze is not yet the final call. If you still need something critically in for Beta, please upload and give us a sign through any available media. We trust you, and trust that you know best what is needed for your flavor to shine. Please remember that handling Ubuntu releases is *hard*. Ubuntu is a big project with lots of wonderful flavors. We try to make sure that we consider all the flavors equally, but it's not always possible - there's always so many moving parts that it's a non-trivial task. But most important of all: if at any moment you feel that your concerns or your flavor's voice is ignored and you think you are not treated equally, please give us a sign. Tell us what's wrong. We will try explaining ourselves and then try to make it better. Feel free to tell us of the situations when you thought that some other flavor had more of a voice than yours either here or privately. What I generally mean: we'll try to continue and improve our ongoing communication with flavor leads all the way, but just feel free to reach out to us directly yourself. With anything. Keep us in the loop! Cheers, On Tue, 31 Mar 2020 at 07:46, Steve Langasek wrote: > > Hi Erich, > > On Mon, Mar 30, 2020 at 04:18:07PM -0700, Erich Eickmeyer wrote: > > I have a package (carla) for which I have PPU upload rights for that I > > have been working with the upstream for getting a release today. Despite > > this, the upstream developer could not meet this deadline for their > > release, which is really not their problem as the application isn't > > necessarily developed for Ubuntu specifically (the world doesn't revolve > > around Ubuntu). This is a bugfix release being prepared (carla-2.1-rc2, > > with carla-2.1-rc1 already in the archives) in preparation for a final > > release mid-April prior to Final Freeze. > > > Unfortunately, beta freeze came without any discussion as to if the > > flavors were ready for this freeze, and now flavors must rely on a small > > group of developers (the Release Team) to approve any last-minute, > > intended-for-beta uploads. With carla being a release candidate, it is > > perfect for beta testing in preparation of that final release, not only > > for carla, but for Ubuntu. > > > Additionally, carla is a seeded package in Ubuntu Studio. > > > [Proposal 1] > > > > I believe that the release team needs to check with the flavor leads > > prior to enacting the beta freeze, just to make sure there are no > > last-minute intended-for-beta already-seeded packages preparing for > > upload. A good way would be checking with the flavor leads either in > > #ubuntu-flavors or on #ubuntu-release (which many, if not most, are > > monitoring). I think this is important especially for packages in the > > archive that are in beta or release candidate status that have an > > imminent bugfix or final release from an upstream. > > Speaking with my Release Team hat: we do time-based releases, and the dates > are known well in advance. The manual process of the Release Team approving > exceptions to the milestone freeze exists because we know not all seeded > packages, across all flavors, are going to be ready for beta at the start of > the freeze. Nevertheless, a freeze is necessary to impose control over the > set of changes going into the milestone preparation. > > In this case, you want the carla package to be included in the beta. But > you probably wouldn't appreciate it if some ot
18.04.4 release date postponed by a week
Hello everyone, First of all, big thanks to everyone involved in this week's 18.04.4 point-release candidate image testing! All the classic ISOs and images seem to look good and ready for release. That being said, due to some issues noticed during our final rounds of testing of the Ubuntu Core 18 images, we will be postponing the 18.04.4 release until next week (February 13). Hopefully we'll be able to resolve those shortly and release earlier, but it's best to play it safe and validate the images properly. Please note that the issues we are investigating are uc18-only, so we do not intend to re-spin any of the classic ISO flavors. All the testing performed so far will still be valid until release. We apologize for the delay. Thank you! -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Call for testing: fresh RCs for 18.04.4
Hello everyone, We have just built our first release candidate images for 18.04.4 and posted them to the ISO tracker [1]. Those are all fully-prepared, with all base-files and label thingies in place, with hopes of no actual re-spins required. Fingers crossed that these will be the images released on Thursday. Please pick your favourite flavour and start testing. As with every point-release: do keep in mind that any bug that was also present in 18.04.3 isn't considered a blocker, and minor regressions can be dealt with post-release, but if you find something dire and boot/install critical, we need to hear about it yesterday so we can get it sorted by release. Happy testing! Thanks. [1] http://iso.qa.ubuntu.com/qatracker/milestones/410/builds -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Ubuntu 14.04.6 RC images for testing
Hello everyone, Following last week's xenial 16.04.6 security-oriented point-release, we are now preparing a similar release for trusty this week. The target date is 7th of March. We have now built the first set of RC images - hopefully there will be no re-spins needed [1]. The situation is a bit different here than with 16.04.6 as there's only a few flavors still supported for trusty at this stage. Seeing that the series EOLs next month anyway, even for those flavors participation is completely optional (and some have already rightfully opted out). Anyway, if you want to help with testing of the images, feel free to grab the isos and report your findings. Cheers, [1] http://iso.qa.ubuntu.com/qatracker/milestones/401/builds -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Ubuntu 16.04.6 RC images for testing
Hello everyone, Sadly, as most of you know, a regression has been found during testing [1] which means new images had to be built. The issue has been fixed in ubiquity+user-setup and new images created [2], but all this means isos need to be re-tested once again. It's sad, because testing was going really smooth - we were basically 'ready' yesterday. But well, what kind of a release would it be without at least one respin, right? Thanks again to everyone participating! [1] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1817689 [2] http://iso.qa.ubuntu.com/qatracker/milestones/400/builds Cheers, On Fri, 22 Feb 2019 at 15:29, Lukasz Zemczak wrote: > > Hello everyone, > > In the light of the recently discovered and fixed apt vulnerability, > we have decided to re-build all our supported isos that could be > potentially affected. We did not plan for another xenial point-release > but oh well, what can you do. Security is important. > > We prepared the first set of xenial 16.04.6 images just now ready for > testing, visible on the new milestone's isotracker [1]. The release > date has been set for February 28th. > > A very important thing related to all that: since this is a completely > out-of-process point-release, flavors are not required to participate > at all. I have prepared images for all the xenial flavors but we will > be releasing only those that are marked as ready at the time of > release. > So if you're a flavor maintainer and you intend to participate in this > very-last-minute point-release, please grab the relevant iso and test > - that would be more than welcome! Otherwise, please be sure to give > the regular Ubuntu isos a spin and report any issues you might > encounter. > > Thanks! > > [1] http://iso.qa.ubuntu.com/qatracker/milestones/400/builds > > Cheers, > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Ubuntu 16.04.6 RC images for testing
Hello everyone, In the light of the recently discovered and fixed apt vulnerability, we have decided to re-build all our supported isos that could be potentially affected. We did not plan for another xenial point-release but oh well, what can you do. Security is important. We prepared the first set of xenial 16.04.6 images just now ready for testing, visible on the new milestone's isotracker [1]. The release date has been set for February 28th. A very important thing related to all that: since this is a completely out-of-process point-release, flavors are not required to participate at all. I have prepared images for all the xenial flavors but we will be releasing only those that are marked as ready at the time of release. So if you're a flavor maintainer and you intend to participate in this very-last-minute point-release, please grab the relevant iso and test - that would be more than welcome! Otherwise, please be sure to give the regular Ubuntu isos a spin and report any issues you might encounter. Thanks! [1] http://iso.qa.ubuntu.com/qatracker/milestones/400/builds Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Non-final, but very testable (hint, hint) Cosmic RC builds
On it. https://media.giphy.com/media/JIX9t2j0ZTN9S/giphy.gif On Sun, 14 Oct 2018 at 01:32, Adam Conrad wrote: > > Over the next few hours, builds will start popping on the Cosmic Final > milestone page[1] on the ISO tracker. These builds are not final. > We're still waiting on a few more fixes, a few things to migrate, etc. > I've intentionally not updated base-files or the ISO labels to reflect > the release status (so please don't file bugs about those). > > What there are, however, are "close enough" for people to be testing in > anger, filing bugs, fixing bugs, iterating image builds, and testing > all over again. So, please, don't wait until Wednesday night to test, > testing just before release is TOO LATE to get anything fixed. Get out > there, grab your favourite ISO, beat it up, report bugs, escalate bugs, > get things fixed, respin (if you're a flavour lead with access), and > test, test... And test. Did I mention testing? Please[2] test. > > Thanks, > > ... Adam > > [1] http://iso.qa.ubuntu.com/qatracker/milestones/397/builds > [2] Please. > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Please lift aging requirement on gce-compute-image-packages in the stable release exception
Hello, In my humble opinion, for this particular case I would be inclined toward lifting the aging requirement. Yes, it's not a completely straightforward thing, even though I usually approved of releasing early of this package before after validation was performed. From my point of view a strong enough rationale has been provided for that. Balint's original e-mail states: "No one else is expected to test those packages in the remaining time of default required minimal age." I think in case of this package this is true. As already mentioned by Steve, the gce-compute-image-packages binaries are *only* used on cloud instances. This basically means almost absolutely no one will be using the versions from -proposed, meaning the 7 days are wasted on idle waiting. My rationale below: To me the aging period is always a safety buffer for when a package enters -proposed, during which it can get additional testing (or 'dogfooding') by both interested and unrelated parties. In my eyes though, usually what this means in practice is to give users that are affected by the selected bug or are generally interested in the given package time to pick it up from -proposed and give it a spin themselves. Formally for us to consider an SRU to be verified requires only one tested giving a +1 on the package, after providing test results. The aging period (besides the obvious case of letting it run on systems of users that always run with -proposed enabled for testing purposes) serves the purpose of giving additional time for those 'other than the verifying person' affected users to actually test the package and report any regressions that the original verifier could have missed. For this, there have to be such users - and those users need to be able to perform the validation steps as noted in the test case. In the case of gce-compute-image-packages, considering the nature of the package itself, the test case, the SRU exception and the release process of the actual package itself, I think we can be pretty confident that the only people aware of SRU updates of those packages are: the uploader, the SRU team and GCE upstream. These people are probably also the only ones that can fully test the packages (since those are usually new upstream releases), not counting cases where there are specific isolated LP bugs involved in the upload (for those I would say aging can still make some sense). All those small arguments, in my opinion, sum up into a decent enough rationale for ignoring the aging period in this case. Cheers, On 7 August 2018 at 22:27, Robie Basak wrote: > Hi Steve, > > Summary: I still think we should have an actual justification for > waiving the aging requirement. I still don't think that we've actually > been given a justification in this case. Give me one and I'll > reconsider, but IMHO without any justification, we should either change > policy to drop it wholesale, or maintain our current policy of having > it. > > The rest of my response is mostly about why we have the general policy > in the first place, rather than this specific case. > > On Tue, Aug 07, 2018 at 11:41:31AM -0700, Steve Langasek wrote: >> That is certainly the purpose of the aging period, but I think this >> overstates its value in the SRU process overall. You say you believe you >> have seen this happen in practice, to block a buggy SRU before it reached >> -updates. But broadly speaking: >> >> - dist-upgrading (or trying to use update-manager) with -proposed is a bad >>idea for a production machine, because packages in -proposed are known >>not to be consistently installable throughout the SRU lifecycle >> - therefore, running with -proposed enabled is not something that is >>broadly socialized (nor should be) as a way for users to contribute to >>the quality of Ubuntu >> - therefore, random user testing coverage of SRUs is sparse, whether we >>wait 7 days or 30. > > Nevertheless, I think that wider random user testing coverage of > packages in proposed should be something we aim to achieve. This is > something I've mentioned before[1]. I'm confident that we have enough of > a community willing to live on the edge that they would be willing to do > this: if we make it easy for them and publish this as "a way to help > out". Regardless of whether or not we can do this today, removing the > aging period moves us in the opposite direction. > >> There is *some* value to an aging period, which is why I have never >> advocated dropping the default aging period entirely. But the value is >> small, not straightforwardly quantifiable, and doesn't outweigh the cost in >> human developer time of multiple round-trips with the SRU team; so whenever >> anyone asks to waive the waiting period, and I don't have /specific/ >> concerns about the SRU, my answer will be yes. > > I disagree. Since aging is something we consider worthy enough to have > in our policy by default, I think that waiving the aging period in a > specific case
Re: First set of 16.04.5 RC images ready for testing
Hey! On 31 July 2018 at 06:33, flocculant wrote: > On 31/07/18 02:19, Lukasz Zemczak wrote: >> >> Hello everyone, >> >> The first set of official working builds for the upcoming xenial >> 16.04.5 point release (due this Thursday, August 2nd) have been added >> to the tracker [1] for all supported flavours. We had a few images for >> this milestone already but had to re-spin due to quickly spotted >> regressions. The ones now seem to be test-worthy at least. > > Would be useful to know what the regressions were ... The first set of images were completely busted due to an out-of-sync issue on cdimage (cdimage had an older debian-installer than what was in the image itself and archive). The second batch had an issue when using the debian-installer based installer with the default GA 4.4 kernel, causing a kernel panic. This was caused by the last minute SCSI fix we got in (due to 4.4 behaving differently than 4.15 which the fix was targeting). Basically it meant that no server install using regular non-hwe kernels could be done. >> >> >> Which is why please proceed with testing as soon as possible. Even >> though we still have some days until the planned release, don't wait >> until the last minute - the earlier testing starts the more time we >> might have for fixing any blockers found during testing. > > You mean the earlier that testing starts, the sooner we can rebuild, so your > testing gets reset to zero again ;) > > It pretty much makes sense to wait before testing out in the real world > where we test manually. If people wait with the testing and then actually *do* find a release-critical regression last minute, we'll basically won't be able to re-spin and release in time. If we did as you say and did not start performing sanity tests on the two earlier batches as soon as we did, we wouldn't know things are completely busted. Now imagine this happening a day before release. Fast-tracking a fix in through -proposed to -updates and rebuilding all images takes at least a few hours + the re-testing. Yes, it's annoying that testing gets invalidated early and people have to re-test the same thing a few times, but it's a cost worth paying to not have to do an all-nighter before release in case something bad happens. Bugs can pop up everywhere, some can effect only certain flavours and can be potentially caused by even seemingly unrelated changes. This was also the reason why only after the third rebuild batch the call-for-testing was sent out: the first two weren't ready. >> >> As mentioned >> by Adam during the 18.04.1 call-for-testing: images that have no >> testing can't be released! >> >> Good luck! >> >> [1] http://iso.qa.ubuntu.com/qatracker/milestones/393/builds >> >> Cheers, >> > Cheers > > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
First set of 16.04.5 RC images ready for testing
Hello everyone, The first set of official working builds for the upcoming xenial 16.04.5 point release (due this Thursday, August 2nd) have been added to the tracker [1] for all supported flavours. We had a few images for this milestone already but had to re-spin due to quickly spotted regressions. The ones now seem to be test-worthy at least. Which is why please proceed with testing as soon as possible. Even though we still have some days until the planned release, don't wait until the last minute - the earlier testing starts the more time we might have for fixing any blockers found during testing. As mentioned by Adam during the 18.04.1 call-for-testing: images that have no testing can't be released! Good luck! [1] http://iso.qa.ubuntu.com/qatracker/milestones/393/builds Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Releasing systemd 237-3ubuntu10.2 bionic SRU
Hey Dimitri, Noted, I will be releasing the package soon. Since the systemd/armhf is a known failure that should be ignore, I will also be updating the hints for it so that it doesn't pop up all the time - but please remember to fix it with the next upload. Cheers, On 19 July 2018 at 11:43, Dimitri John Ledkov wrote: > Dear release team, > > Please release 237-3ubuntu10.2 bionic SRU. All bugs have been > validated, and it has been aged. > > There are two adt regressions on the report, which imho should be > ignored as neither are regressions. > > systemd/armhf - the sleep/hybernate offset patchset introduced a new > testcase/assertion, which fails to pass when confined in lxd/lxc, but > works on baremetal. The test was not correctly guarded for our lxd/lxc > confinment and is to be fixed. It is the last assertion in the > test-sleep binary, and all other tests pass. This is to be fixed, in > the next SRU, or this extra test case dropped from bionic. > > linux/s390x - stree-ng personality tests cases are failing, as per > cking this has been fixed, I'm currently reruning the linux/s390x on > bionic and it should pass, if not, I will followup with cking on that. > Otherwise, there is nothing in linux/s390x adt tests results > indicating any other failures or regressions that may have been caused > by systemd userspace. > > Please release 237-3ubuntu10.2 into bionic-updates. > > -- > Regards, > > Dimitri. > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Ubuntu base language-pack refresh for 18.04.1
Hello everyone, For the first upcoming point-release for bionic we have decided to do a full base language-pack refresh for all languages. We already did a similar thing for xenial 16.04.1 so it's not anything completely new and unusual, but it's worth noting as the usual steps for upgrading translations in point-releases is a different. What this means is that, if no regressions are reported for the newly uploaded language-pack-* packages for a given language, those will be released into -updates regardless of how well they were actually tested. This carries some risk of course, but the number of languages submitting test results for regular translation updates is usually quite low so most just end up being outdated. We're still early in the cycle for bionic so the risk of regressing is quite low. That being said, please try giving the new language-pack-* packages for your language from bionic-proposed a spin to check if there are any obvious visible regressions. We will let them age a bit before proceeding further, but seeing that 18.04.1 is nearing close we might have to act fast. Cheers, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Please document & announce merge proposals workflow for the ProposedMigration hints
Hey Dimitri, I agree we should potentially be more informative about what to do in the uncommon case of tests needing being ignored and packages hinted in because of, let's say, some other package in the archive introducing a regression what went unnoticed, thus blocking package migration (requiring a fix in the other package). That being said, we should make sure to be clear that hinting is not the only way to go and should be done if there's no other sensible way to go forward - I wouldn't want developers taking this new part of the documentation as an excuse to not fix their broken tests instead of just fixing them with a subsequent upload. We should mention it's all for cases like tricky transitions or simply breakages that are unrelated and not fixable in the package itself. I can try fitting something in like that in the documentation. I guess it would be nice to also document the hint syntax, as I don't know if we already have a place with that explained. It was usually just something one was either learning from others or from reading the code, which is not how it should be for sure. Cheers, On 20 June 2018 at 16:35, Dimitri John Ledkov wrote: > Dear Release team, > > Please document on https://wiki.ubuntu.com/ProposedMigration something > along the lines - What to do if tests have regressed/broken in the > release? > > And explain that one should write hints and make merge proposals > against the ubuntu-release file. > > Also please explain the supported hints and their format. I've managed > to construct some of them, but it is a bit fragile / non-intuitive. > > Also do a one-off announce on ubuntu-devel@ mailing list that hints > overrides should be done as merge proposals and not ad-hoc IRC pings > on #ubuntu-release, with copy & paste of the new doc section about it. > > Since merge proposals, appear to be much easier to discuss / review / > queue process, and have history available about them. > > This is a crucial bit that is missing from ProposedMigrations > documentation, and I think lack of docs/advertisement on "how to make > hints changes happen" affects many developers and should be publicized > / re-advertised more widely. > > -- > Regards, > > Dimitri. > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: SRUs solely for dep8 updates
Usually, whenever I see an SRU that only attempts to fix an autopkgtest regression, I first check how frequently the given package receives regular updates. If I see the package is really 'popular' and gets a lot of love for the stable series, I reach out to the uploader for him/her to consider bundling the change in the nearest bigger SRU. But for most packages I just accept those changes as they are, since there is no guarantee when the nearest regular SRU will be prepared. My general take on autopkgtest-fix-only SRUs can be summarized with: "it's not that big of a deal". In the common case, accepting and then handling of the SRU does not waste enough of my time and resources for me to consider bouncing it back. The verification of such bugs is also very easy, so those have a potential of not lingering in -proposed for too long. Uploads are cheap, IMO. And since such uploads potentially do make things easier for both me, as an SRU member, and the developer, that's usually a green light for me. Autopkgtest regressions frequently cause uploads to get blocked for longer periods of time, usually with us waiting for the uploader to assess if it's a regression or not, with ubuntu-sru having to sometimes 'remind' people in the comments about those as well. The faster an autopkgtest regression is fixed, the better for both sides. Of course this all depends on the actual change - if the change does not only affect code of the test, the situation is different. As always it's a case-by-case situation. If the concern here is related to the fact that such uploads can block other, real bugfix uploads before the autopkgtest fix gets released into -updates, I don't think that's much of a problem. When dealing with autopkgtest fixes that get 'blocked' in -proposed without verification for too long, I generally wouldn't mind someone to upload an upload 'on top' of that version (if the changes are preserved with a -v during source build) and proceeding. The only verification required is anyway checking if the failure is indeed fixed or not. We could also think of maybe some 'fast-track' rule for such uploads, but on the other hand I guess it's really not worth complicating our rules. Here again my earlier summary shows: "it's not that big of a deal". That's my humble POV. Cheers, On 24 March 2018 at 01:48, Steve Langasek wrote: > On Thu, Mar 22, 2018 at 10:04:11AM +, Robie Basak wrote: >> > > I've always been reluctant to accept SRUs for things that are not user >> > > impacting. > >> > > For consistency, please could we decide a policy on this? > >> > To understand, are you looking for consistency because you think the policy >> > should be to reject autopkgtest-only fixes and you don't want uploaders to >> > shop their upload around to multiple SRU team members to get the answer >> > they >> > want? Or is it that you think it's unfair to uploaders and a waste of >> > their >> > time to have done work that might then be rejected? Or some other reason? > >> I think consistency saves wasting everyone's time, so all of the above. >> Uploaders would know what to expect and SRU team mebmers won't duplicate >> review time. It would a waste for me to reject or defer an SRU and for >> another SRU team member to later accept it, and frustrating for >> uploaders to be playing a lottery like that. > > I agree that this would be wasteful. I'm not sure it comes up often enough > that we would be saving energy by attempting to (agree on and) adopt a hard > policy, however. > > My own view is that for the specific narrow case of a package whose > autopkgtests have regressed post-release, and there are dependencies of that > package being SRUed, and there is an Ubuntu developer who cares enough about > the regressed package to prepare an upload a fix, it is reasonable to accept > an SRU for this. > > I'm interested to hear the opinion of other members of the SRU team as well. > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developerhttp://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release > -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Xenial 16.04.4 Call For Testing (All Flavours)
Hey Ian! Please see my earlier message to ubuntu-release@ - all the release candidates for .4 are being re-built, i.e. new images for each flavour are being created. This essentially means some testing needs to be re-done, sadly. But this should be the final set of images for this milestone. Please wait for the builds to finish (should only take a little while) and then resume testing. Thank you! On 28 February 2018 at 19:30, Ian Bruntlett wrote: > Hi Lukasz, > > On 23 February 2018 at 22:33, Lukasz Zemczak > wrote: >> >> Hello everyone, >> >> Some time ago our first release candidate builds for all flavours that >> released with xenial have been posted to the ISO tracker [1] into the >> 16.04.4 milestone. >> >> As with each point-release, we would need volunteers to grab the ISOs >> of their flavour/flavours of choice and perform general testing. We >> obviously are mostly looking for regressions from 16.04.3, but please >> fill in any bugs you encounter (against the respective source packages >> on Launchpad). There is still time until the target release date on >> 1st of March, but for now we're not considering pulling in any more >> fixes besides ones for potential release-blockers that we encounter. >> >> With enough luck the images that have been made available just now >> might be the ones we release on Thursday. >> >> Thank you! >> >> [1] http://iso.qa.ubuntu.com/qatracker/milestones/386/builds > > > OK, I've downloaded these two isos:- > f10dfd15204c47177da81a3029c54220 *xenial-desktop-amd64.iso > 8513386307089f23f03a924b108740f5 *xenial-desktop-i386.iso > > Now I only had enough time to install it on a 32-bit system, a Dell Latitude > D610. I worked my way through my lubuntu-refurbishing-a-computer notes that > can be found from the bottom of this page:- > https://sites.google.com/site/ianbruntlett/home/free-software and the whole > system worked fine although I had to do a bit of searching to work out how > to get internal Wi-Fi working (install packages firmware-b43-installer". > > I was going to log this but when I got to this page - > http://iso.qa.ubuntu.com/qatracker/milestones/386/builds - it said the > builds were being rebuilt. What is all that about? > > BW, > > > > Ian > > -- > -- ACCU - Professionalism in programming - http://www.accu.org > -- My writing - https://sites.google.com/site/ianbruntlett/ > -- Free Software page - > https://sites.google.com/site/ianbruntlett/home/free-software > -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Xenial 16.04.4 Call For Testing (All Flavours)
Another note to testers: sadly a second re-spin of our candidate images is required. I will be performing those in some moments after making sure everything we need is in the -updates pocket. Hopefully this will be the last one - content-wise for flavours besides ubuntu-server and, well, netboot there will be no functional changes in the images, so possibly a sanity install-check should be enough for those that already had their testing finished. I will be helping out with those as well, so I do not expect this to delay the final release date. Thanks, On 26 February 2018 at 11:55, Lukasz Zemczak wrote: > A note to all testers: I am doing a quick re-spin of the .4 images as > I missed a bzr pull step at one place (thanks infinity, jibel) and the > resulting image version number was wrong. The image contents > themselves have not changed so no re-testing is needed - so please > carry over test results from the previous RC where needed. > > Thanks, > > On 23 February 2018 at 23:33, Lukasz Zemczak > wrote: >> Hello everyone, >> >> Some time ago our first release candidate builds for all flavours that >> released with xenial have been posted to the ISO tracker [1] into the >> 16.04.4 milestone. >> >> As with each point-release, we would need volunteers to grab the ISOs >> of their flavour/flavours of choice and perform general testing. We >> obviously are mostly looking for regressions from 16.04.3, but please >> fill in any bugs you encounter (against the respective source packages >> on Launchpad). There is still time until the target release date on >> 1st of March, but for now we're not considering pulling in any more >> fixes besides ones for potential release-blockers that we encounter. >> >> With enough luck the images that have been made available just now >> might be the ones we release on Thursday. >> >> Thank you! >> >> [1] http://iso.qa.ubuntu.com/qatracker/milestones/386/builds >> >> On behalf of the release team, >> >> -- >> Łukasz 'sil2100' Zemczak >> Foundations Team >> lukasz.zemc...@canonical.com >> www.canonical.com > > > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Xenial 16.04.4 Call For Testing (All Flavours)
A note to all testers: I am doing a quick re-spin of the .4 images as I missed a bzr pull step at one place (thanks infinity, jibel) and the resulting image version number was wrong. The image contents themselves have not changed so no re-testing is needed - so please carry over test results from the previous RC where needed. Thanks, On 23 February 2018 at 23:33, Lukasz Zemczak wrote: > Hello everyone, > > Some time ago our first release candidate builds for all flavours that > released with xenial have been posted to the ISO tracker [1] into the > 16.04.4 milestone. > > As with each point-release, we would need volunteers to grab the ISOs > of their flavour/flavours of choice and perform general testing. We > obviously are mostly looking for regressions from 16.04.3, but please > fill in any bugs you encounter (against the respective source packages > on Launchpad). There is still time until the target release date on > 1st of March, but for now we're not considering pulling in any more > fixes besides ones for potential release-blockers that we encounter. > > With enough luck the images that have been made available just now > might be the ones we release on Thursday. > > Thank you! > > [1] http://iso.qa.ubuntu.com/qatracker/milestones/386/builds > > On behalf of the release team, > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > lukasz.zemc...@canonical.com > www.canonical.com -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Xenial 16.04.4 Call For Testing (All Flavours)
Hello everyone, Some time ago our first release candidate builds for all flavours that released with xenial have been posted to the ISO tracker [1] into the 16.04.4 milestone. As with each point-release, we would need volunteers to grab the ISOs of their flavour/flavours of choice and perform general testing. We obviously are mostly looking for regressions from 16.04.3, but please fill in any bugs you encounter (against the respective source packages on Launchpad). There is still time until the target release date on 1st of March, but for now we're not considering pulling in any more fixes besides ones for potential release-blockers that we encounter. With enough luck the images that have been made available just now might be the ones we release on Thursday. Thank you! [1] http://iso.qa.ubuntu.com/qatracker/milestones/386/builds On behalf of the release team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Requesting DPDK MRE
Hello Christian! As you can see on the SRU policy page [1] the MRE for DPDK has been already approved some time ago. I thought I communicated that on IRC, but maybe I should have been more explicit. Sorry for that. Cheers, [1] https://wiki.ubuntu.com/StableReleaseUpdates#DPDK On 4 January 2018 at 08:23, Christian Ehrhardt wrote: > Ping, > please let me know if I should do anything else than waiting for your > decision. > > On Mon, Dec 18, 2017 at 4:00 PM, Christian Ehrhardt > wrote: >> On Fri, Dec 15, 2017 at 8:09 AM, Christian Ehrhardt >> wrote: >>> Hi, >>> I revised my former misguided request to the TB [1] after learning about >>> [2]. >>> For that I have now prepared [3] to be discussed and hopefully >>> approved and included in [2]. >> >> FYI a similar request for an update to 16.04 in current Debian. >> => https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884711 >> >>> If there is any SRU team meeting or such I should participate to >>> discuss please let me know. >>> >>> -- >>> Christian Ehrhardt >>> Software Engineer, Ubuntu Server >>> Canonical Ltd >>> >>> [1]: >>> https://lists.ubuntu.com/archives/technical-board/2017-December/002335.html >>> [2]: >>> https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases >>> [3]: https://wiki.ubuntu.com/StableReleaseUpdates/DPDK >> >> >> >> -- >> Christian Ehrhardt >> Software Engineer, Ubuntu Server >> Canonical Ltd > > > > -- > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
New 16.04.4 point release date: 1st of March
As announced previously the release of the 16.04.4 point release has been delayed. Seeing that things are now settling in, we have set the 1st of March as the new planned date release date. We expect to have all the required pieces available in the archive by that time and will provide images with all the necessary security fixes in place. On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
16.04.4 point release delayed; new date TBD
Due to the ongoing evolution of the fixes for the recently announced Meltdown and Spectre security vulnerabilities [1], we are delaying the 16.04.4 point release, originally scheduled for the week of February 15. We intend that, when it is released, 16.04.4 will include kernels which mitigate these severe vulnerabilities. We also recognize that, because updates for these security vulnerabilities are currently monopolizing the SRU queue for kernels, there is no opportunity for any other point-release-critical fixes to be included, and we need to allow the dust to settle a bit before putting the finishing touches on the point release. We are currently unable to set a new firm date for the release, but we do not expect the schedule to slip more than a few weeks. We will send a follow-up email once more is known. [1] https://insights.ubuntu.com/2018/01/24/meltdown-spectre-and-ubuntu-what-you-need-to-know/ On behalf of the Ubuntu Release Team, -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
