Re: Lubuntu LTS Requalification: 24.04 Noble Numbat
Hey Simon, Lukasz, I'm also giving a +1 for Lubuntu-3years-LTS Cheers, Sébastien Le 17/01/2024 à 11:13, Lukasz Zemczak a écrit : 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.
Re: Status of the Noble archive opening
Hey Lukasz, I didn't know we had the option to make some of our JIRA boards public, that's great, thanks for sharing! Should we perhaps reference it in the IRC release channel until the archive is actually open (the title still states 'Archive: Final Freeze')? Having a discourse post would also be nice, especially if it contains a more easily understandable description of the current status and expectations (the JIRA cards is a long list but for example the toolchain one didn't include details on what toolchain changes we plan to do and how long it's going to have those in place) Cheers, Sébastien Le 25/10/2023 à 15:47, Lukasz Zemczak a écrit : 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 -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Status of the Noble archive opening
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
Documenting the ubuntu-sru team membership process
Dear Ubuntu SRU Team members, I've started a discussion [1] at the TB level about the fact that some of the Ubuntu project teams don't really communicate on how they are working, especially on how they select new members, which I think is detrimental to the project. During one of the recent TB meetings [2] we went to an agreement that it would be nice if the core project teams could at least document their membership process. We could then add the references https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations. I've an action items from the TB to reach out to the concerned teams to ask if they could provide a such documentation, which is why I'm writing to you now. Let me know if I can help with the process. Thanks in advance, Sébastien Bacher [1] https://lists.ubuntu.com/archives/technical-board/2023-June/002741.html [2] https://irclogs.ubuntu.com/2023/07/11/%23ubuntu-meeting.html -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Documenting the ubuntu-release team membership process
Dear Ubuntu Release Team members, I've started a discussion [1] at the TB level about the fact that some of the Ubuntu project teams don't really communicate on how they are working, especially on how they select new members, which I think is detrimental to the project. During one of the recent TB meetings [2] we went to an agreement that it would be nice if the core project teams could at least document their membership process. We could then add the references https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations. I've an action items from the TB to reach out to the concerned teams to ask if they could provide a such documentation, which is why I'm writing to you now. Let me know if I can help with the process. Thanks in advance, Sébastien Bacher [1] https://lists.ubuntu.com/archives/technical-board/2023-June/002741.html [2] https://irclogs.ubuntu.com/2023/07/11/%23ubuntu-meeting.html -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Transitioning the sync-blacklist vcs to git
Le 05/07/2023 à 22:51, Steve Langasek a écrit : Outstanding MPs for +junk branches are obviously not an issue, but for u-a-scripts there's: https://code.launchpad.net/~ubuntu-archive/ubuntu-archive-scripts/trunk/+activereviews still awaiting feedback from another AA. That has been merged now and I've updated the git import Let's settle some of these changes out on the existing bzr branch before switching it to git, please. Alright Cheers, Sébastien -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Transitioning the sync-blacklist vcs to git
Thanks Steve for reviewing and merging the changes! Since that landed I also went ahead and converted that one https://code.launchpad.net/ubuntu-archive-scripts/+git If that's ok with others should we also deprecate the corresponding bzr repository? There is a checkout on ubuntu-archive-toolbox with some local delta (are those changes still needed? could they be pushed to the vcs?) which I can switch (reapplying the local changes for now) Cheers, Sébastien Le 05/07/2023 à 18:31, Steve Langasek a écrit : - https://ubuntu-archive-team.ubuntu.com/sync-blocklist.txt exists, so landing the ubuntu-archive-tools changes (including the checkout on ubuntu-archive-toolbox) - pushed the breadcrumb to the old bzr branch Thanks, -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Transitioning the sync-blacklist vcs to git
And corresponding changes to the archive utilities https://code.launchpad.net/~seb128/ubuntu-archive-tools/+git/ubuntu-archive-tools/+merge/446082 https://code.launchpad.net/~seb128/ubuntu-archive-scripts/blocklist/+merge/446079 Cheers, Sébastien Le 05/07/2023 à 15:39, Sebastien Bacher a écrit : I'm going to assume that we want to take the opportunity to do the inclusive naming change and pushed a new vcs there https://code.launchpad.net/~ubuntu-archive/+git/sync-blocklist Cheers, Sébastien Bacher Le 05/07/2023 à 11:43, Sebastien Bacher a écrit : Hey there, I've imported the sync-blacklist bzr repository [1] to git [2] and submitted a merge request [3] to update the update-sync-blacklist job to use the git location Now I've some questions for archive/release team members 1. do you know of any other script/job that needs to be updated for the Vcs move? 2. do we need to manually update the ubuntu-archive-scripts checkout on the archive server or is that automated? 3. Should we try to fix https://bugs.launchpad.net/ubuntu-archive-scripts/+bug/1915708 at the same time and rename blacklist to blocklist (inclusive naming)? And if so do we think we need some sort of compat symlink at least for the file exported on https://people.canonical.com/~ubuntu-archive/sync-blacklist.txt? Cheers, Sébastien [1] https://code.launchpad.net/~ubuntu-archive/+junk/sync-blacklist [2] https://code.launchpad.net/~ubuntu-archive/+git/sync-blacklist [3] https://code.launchpad.net/~seb128/ubuntu-archive-scripts/ubuntu-archive-scripts/+merge/445524 -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Transitioning the sync-blacklist vcs to git
I'm going to assume that we want to take the opportunity to do the inclusive naming change and pushed a new vcs there https://code.launchpad.net/~ubuntu-archive/+git/sync-blocklist Cheers, Sébastien Bacher Le 05/07/2023 à 11:43, Sebastien Bacher a écrit : Hey there, I've imported the sync-blacklist bzr repository [1] to git [2] and submitted a merge request [3] to update the update-sync-blacklist job to use the git location Now I've some questions for archive/release team members 1. do you know of any other script/job that needs to be updated for the Vcs move? 2. do we need to manually update the ubuntu-archive-scripts checkout on the archive server or is that automated? 3. Should we try to fix https://bugs.launchpad.net/ubuntu-archive-scripts/+bug/1915708 at the same time and rename blacklist to blocklist (inclusive naming)? And if so do we think we need some sort of compat symlink at least for the file exported on https://people.canonical.com/~ubuntu-archive/sync-blacklist.txt? Cheers, Sébastien [1] https://code.launchpad.net/~ubuntu-archive/+junk/sync-blacklist [2] https://code.launchpad.net/~ubuntu-archive/+git/sync-blacklist [3] https://code.launchpad.net/~seb128/ubuntu-archive-scripts/ubuntu-archive-scripts/+merge/445524 -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Transitioning the sync-blacklist vcs to git
Did you read the email to the end? That question is what I was asking in 3. Le 05/07/2023 à 12:13, Julian Andres Klode a écrit : On Wed, Jul 05, 2023 at 11:43:32AM +0200, Sebastien Bacher wrote: Hey there, I've imported the sync-blacklist bzr repository [1] to git [2] and submitted a merge request [3] to update the update-sync-blacklist job to use the git location Can we rename it to sync-blocklist while we're at it? -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Transitioning the sync-blacklist vcs to git
Hey there, I've imported the sync-blacklist bzr repository [1] to git [2] and submitted a merge request [3] to update the update-sync-blacklist job to use the git location Now I've some questions for archive/release team members 1. do you know of any other script/job that needs to be updated for the Vcs move? 2. do we need to manually update the ubuntu-archive-scripts checkout on the archive server or is that automated? 3. Should we try to fix https://bugs.launchpad.net/ubuntu-archive-scripts/+bug/1915708 at the same time and rename blacklist to blocklist (inclusive naming)? And if so do we think we need some sort of compat symlink at least for the file exported on https://people.canonical.com/~ubuntu-archive/sync-blacklist.txt? Cheers, Sébastien [1] https://code.launchpad.net/~ubuntu-archive/+junk/sync-blacklist [2] https://code.launchpad.net/~ubuntu-archive/+git/sync-blacklist [3] https://code.launchpad.net/~seb128/ubuntu-archive-scripts/ubuntu-archive-scripts/+merge/445524 -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Debian release date and Debian Import Freeze
Hey there, I agree with Jeremy there and I would prefer to take on some extra load this cycle and avoid extra disruptions during the LTS cycle. If there are specific concerns about some transitions maybe we can go the other way around and avoid syncing some specific components instead? Cheers, Sébastien Le 25/05/2023 à 02:47, Michael Hudson-Doyle a écrit : Hi release team, Debian bookworm is scheduled to be released on June 10. Debian Import Freeze is currently scheduled for about six weeks later, on August 17. Do we want to shut off debian imports early, basically as soon as bookworm releases, to avoid having all our work overwhelmed by a bunch of transitions in Debian? Cheers, mwh -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Replacing the telegram-desktop deb by a snap installer in stable series?
Le 25/01/2023 à 11:38, Robie Basak a écrit : I think this will probably need some discussion within the SRU team. To help with that, do you know if this (deb to snap transition) has been done before within a stable series, or is there anything like that planned for any other package? No, I'm not aware of another case where that was done before or where it's planned for a SRU. Cheers, Sebastien -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Replacing the telegram-desktop deb by a snap installer in stable series?
Hey there, In Lunar we changed the telegram-desktop deb to be 'a snap installer', which was done on upstream request. The telegram-desktop snap is maintained by upstream. Now we are considering doing the same in stable series, I would like to get some input on the topic (probably from the SRU team?). The initial request has been registered on https://launchpad.net/bugs/2000552, copying the rational ' > This package is not maintained by the upstream project maintainers and it gets lots of reports about crashes and bugs. I would like to suggest a transition to a snap installer so that installing > this package would automatically install official snap package of Telegram Desktop: > https://snapcraft.io/telegram-desktop > Like it was done for Firefox, Chromium. > That way the upstream maintainers could take care of the users of this package. Thank you.' We also have issues because the outdated client doesn't handle well newer server side features, for example https://launchpad.net/bugs/1998127 > The old version of telegram installed via apt does not display messages containing characters added in newer versions. We have a few options there 1. Fixing the deb in older series, either by updating the version or backporting changes. That's complicated though since new versions also have new requirements. We also don't have resources to allocate to those updates nor seen contributors interested in helping. 2. Empty the deb and recommend users to install the software from upstream directly. 3. Replace the deb by a snap installer. We believe that 3. is the best solution for us and our users. How would the SRU team feel about going that way? Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [SRU] Is there a process to have universe sources promoted to main in stable series?
Thanks Lukas and Utkarsh for the replies. I've targeted those MIR reports to 22.04 now as you suggested. I'm mentioning them for reference as I'm unsure if they would show up on your standard query since the 'active serie' status is fix released and by default launchpad buglists don't show past series unless specified. https://bugs.launchpad.net/ubuntu/+source/webp-pixbuf-loader/+bug/1979121 https://bugs.launchpad.net/ubuntu/+source/libwpe/+bug/1973031 https://bugs.launchpad.net/ubuntu/+source/wpebackend-fdo/+bug/1973033 Cheers, Sebastien Le 01/12/2022 à 12:23, Lukas Märdian a écrit : Hi Sebastien, Am 01.12.22 um 11:31 schrieb Sebastien Bacher: Hey there, That's a question probably for the SRU team. The question if a new software feature can be enabled in a stable series post feature freeze is probably a question for the SRU team, indeed. But I don't think there's any formal process to it. But this case also requires involvement of the MIR team, IMO. I've recently uploaded webp-pixbuf-loader as a new package to 22.04 (SRU https://launchpad.net/bugs/1993789). The goal is to enable webp support on the desktop in the LTS. The package got promoted to main in Kinetic. I would like to know if there is a formal process to ask for promotion in a stable serie? The intend is to have the package pulled it by our default image viewer (eog), so that would be a SRU to eog adding a depends or recommends on webp-pixbuf-loader. Can I go ahead with the SRU or should I get input from the MIR team first? First, we (the MIR team) had a very similar case with fwupd -> protobuf-c in the past, although that was for hardware enablement, which might be a bit stronger case than enablement of a new software feature: https://bugs.launchpad.net/ubuntu/+source/protobuf-c/+bug/1956617 So retroactive promotion to "main" in stable series is possible and has been done in the past, and we've been using the normal MIR process to find consensus. The MIR and potentially security teams should agree, which should be easy if the same version of a software is already supported in another series. I'd suggest using the same MIR bug, adding the required target series, to get formal agreement from the MIR and security teams, before uploading any SRU pulling in the new dependency. Also for webp-pixbuf-loader the version in 22.04 is the same than the one that got reviewed and promoted by the MIR team, but we have another similar need for webkitgtk where we would like to build using libwpe/wpebackend-fdo but in this case the version in 22.04 is older than the one that got promoted in Kinetic, would that change the answer? As outlined above, I'd suggest to use the same MIR bug that was used for promotion in Kinetic, adding the required target series and asking for MIR review/ACK from the corresponding teams, before uploading an enablement SRU. It might be harder, require some extra work or even not be possible at all to get the older (currently unsupported) version of a software promoted to main, depending on the MIR/security assessment. Cheers, Lukas -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[SRU] Is there a process to have universe sources promoted to main in stable series?
Hey there, That's a question probably for the SRU team. I've recently uploaded webp-pixbuf-loader as a new package to 22.04 (SRU https://launchpad.net/bugs/1993789). The goal is to enable webp support on the desktop in the LTS. The package got promoted to main in Kinetic. I would like to know if there is a formal process to ask for promotion in a stable serie? The intend is to have the package pulled it by our default image viewer (eog), so that would be a SRU to eog adding a depends or recommends on webp-pixbuf-loader. Can I go ahead with the SRU or should I get input from the MIR team first? Also for webp-pixbuf-loader the version in 22.04 is the same than the one that got reviewed and promoted by the MIR team, but we have another similar need for webkitgtk where we would like to build using libwpe/wpebackend-fdo but in this case the version in 22.04 is older than the one that got promoted in Kinetic, would that change the answer? Thanks, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Desktop UIFEs requests
Hey there, We have a few pendings UIFes we would like get reviewed if possible https://bugs.launchpad.net/ubuntu/+source/ubuntu-wallpapers/+bug/1966105 https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1965993 https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1965996 Thanks, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Desktop FFes
Could we also get that one reviewed? https://bugs.launchpad.net/ubuntu/+source/libvdpau/+bug/1964674 Le 18/03/2022 à 11:25, Sebastien Bacher a écrit : hey there, We would like to add that one to the list https://bugs.launchpad.net/ubuntu/+bug/1965006 Thanks, Sebastien Bacher Le 15/03/2022 à 22:03, Jeremy Bicha a écrit : Hi, The Desktop Team has some Feature Freeze exceptions we'd like to see reviewed before User Interface Freeze. https://launchpad.net/bugs/1963241 evince 42 (I responded to the questions) https://launchpad.net/bugs/1964732 Desktop Icons Settings https://launchpad.net/bugs/1964132 webkit2gtk built with libsoup3 (& epiphany-browser built against both) Thank you, Jeremy Bicha -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Desktop FFes
hey there, We would like to add that one to the list https://bugs.launchpad.net/ubuntu/+bug/1965006 Thanks, Sebastien Bacher Le 15/03/2022 à 22:03, Jeremy Bicha a écrit : Hi, The Desktop Team has some Feature Freeze exceptions we'd like to see reviewed before User Interface Freeze. https://launchpad.net/bugs/1963241 evince 42 (I responded to the questions) https://launchpad.net/bugs/1964732 Desktop Icons Settings https://launchpad.net/bugs/1964132 webkit2gtk built with libsoup3 (& epiphany-browser built against both) Thank you, Jeremy Bicha -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Include transitions in the feature freeze definition
Hey ubuntu release! Reading https://wiki.ubuntu.com/FeatureFreeze it doesn't seem to cover packaging changes, but renaming a binary can have an high impact on the archive. I'm proposing that we add 'starting a transition' as something that requires a ffe. Why? The practical situation that made me check the definition is https://bugs.launchpad.net/ubuntu/+source/libffi/+bug/1943288. The libffi soname means that some days before beta we are having - lot of rebuilds which are keeping the builders busy and creating delays - packages blocked in proposed for over a week, beta freeze is monday (which means tomorrow if we don't count on people working during the weekend) - our fixes and improvement not landing on the daily ISO and tested before beta This is going to have a negative impact on our beta quality, I think the freezes should protect us against those disturbances. (the libffi update might be covered by the current rules so let's not discuss that particular case. We could take a poppler update as an example instead since upstream bumps the soname at every new version even if those include no API changes and only bugfixes) Thanks for considering, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[SRU discussion] Renaming the 'Regression Potential' section
Hey there, I hit another of those bugs where the well intended controbutor spent time writing a 'low ', 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
Re: Hirsute opening status?
Hey Christian, Thanks for the reply. Indeed checking the status is easy enough (also uploads return a 'waiting for approval' email instead of accepted). Is it fine to upload in the queue though or should we hold on if possible until the freeze is lifted? The fact it's frozen doesn't tell us when we expect our work to be unblocked or how we can help to get there though. Laney kindly pointed out that https://people.canonical.com/~ubuntu-archive/transitions/html/python3.9-add.html was something currently being worked on, it's unclear to me if we want that transition to be finished before accepting other uploads (how long is that likely to take, days? weeks?). I'm also not sure if that's the only thing blocking. I'm Cc-ing ubuntu-release@ now, maybe they can help answering some of those questions. Cheers, Sebastien Bacher Le 27/10/2020 à 07:18, Christian Ehrhardt a écrit : > I'm in no way denying the usefulness of such a mail, but as a hint for > self-checking the state > I can recommend to look at the release pages like [1] and avoid > uploading before the status > "Pre-release Freeze" is gone there. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Could we make easier for contributors to get involved in the release preparations?
Hey Release Team, First congrats on getting the new Ubuntu release out! I'm writing there because I had hoped that having the release sprint a virtual event instead of an in-person one would be an opportunity to make possible to better include others (the persons not at the organized event). In practice it feels like there was not much difference compared to previous cycles and I found that a bit sad. Probably the release-people-are-in-the-room got replaced by release-people-are-in-the-same-hangout but #ubuntu-release on IRC got little attention (I personally asked some questions and pointed out some uploads but got no reply or comment about, I noticed it was true for others as well). The team used a discourse post for status updates, while it's nice to have an idea of where things are it's not a communication channel for the actual work being done on issues. I've personally tried to help with some flagged problems. I debugged a bit lightdm-gtk-greeter segfaulting and discussed that on IRC (got no traction or reply) and tried to help with an audio issue which was flagged by the team by doing some testing and sponsoring a fix which was made available, to realize that others from the in-real-event had been doing the same work, not commenting in public on IRC or updating the launchpad bug status which did lead to a duplicate upload and a rejection. I find the experience quite frustating and at this point I wonder if it's worth for people out of the release team to be actively involved in try to resolve issues or if the team simply prefers to focus as a small group on debugging and fixing things? If outside help is welcome I would suggest we try to make possible for others to stay in the loop, maybe by making the hangout public so it's possible to really join the discussions or by moving things a bit more on IRC? Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: LibreOffice SRUs
Hey there, Le 17/09/2020 à 18:52, Brian Murray a écrit : > Do you know if there plans to switch stable releases to using the > libreoffice snap? There is no concrete plan at the moment to switch any serie to use the snap, the deb is still what we install by default and we expect to continue to SRU stable updates. Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: An updated version of proposed-migration is available to review
Hey Iain, thanks for the work! Le 16/06/2020 à 19:07, Iain Lane a écrit : > If you can see anything that's *wrong* in the output linked above, > please let me know. If you run any scripts which parse the yaml, please > try them against > > > https://people.canonical.com/~ubuntu-archive/laney/proposed-migration/update_excuses.yaml > > and ideally adapt them as necessary. (That's a .xz compressed version which is a bit confusing) The by-team-report is unhappy with the new file, it doesn't like the policy_info/autopkgtest section having no package listed, e.g from gcc-9 policy_info: autopkgtest: verdict: REJECTED_TEMPORARILY Skipping those cases as a test workaround gives a report where bug references are buggy (listed as #0). I plan to work on those issues tomorrow Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Not requiring SRU changes to be in $current-stable to go in the LTS
Hey Steve, Le 09/03/2019 à 21:26, Steve Langasek a écrit : > So I will always ask an uploader to also SRU the fixes to the interim > releases if I see that they haven't been, because as Robie says, we also > have made a committment to support these releases. But I also am unlikely > to reject the LTS-only SRU if the uploader is unwilling to do the SRU to > non-LTS on the basis of their cost-benefit analysis. Thanks, I agree with what you wrote and I think it's a pragmatic position. If other SRU team members are in agreement I think we can close the discussion. The SRU documentation on the wiki could do with some clarification in any case since it looks like the only requirement described today is to upload to $unstable-serie first. Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Not requiring SRU changes to be in $current-stable to go in the LTS
Hey Robie, thanks for the reply Le 09/03/2019 à 11:03, Robie Basak a écrit : > AIUI, the concern is that a user running an LTS may upgrade up to an > intermediate release, and then face regressions there for known bugs > that have known fixes that we didn't bother to fix in a supposedly > supported release. This seems inappropriate. In my view the likelihood > of needing this upgrade increases the closer we get to the next LTS as > the older LTS falls increasingly out of date. Well, at the same time, the cycle post LTS is often when we go ahead with big transitions/features that got parked in the previous cycles while we were stabilizing the LTS. The result is that those versions are often quite different/less polished/including changes|regressions compared to the LTS. I don't believe that skipping some SRUs or not is going to change the situation (at least from a desktop perspective, maybe server is in a different position) > expecting that, then we should make the project-wide decision to stop > doing the intermediate releases, rather than pretend that we are > supporting them. Right, that's a complex topic by itself so probably best to keep that aside of the current SRU one. > I don't think this necessarily needs to be a hard rule for every SRU, > but I think it should be the norm, and I'm concerned that removing the > general expectation will leave the intermediate releases effectively > unmaintained. I think it does make sense to try to make an honest effort, and I agree that we should recommend that we do SRU fixed to $current-stable. That said I personally see value doing that for important fixes/early after the new version is out, but at this point of the cycle I start feeling like that Cosmic desktop SRU aren't bringing much values, especially for 'cosmetic' fixes. Disco is likely going to be out before or soon after we do the SRU upload/review/verification dance and if our nonLTS users did manager to stay on a version with $problem until now they can probably waiting until they start using Disco to see it resolved. > However, I can imagine exceptions to always requiring SRUs into > intermediate releases. For example if a bug is difficult to reproduce or > verify, or a complication means that the fix is different and difficult > to verify, or regression risk is higher, then, combined with there being > no users evidently available to verify an intermediate release, I don't > think it would be appropriate to block the publication of an LTS fix. Again that might be more desktop specific, but I think cosmetic/polish fixes should be in that category. Often we do include fixes for minor annoyances in the LTS because users are going to be for years on that version but we don't have the resources to polish the non LTS on the same level. > Every release is "stable", not just LTS releases. If you don't see it > that way, then please let's change the discussion to "let's get rid of > intermediate releases", because it feels to me that this is the > essential reduction of your point. Supporting more releases does take > more effort! But the project has made the commitment to do this work, > and if we want to stop, then we should make it clear to users what the > new deal really is. Well, I think it mostly comes down to available resources at this point. In theory, yes, we would like to fix every single bug reported and every serie, in practice we can't. If we don't have the manpower to keep up with LTS/current stable/new serie, our options are basically 1. reduce the quantity of work we spent on $next-version in favor of stables 2. fix less issues in $stable-series, including the LTS 3. focus on the LTS which is what matters the most and skip $current-stable for some of the fixes I don't think we are going to get sign-up to do 1., so it basically it's either 2. or 3. Letting bugs unfixed in the LTS just because people don't have the capacity to do the $current-stable work sounds wrong to me. I think the consequence of the current SRU team position is that we get less SRUs in the LTS and/or that people do delay they SRUs to workaround the problem (as Steve suggested in his email). Do we have stats on the number of SRUs which end up being unverified and deleted/never rolled out to updates by serie? It's not based on facts but my got feeling is that at this point cosmic SRUs are struggling to get verifications done because most of our active contributors switched to disco and the SRUs we are currently doing are mostly going to be wasted work. Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Not requiring SRU changes to be in $current-stable to go in the LTS
(I'm not sure what's the best place to discuss the SRU process but it has been suggested that this list might be appropriate so I'm starting here) Good afternoon, From my experience, it's common practice from the SRU team to require for a bug to be fixed in $current-stable to be SRUed to the LTS (e.g to need a cosmic SRU first to be able to have a SRU for bionic). I would like to ask if we could revisit that requirement, which I believe is resource expensive and bring us little benefit. Some arguments - our team members are usually either using the current devel version or the current LTS, which means in practice the current-stable SRUs get tested in a VM or not tested at all before upload - we often get no feedback at all on the nonLTS version of the SRU, those tend to sit longer in proposed by lack of verification - the previous items leads us to often validate the LTS update before the non LTS one so we can't really argue that the nonLTS upload helps to get more testing and reduce risks on the LTS one - the non LTS/newer series are often less polished so we can't really argue that users upgrading from e.g bionic to cosmic shouldn't be exposed to problems that were resolved while they were on the LTS - it makes sense to put the extra polish effort for a LTS serie - we should trust the maintainer's judgement, often it makes sense to fix important issues in current-stable, especially after release, but as we get closer from the next stable those SRU makes less sense Reading the wiki documentation (https://wiki.ubuntu.com/StableReleaseUpdates) it seems the only documented requirement is to fix the issue in the devel version first? Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: A new Unity 8 flavour
Le 14/05/2014 18:58, Dimitri John Ledkov a écrit : As far as I understand: installation media (.iso) ability to run live-session of said image defaulting to unity8. Plus the default packageset would be different, e.g. converged apps would be pre-installed / available. Mostly what Dimitri said. Some of the avantages I see: - having a live session means it's easy to test it (no need to run the current devel Ubuntu serie on your personal machine/to install it). - it gives us a base where we can experiment with more low level changes (e.g we could start by testing system images for desktop on that image) - It's also likely that this image is going to be good enough, at some point, that we can recommend it for some users without making it the default In fact in shouldn't be lot of overhead, it's simply making the Unity 8 desktop session from the archives a first class citizen Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: A new Unity 8 flavour
Le 14/05/2014 18:09, Iain Lane a écrit : The desktop team would like to add a new flavour (ish, we don't plan to have any formal releases at this point) of Ubuntu which contains the Unity 8 desktop and the new applications which have been developed for the touch project. Hey Iain, Thanks for starting the work on the iso and for writing that email! ;-) I just wanted to add that we registered a blueprint https://blueprints.launchpad.net/ubuntu/+spec/client-1410-unity8-desktop-iso There is not much content on it yet, but I expect that to change, once we get started and identify the gaps and the things that need to be worked on next. Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Draft Utopic Release Schedule
Le 29/04/2014 01:19, Adam Conrad a écrit : If you want specific things added (like, say, vUDS[1], some important community summit/sprint for Flavour X, etc), also let me know. Hey Adam, Would it make sense to add the LTS .1 to the schedule? It seems to currently be for the same week than a 14.10 alpha, not sure if that's creating any issue Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[Desktop] Release Report 2012-12-14
(that report doesn't cover the Unity nor Xorg sides) team chart: http://status.ubuntu.com/ubuntu-raring/canonical-desktop-team.html Quite some people are on holidays so there is not going to be a lot of updates until new year === What was done engineering wise? === * libreoffice 4 is being prepared for upload to raring (bunch of new sources uploaded and NEWed, MIRs required) * webkit got updated to 1.10.2 * cups-pk-helper MIR compliance work (hardening, testing) * chromium: getting ready for the new stable release, bugsfixing * first testable version of indicator-bluetooth * some SRUing for 12.04.2 and quantal === What's about to land that might impact the other teams and release as a whole? === * Libreoffice 4 might be worth mentioning (will need MIRs reviewed/approved) === Dependencies on other teams to make deliverables, blocking items, release wide concerns? === * None so far Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Release team meeting?
Hey there, It seems like it would be a good time to resume weekly summary emails and meeting ... is that planned? What do others think? Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
How do you track bugs working on by team?
Hey, That's something I didn't find a good way to do this cycle for the desktop summaries and I wonder how other teams deal with that? I've a rough idea of what desktop is working on but I never find the time to chase down all the references to list them in those emails... Do we have any report which list all the bugs assigned to people from $team? That would be a good start but not quite a match for that list since lot of our team members have pet bugs they plan to work that are not release material... Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[Desktop] Release Meeting 2012-10-05
=== What was done engineering wise? === * Worked on the privacy lens option support across and the different lenses. * New upstream bug fix release of deja-dup and unity-greeter * Landed new webkit, with a make-dfsg upload to support it. * Landed change to qt4-x11 to make it build and stop killing arm builders * Applied upstream fixes for several CUPS crash bugs * It's now possible to play DRM protected Flash content (ie, Amazon Video) without us having to support HAL * Got to the bottom of the 2 most serious regressions introduced by the landing of webapps * Updates to GNOME a11y stack for 3.6. * Work on bug #1056300, looks like a possible GTK issue. * Add improved support to Jockey for experimental nvidia drivers. * Update xdiagnose 3.2 for bug fixes * utouch renaming underlying discussion still going on for precise and oneiric * Compiz 0.9.8.4 released done (with ABI bump). Now in quantal. Mostly bug fixes. * Unity 6.8 release * updating q-lts-backport ppa to include armel and armhf, tested it on my panda * organising a meeting on UDS about merging my optimus support work, and related future work * squashing bugs, testing quantal stack more * nvidia experimental driver work, hack on jockey and nvidia-common * triage and fix quantal bugs. Our graph is actually going *down* this cycle! http://www.bryceharrington.org/Arsenal/ubuntu-x-swat/Reports/totals-quantal-workqueue.svg * bugs fixing, bugs fixing, bugs fixing === What's about to land that might impact the other teams and release as a whole? === * There is still a Libreoffice update with appmenu fixes to land * Some webapp fixes should still land as well === Summary of bugs working on by team (reasonably reliable) === * quantal milestoned bugs === Dependencies on other teams to make deliverables, blocking items, release wide concerns? === * Seems the recent nvidia update broke unity launcher reveal (lp: #1057000) -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [Lubuntu] Release Meeting 2012-10-05
Le 05/10/2012 14:13, Julien Lavergne a écrit : * Some artwork problems remains with the versions of unico and / or gtk3 in quantal (black borders on various widgets, active control ignoring the X ...). If we can have some help, at least to know which change we need to do on our theme, that would help us. See bug 1043129 for detail and discussion. Hey Julien, I'm not sure it's the same issue but it seems a bit similar to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1059374 If somebody having the upstream could test the gtk git commit that would be useful (I would give the link to it but git.gnome.org seems down) Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [PS] Release meeting 2012-09-28
Le 28/09/2012 13:58, Alan Pope a écrit : - New compiz version tarball released - 0.9.8.4 Hey, When do you expect it to be ready for quantal ? The initial schedule was to land it this week but it's friday mid-afternoon and there is an ABI transition so that seems unlikely at this point... Btw what is the reason for the delay? The tarball went out on time and it seems things go stalled in your team for the packaging, is there anything you guys need help on? Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[Desktop] Release Meeting 2012-09-28
=== What was done engineering wise? === * Made printing via AirPrint from iOS6 work * Webapps finally landed in the image * GNOME 3.6 updates * Debugging Evolution's loading of webkit plugins * Unity 6.6 stack update, with compiz, nux, unity, libunity, lenses and the new shopping lenses. * The X stack is fully up to date (see the package status report) and nearly complete for this release. We still await release of the final mesa 9.0, and may pull in a few minor updates (e.g. -nvidia 304.51). * -nvidia experimental drivers have landed in quantal. SRU of these to precise is in progress. * Rebuilding my Xorg q-backports stack * Working on upstream dma-buf synchronization patches === What's about to land that might impact the other teams and release as a whole? === * bug 1005682 FFE Update webkit to 1.9.91 * bug 1054746 [FFe] [UIFe] No easy way to disable online results in lenses * bug 1056718 [UIFe] Add legal notice buttons to UI * compiz bug fix update, followed by another unity update === Summary of bugs working on by team (reasonably reliable) === bug 1040839Thunderbird hangs accessing eds on startup bug 1041104apport hook error: TypeError: 'in ' requires string as left operand, not bytes bug 1041032An error occurred Location not found after automatically installing the missing gstreamer plugins. bug 1029333 rhythmbox crashed with SIGSEGV in monitor_entry_file() bug 1052754apport-gtk crashed with AttributeError in _filter_tag_names(): 'int' object has no attribute 'isspace' bug 1053257 unity-lens-photos crashed with ImportError in /usr/lib/unity-lens-photos/flickr_scope.py: No module named oauthlib.oauth1 bug 1040839Thunderbird hangs accessing eds on startup bug 1041104apport hook error: TypeError: 'in ' requires string as left operand, not bytes === Dependencies on other teams to make deliverables, blocking items, release wide concerns? === * foundation's XDG_RUNTIME_DIR support still didn't land (in NEW with a ffe though) -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Desktop updates to consider for beta1?
Le 02/09/2012 04:37, Micah Gersten a écrit : The new libreoffice failed on i386. Thanks, launchpad does notify about those and emailed about that as well... (no need to directly copy me btw, you can just reply to the list, thunderbird has a button for that) Thanks Adam for fixing the typo from Bjoern, as he put it in an email he sent me on saturday: typical 3am fix error Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Desktop updates to consider for beta1?
Hey release team, Here is a status update from desktop: * we finally landed the unity stack, sorry for the delay and thanks for accepting it, it looks like the stack can be copied to quantal (from proposed) at this point (I prefer to let the release team to do it so I'm not sure what the copy rules are during the freeze) * we would appreciate if those upates could be considered as well for beta1: - indicator-session: it has some UI tweaks and we would like feedback early on that (bugs linked in the changelog are UIFe ones) - indicator-messages: it should be a no-op compared to what we have for most user but it adds some extra api that are needed for the webapp integration work going on, as well as documentation which should help the porting of the client apps - system-coonfig-printer: it includes some fixes * the libreoffice update from yesterday failed to build on amd64, we uploaded a fixed version, Bjoern described the issue we had with testing in the changelog (basically we need to mangle the build on ppas due to disk use limitation in place on those builders), the new version got tested locally by Bjoern and we are confident it fixes the problem from the previous version Thanks for considering those, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [Foundations] Release Meeting 2012-08-29
Le 31/08/2012 12:43, Oliver Grawert a écrit : * XDG_RUNTIME_DIR spec to be done the coming week Does it mean it will be in beta1 or miss it? We really wanted to test the XDG_RUNTIME_DIR codepaths in desktop components for beta1 since beta2 would be late to start getting feedback on that... Chers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [Desktop] Release Meeting 2012-08-31
Reply to myself, we had a pending action: ask TheMuso https://wiki.ubuntu.com/TheMuso to put together a list of tests worth focusing on for accessibility I didn't get a reply from Luke but here as the basic things to test: - boot the liveCD, enable screen reader, check that it's working in GTK3 applications (ubiquity, rhythmbox, gedit, shotwell, ...) - install, reboot, log into the session, check those are still working - watch for any performance or stability bug that lead to errors in a11y components I don't have really specific items and I'm still trying to get details from luck but the key points are to check out the fact that accessibility is indeed working and to watch for issues that might be created by it being one (like errors.ubuntu.com issues pointed to at-spi or atk components) Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Disabling whoopsie by default in the 12.04.1 release
Le 20/08/2012 11:19, Evan Dandrea a écrit : We did ultimately decide to keep error reporting on for 12.04.1, as the average number of errors per week met the requirement set forth by the desktop team: Hi, For the record I think that number is buggy (and I raised that concerns during laste week discussions), it seems artificially low and we identified several issues in the system without explaining all of them nor their impact (the 90% drop which happened for lot of bugs on 17/05/12 being one, the fact that bugs that fail retracing are not showing up on the lists, the fact that the first weeks stats seem much higher and that's the ones which give the first impression for users so that should be the number to consider for the choice, etc). I'm not happy about the decision and how it was taken (in retrospect I wish I had brought the topic in front of the TB rather to have a what is best for Ubuntu project's discussion), let's move on but I don't consider the met the requirement set forth by the desktop team true so let's refrain from making it look like the desktop team agreed on or supports the decision. Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Disabling whoopsie by default in the 12.04.1 release
Le 20/08/2012 12:26, Evan Dandrea a écrit : Apologies. It was not my intention to imply you accepted the decision, just that your team picked a number you would be happy with, and we came up with data that indicated we were below that. Right, we picked a 3 dialogs showing up in a week as a max rate, the number you guys came up with is under that but: - you took the number on a 90 days period I think, knowing that most of the common issues would be stopped after 3 reports by apport. It's likely that the number of the first weeks of use is much higher than the one you came with and it's the one make the first impression (if people give up after a week because Ubuntu is too buggy we just lost them even if the annoyance would have gone down over time) - we still didn't explain that 90% drop showing in a lot of the reports' curves - the 0.4 report/week/user just doesn't match real life experience, nautilus and some other services generate a report every second logout, that alone should put us over that number if you consider users restart their computer once a day, and we didn't start counting any of the real issues... Well anyway, as said let's move on, but I still think we took a non-decision to keep things the way they are based on approximative datas Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [Desktop] Release Meeting 2012-08-17
(Replying to myself to add a comment) I will not be around for the meeting today but Ken accepted to be there in case there are desktop questions, I will also read the log and reply to questions on the list if there is any there Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Disabling whoopsie by default in the 12.04.1 release
Le 13/08/2012 17:20, Evan Dandrea a écrit : In the most common problems table: - If a linked bug report is marked as completed, the entire row will be greyed out (but still clickable). - If there is no linked bug report or the linked bug report is not marked as completed, but the version in Last seen column is *not* the most recent, just the Last seen column will be greyed out. This implies that because we have not seen a newer version with the problem, it is no longer present. - If the linked bug is marked as completed, but the Last seen column contains the most recent published version of the package, the Last seen column will be marked red. This is to indicate a *possible* regression. I'm still playing with this. Because Invalid bugs are also interpreted as complete, and because we only consider a bug complete when all of its bug tasks are complete, this is currently wrong in a few places. I was more interested in seeing how it presented, however. Hey Evan, Those are excellent news, the improvements make a real difference to the side usability, we finally can easily sort out what issues on the main page got addressed and those that still need work! Thanks, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Disabling whoopsie by default in the 12.04.1 release
Le 13/08/2012 17:20, Evan Dandrea a écrit : - If the linked bug is marked as completed, but the Last seen column contains the most recent published version of the package, the Last seen column will be marked red. This is to indicate a *possible* regression. I'm still playing with this. Because Invalid bugs are also interpreted as complete, and because we only consider a bug complete when all of its bug tasks are complete, this is currently wrong in a few places. I was more interested in seeing how it presented, however. There seems to be a bug in that code, takes sessioninstaller: https://launchpad.net/bugs/848605 - the issue got fixed in 0.20+bzr128-0ubuntu1.1 - precise-updates has that version, same for quantal - the last seen column has 0.20+bzr128-0ubuntu1, the detailled report page confirms that but it's marked in red? Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Disabling whoopsie by default in the 12.04.1 release
Le 07/08/2012 08:14, Steve Langasek a écrit : because the information available remains rather incomplete. I have not heard the same feedback that you have about precise being buggy, and I'm not sure that's actually representative of users' experience Hey again, I just crossed that online I figured I would point it as one of the examples I was making reference to: http://www.techdrivein.com/2012/08/how-to-disable-system-program-problem.html Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Disabling whoopsie by default in the 12.04.1 release
of that information. I don't see a good reason we would made the same argument for 12.10, I'm mostly pushing there because: - the system is young and still has flaws, those are being addressed and should lees in an issue by 12.10 time - it's an LTS and perception matters especially for those I would push for not turning it off from 12.10 because I agree it's good to have the system running and from there I think the benefits will be greater than the cost In practice, are the dialogs shown on login after shutdown the main problem? If so, there might be a way to mitigate this particular problem without hobbling whoopsie entirely. I don't know if they are the main problem, they are a source of annoyance and user spamming for sure though (and yeah, stopping those would be nice) Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Reducing dialogues rate (was: Re: Disabling whoopsie by default in the 12.04.1 release)
Le 07/08/2012 08:40, Steve Langasek a écrit : that data that aren't giving users a bad impression (if indeed that's what's happening). For instance, what if we were to only pop up the whoopsie prompt for every fifth crash on a user's system on a stable release? The per-user dialogue rate would be slashed by 80% (er, except for the fact that That would be good to reduce the spamming but it would also breaks what Evan and Matthew consider one of the main features, telling users about problem when they happen and gives an easy way to restart the applications when it closed. We could maybe do something like that on session start though? If you log in and 5 reports are waiting on the disk we should probably not have 5 dialogs displaying in sequence... Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Disabling whoopsie by default in the 12.04.1 release
Le 06/08/2012 13:04, Matthew Paul Thomas a écrit : - - It makes relaunching a crashed application much easier. Right, most of the issues we get are with services and not applications though - - From the next errors.ubuntu.com rollout, it will let release managers and other contributors see whether Ubuntu Q is more reliable than 12.04. I never suggested turning of whoopsie in Q, so we will get metrics in Q in any case. We have metrics from precise at release time and .1 time, that should be good enough to know where Q stands. I don't think lacking a metrics on 12.04.1 post .1 compared to Q is a big deal, the LTS shouldn't change much, we want to know where Q stands though and we will know since we will keep the system running for it. With previous versions of Ubuntu, windows would disappear or features would stop working, and people wouldn't know why. The only difference is that now the failure comes with an explanation. It would be best if the failure didn't occur at all, but if it does, it's better for it to be explained than to be mysterious. That's again assuming that the errors we received are real bugs having an user visible impact, it's true in some cases but I would challenge that being the most frequent case, we have been looking at those errors for 3 months and most of them are bugs reported against services, or happening at session closing, or harmless exception uncaught in python programs. Turning off error reporting would leave the release team ignorant about whether 12.10 is an improvement on 12.04. But this is not a release-team-specific question. It would make Ubuntu developers in general less productive, and it would make Ubuntu worse for end users. The suggestion is to turn if off for 12.04.1, can you explain how it prevents us to get metrics on 12.10? If you think there are ways the end-user presentation can be improved, I'm happy to take suggestions. Routing around that by asking the release team to disable it altogether is not cool. Evan said that work was ongoing on batching reports to submit several together, that will be good. I don't think there is magical ways around it otherwise, it's just that 10 bugs a week is too much errors dialog popping up. The main concern is that only a small fraction of those are user visible issue. To take an example a non marginal number of issues happen on session closing, they are due to the fact that our desktop session management is not really good. That's a known issue, will not be fixed in the LTS (the scope of the work is not appropriate for stable updates), and is harmless ... still it means lot of users get a system error happened dialog first thing after next login. That has a real cost in user perception, the benefit we get back is null though ... Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Disabling whoopsie by default in the 12.04.1 release
Le 06/08/2012 15:20, Matthew Paul Thomas a écrit : That isn't true, unless today is a freak exception. Right now, out of the 50 most common errors, only 17 are from services. The rest are from applications. Right, but if you look at e.g jockey issues some are in the backend side of the software, anyway let's not argue over numbers, my gut feeling from dealing with those bugs since precise is that about half of the issues deserve telling the user, the other half are harmless, session closing bugs, etc. If you take a 50%-50% ratio for the sake of the argument with 10 bugs a week you can consider that we spam users 5 times a week for no good reason or that we avoid confusion 5 times a week for them, matter of perspective. We didn't get so many complain in the past about the confusion created by the bugs (but maybe they just didn't reach us) but we do get quite some for the error dialogs... I think that is mistaken in three ways. Most importantly, Ubuntu 12.04.1 does not mark the end of updates to 12.04. There will be more SRUs. Hopefully some of those will make 12.04 more reliable. If we're unlucky, others may make it less reliable. If the latter happens, how will you know? The same way we did until precise, sure it's less ideal but as said it's a cost-benefit ratio and if we don't invest significant resources into actively fixing stable I don't see it moving enough for the datas to provide a benefit over what they cost us. Second, the kind of people who install 12.04.1 (or buy a computer with it installed) may have noticably different behavior from the kind of people who installed 12.04 -- using different applications and features, and encountering errors at different rates. Right, again what's the point to know about issues and bother users if we do nothing about them because we don't have resources allocated to deal with them? And third, there may be time-based problems that people using 12.04 can't have encountered yet (unless their clock was set wrong). Right, it's not optimal, but we didn't have that system until precise and we somewhat managed to do fine, I'm sure we could deal without it for another release. I didn't say it prevents you from getting error reports from 12.10. I said it prevents you from seeing whether 12.10 is better or worse than 12.04. By 12.04 I include 12.04.1 and any later updates. I don't think we need exact numbers to compare 12.10 to 12.04.1+, we know about the current state of 12.04.1 and the release team should set a goal, e.g the medium submission rate should be lower than 1.3 for quantal. While we are doing time based released anyway those goals will need to be hard ones, we can't block on all parameter you need a variable to adjust, either let slip on goals or on time... The main concern is that only a small fraction of those are user visible issue. How do you know? I've been watching errors.ubuntu.com since precise release, dispatching a good number of the top issues and following up with assigned people, we have a good understanding of most of the bugs we fixed, when they happen and what's the impact. If they are harmless, why do they need fixing at all? If they really don't, that error message in particular could be suppressed. They don't, that's my point, we shouldn't bother users about those, but our system is not smart enough at the moment to tell them apport from important issues. Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Disabling whoopsie by default in the 12.04.1 release
will get there, but we need to: - spend more time improving our stability - stop having so many virtually unmaintained pieces of softwares in our default desktop - improve the system so we don't trigger errors report when not needed (the session closing ones showing up on next login for example) Until we get there I think we should try to not annoy users too mich. The users who are talking to you about it. I suspect these are fairly technical people who do not need an explanation about what just happened when an application disappears - feel free to refute that though. My understanding is that our target market is general consumers though. No, they are normal non technical users who get 5 prompts on login while they didn't start doing anything and when they box is working normally and in a clean state because we collect i.e random shutdown issues and are showing them those after next book. If we completely locked precise down and didn't allow any further changes after the .1 release, I'd be happy to reconsider my position. But we're not. And letting people continue to upload new versions of packages while disabling crash reporting strikes me as reckless. We have been doing that since Ubuntu exists, sure it's not perfect but it has never been so much of an issue, I doubt doing one extra release the way we worked for 8 years would mean the end of the world. Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Changes to the SRU processes?
Le 03/08/2012 22:25, Brian Murray a écrit : As a member of the SRU team I'd like to be involved in the process of watching for regressions in packages from -proposed and having these indicated in the report and process we use would make that easy. Using another tag like verification-potential-regression would require one more search for people to perform. Additionally, I think this tag is one for which the bug count would continue to grow. You shouldn't have to do another query, the SRU report should know about those tag. Using the failed tag for potential issues due to the updates makes you confuse confirmed regressions with potential ones which might be normal bugs, it means there is a chance you overlook a real regression because it's mixed with the noise of new bugs reported by an user running proposed which could be a regression Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[Desktop] Release Meeting 2012-08-03
=== What was done engineering wise? === * Packaged up CUPS 1.6.0 and cups-filters 1.0.20 for Debian and Ubuntu * Pulseaudio 2.1 testing, got some volume behavior weirdness which needs investigating, yet to test on ARM, thats for this week. * Hit some snags with python 3 and BrlTTY, still working through those to get things working again with Orca. * Quite some updates, desktop and other components * Several team members participed to GUADEC and had a productive week there * ubuntu-online-accounts,webapp stack is being uploaded *Updated all xorg-server and all xorg video drivers to prepare for x-1.13 release * Submitted nouveau patches to support vblank * Continued work on cleaning up dma-fences/dmabufmgr * libreoffice 3.6.0rc4 === What's about to land that might impact the other teams and release as a whole? === * xserver 1.13rc2 stack === Summary of bugs working on by team (reasonably reliable) === * No specific list yet for quantal === Dependencies on other teams to make deliverables, blocking items, release wide concerns? === * None -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Disabling whoopsie by default in the 12.04.1 release
Hey, That's something quite some people raised as an issue since precise, the frequent whoopsie dialogs in the LTS gives users the feeling that precise is unstable (it seems often qualified to buggier over previous release for no reason out of the number of error dialogs showing up to report bugs). I've discussed the issue with different people in different teams, here is my try to a summary of the pro and con: Pro: - it gives us infos on what issues users run into - it gives feedback to users on what happen when a program close while they are using it Con: - it's showing up too often and giving the impression to users that the system is buggy - it's often showing programming errors which don't impact users (untracked exception from python softwares or services by example), what users get the most notified about is glitchs about things like ubuntuone services, oneconf, software-center ... most of those are not user visible issues and the frontend would handle the glitches fine without whoopsie notifying the users - errors.ubuntu.com is not good enough yet that we can properly tackle those issues - we don't have the resources to get where we want to be in a short timeframe, we are working on it but meanwhile we are impacting users for things we don't make real use for I know that most of the cons are addressable but until we do address them the consensus form the people I talked to seems to be that the cost-benefit is largely not in our favour at this point so I would recommend we do disable it by default for 12.04.1 to minimize LTS annoyance and keep it enable from now on for new release (on the basis that the system will improve enough that we can catch up and that the perception issues is a bit less of an issue on a non LTS) Just to give some details about the errors.ubuntu.com issues mentioned before (I think people are going to ask what are the problems at some point so I can as well reply to that here): - it's not possible to filter out issues which have been resolved from the list (so it's hard to know what has been worked on and what needs work still) - it's not possible to say what issue happens to what version and get stats of instances of the bugs by version, i.e to get datas on whether the situation improved or not for a bug - some of our engineers have issues login into the system to get access to the infos they need to work on the bugs, that situation is still not resolved after some months - other small issues, but I don't want to turn that email into a list what is wrong currently, especially when we have people knowing about those and working on improving the situation I would add that Evan did an amazing job so far and that errors.ubuntu.com has been proved very useful already (we fixed at least an hundred bugs, most wouldn't have show up in this way using launchpad) so the email is not again that work, we just feel that the current status of the system and the resources allocated to fixing those bugs gives us a situation where the benefit is not sufficient to justify the cost on the Ubuntu image. What do people think about turning whoopsie off for 12.04.1? Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[Desktop] Release Meeting 2012-07-27
=== What was done engineering wise? === * Started work on a patch to NM to update dnsmasq via DBus rather than respawning it on every DNS server changes * Polished some of the session-migration work * Worked on the jockey killer (software-center properties integration of devices installation) * LibreOffice 3.6.0~rc2 released to quantal -- one month earlier than our first release a year ago on oneiric * Ported BrlTTY python bindings to cython (practically no work required other than autotools changes). THis gives us a launchpad to ship python 3 bindings for BrlTTY, whichi Orca can use. * Tracked down some bugs related to netboot d-i installation on pandaboards, however not all bugs have been ironed out yet. All of this is a result of me trying to set up quantal on a pandaboard using an external USB drive. * Unity/Compiz/Compiz-plugins-main SRU tested and uploaded in precise. Will like be the 12.04.1 version * Work with PS on the compiz gsettings migration. Got a migration script ready to migrate most important values from gconf to gsettings. * Work on gnome-control-center to support the new values now in gsettings in both display and background panels. * Start a discussion of what's still needed to do and blocking the gsettings compiz upload === What's about to land that might impact the other teams and release as a whole? === * compiz on gsettings (still...) === Summary of bugs working on by team (reasonably reliable) === * No specific list yet for quantal === Dependencies on other teams to make deliverables, blocking items, release wide concerns? === * Libreoffice still having issues with gcc c11 abi changes in quantal -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[Desktop] Release Meeting 2012-07-20
=== What was done engineering wise? === * Landed session-migration tool to quantal * Coordination with the community team around making a Quickly reboot * Help the ARB with reviews for the contest * Landed software-properties with drivers support (deprecates jockey-gtk) * New NetworkManager snapshot with 0.9.5.95 (IPv6 stability fixes, IPv6 for VPN, Vala bindings, etc.) * LibreOffice 3.6.0 rc uploaded to quantal * lo-menubar contractor work started * GNOME updates * GNOME accessibility stack updates for GNOME 3.5.4 * Discussion with unity devs about accessibility, and the right way to get it fully implemented. * Commense unity panel accessibility code refactor * Got a small unity-lens fix and SRU last week * Preparation of a compiz gsettings release, unity and compiz SRU * Started preparing parts of x1.13 server * SRU updates for xorg and other desktop components * work on lightdm,system compositor continued === What's about to land that might impact the other teams and release as a whole? === * compiz on gsettings (still...) === Summary of bugs working on by team (reasonably reliable) === * No specific list yet for quantal === Dependencies on other teams to make deliverables, blocking items, release wide concerns? === * None -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Changes to the SRU processes?
Le 17/07/2012 21:59, Stéphane Graber a écrit : Can't we have a bot spotting new bugs matching the version in -proposed and marking verification-failed the master bug in such case (or any bug linked to the SRU, so that it's blocked)? While an improvement that wouldn't have caught the recent issue with xorg-server which was reported against gimp (the issue was xorg segfaults when using gimp) before being reassigned to xorg ... not sure how we can be smart enough to catch those though out of listing all the bugs reported on ,reassigned to the said source and having somebody reviewing the list before SRU copy. -- Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Changes to the SRU processes?
Le 17/07/2012 22:09, Scott Kitterman a écrit : This sounds to me like something that could have caught the recent problems, so +1 from me. Double +1 since it's a solution that doesn't result in more random bug mail for me. One issue with those is the number of false positives, that's not because a bug is opened by a proposed user that it's a regression, it's likely that proposed users will as any user report issues when they hit them and that most are not specific to the SRU they are running... -- Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[Desktop] Release Meeting 2012-07-13
=== What was done engineering wise? === * new libusb-based USB CUPS backend * Improved Plug'n'Print UDEV facility of system-config-printer * First printer driver packages using new libjbig are available now: foo2zjs, splix, c2esp * Got some quickly/python-distutils-extra fixes and support for the arb team during the app developer week * Work in progress on new gnome-settings-daemon and gnome-control-center * Continued work on the UI design for Additional Drivers in software-properties * Fixed chromium-browser (18.x) FTBFS in quantal * Worked on updating chromium-browser to latest in the stable channel, 20.x * Libreoffice 3.6 is getting ready for upload in quantal * Get a branch ready for merging into Unity, so that Unity uses libatk-bridge. * First round of indicators updates in quantal, including new session indicator * First round of unity 6 serie updates in quantal, not so many user visible changes but lot of bug fixing and foundation work * Working prototype of system compositor + intel driver * Experimental lightdm,system compositor work ready to test, see https://lists.ubuntu.com/archives/ubuntu-desktop/2012-July/003890.html === What's about to land that might impact the other teams and release as a whole? === * compiz on gsettings === Summary of bugs working on by team (reasonably reliable) === * No specific list yet for quantal === Dependencies on other teams to make deliverables, blocking items, release wide concerns? === * None -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Work items tracking
Le 10/07/2012 16:18, Kate Stewart a écrit : Hey Skaet, Thanks for the reply. the work items are only tracked for those that are part of an existing team in launchpad that the tracker knows about. if he's not a member of one of the teams in: http://status.ubuntu.com/ubuntu-quantal/teams.html his work items aren't individually tracked. Oh, that makes sense, thanks! There's a team where he can be added to, ubuntu-community-contributors, so that tracking can start. Ask him to ping me if he wants to be added, and I'll help sort it, and anyone else that falls into this catch all. Thanks, I will ping you off list if I get some such cases. Load balancing should be done before features are milestones/prioritized and approved by team management. Right, sorry I think I overlooked it, I though for one moment that a workitem assigned to a desktoper on a foundation blueprint wouldn't reflect on the desktop team chart so we wouldn't see how much debt we have to other teams on how we are progressing on those. Yes, milestones and priority of the blueprint should be standard practice to make sure are set on blueprints before they are approved. The fields are there, we should be using them to help us manage the release. :) In terms of using the milestones, spreading the work out and managing expectations about when features are landing, is what the other teams are doing, and is good engineering practice to avoid problems at the system level across teams. (for dependencies and expectation setting). Well, the way we have been doing (or at least I, but maybe I overlooked something pitti was doing before) is to use the Series goal to see the serie and only set the milestone if the spec was due before the end of the cycle (i.e for an alpha or beta), I will go and fix the desktop blueprints. Looking to foundation they seem to have it set for most specs but lack some as well, I spotted those if somebody wants to fix them: https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-roadmap https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-stateful-re-exec https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-autocreate-preseed https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-xdg-runtime-dir If someone with launchpad skills wants to volunteer to do the work, we can look at making it default to beta-1 for all blueprints not explicitly assigned to a milestone in the series (closest point to feature freeze), since most blueprints are for features, rather than the end of the release. Any volunteers? ;) That would be good ;-) Thanks, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[Desktop] Release Meeting 2012-07-06
=== What was done engineering wise? === * Wrote some integration tests for different desktop components * Improved libusb-based USB CUPS backend a lot * A Software Updater redesign landed and the release upgrader was moved to its own package * Desktop SRUs for precise * Accessibility work unity and unity-panel-service * Unity 6.0 and Nux 3.0 release preparation (with the lenses transition). * New firefox,thunderbird beta version * Work on libreoffice 3.6 beta continued * Compiz on gsettings is getting ready * Uploaded x1.12 into ubuntu-x-swat/q-lts-backport * Working with debian on making libdrm_nouveau new and old abi parallel installable using f17's patch * Working upstream on dma-buf synchronisation problem * lightdm,system compositor work is ongoing * some GNOME updates * software-properties port to python3 got uploaded === What's about to land that might impact the other teams and release as a whole? === * there should be an upload of the new unity serie soon in quantal but it shouldn't create any problem * compiz on gsettings should be uploaded which will unblock some gnome-control-center, gnome-settings-daemon work, should really have an impact either though but still worth mentioning ;-) === Summary of bugs working on by team (reasonably reliable) === * No specific list yet for quantal === Dependencies on other teams to make deliverables, blocking items, release wide concerns? === * None -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Is there any progress on the stl abi issues? (was: Re: [Desktop] Release Meeting 2012-06-29)
Le 28/06/2012 21:55, Sebastien Bacher a écrit : * the gcc 4.7,libsigc,stl issues are still not fixed yet (unity is build with gcc-4.6 still) I've been mentioning that for a few weeks but I've seen no recent update, is anyone working on it? Bjoern just raised the issue in the desktop team, those issues are blocking libreoffice work in quantal for some weeks and we would like to know if we need to invest efforts in building libreoffice with gcc-4.6. Thanks, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Is there any progress on the stl abi issues?
Le 29/06/2012 20:29, Steve Langasek a écrit : In the meantime, yes, any packages that are being built with -std=c++0x or -std=c++11 should use gcc-4.6 instead. Thanks! Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[Desktop] Release Meeting 2012-06-29
=== What was done engineering wise? === * libreoffice 3.6.0 beta2 pre-released in a ppa for precise and quantal * work on ubuntu drivers (jockey replacement) continued, including port to python3 (waiting for review) * gtk got updated, included new a11y libraries and accessibility on by default * xserver 1.12 got uploaded * compiz one tree version (i.e all the components merged in one source) got upload * work is on progress on orca-python3 * GNOME 3.5 updates * update-manager work continued, included reviews and some of changes landing to trunk (should make their way to distro soon) * new firefox beta version in quantal including some fixes to our customization changes === What's about to land that might impact the other teams and release as a whole? === * the new gtk has a11y enabled by default, check for issues it might create and let us know if there is any === Summary of bugs working on by team (reasonably reliable) === * No specific list yet for quantal === Dependencies on other teams to make deliverables, blocking items, release wide concerns? === * the gcc 4.7,libsigc,stl issues are still not fixed yet (unity is build with gcc-4.6 still) -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [Desktop] Release Meeting 2012-06-15
Le 15/06/2012 15:49, Kate Stewart a écrit : * The next SRU round for the unity stack is being prepared Any feel for when this might be landing? It's scheduled for next week What about the next update to unity for quantal? The gcc,libsigc issue I mentioned bellow in the blocking items section will need to be resolved before we can update unity in quantal. The next upload will probably still be a bug fix one (i.e the equivalent of the precise SRU), the unity team didn't show signs to be close to land feature work for quantal yet... Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: [Desktop] Release Meeting 2012-06-15
Le 15/06/2012 12:17, Sebastien Bacher a écrit : * GTK 3.5 is ready for upload (will likely be uploaded on monday) Note that a few packages build-depending on 3.5 (gnome-online-account, nautilus) got uploaded today, gtk was meant to be uploaded as well but that didn't happen and it took us a bit to figure out that it was missing. To be safe on a friday afternoon, at this point, we prefer to keep those packages in depwait during the w.e and upload the new gtk on monday. Is there any concern from the release team about those packages staying in depwait state for some days? Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[Desktop] Release Meeting 2012-06-08
=== What was done engineering wise? === * firefox and thunderbird 13 have been updated for all supported ubuntu series, work started for the next versions in quantal * Libreoffice 3.6.0-beta1 is getting ready for quantal (in a ppa for the moment) * Update Manager got a slightly new look, more to come in the future * GNOME 3.5 updates in quantal * The team continued on merges and python3 porting * The system compositor work is seeing some good progresses * Unity build issues on quantal are being investigate (the build issue have fixes available but unity,nux segfaults when building with the new gcc, that's being investigated) * Some SRUs for precise === What's about to land that might impact the other teams and release as a whole? === * GTK 3.5 should be uploaded to quantal soon (blocked on the themes (unico) to be updated to work with it), out of the fact that it's a new GTK serie there is no known issue though === Summary of bugs working on by team (reasonably reliable) === * No specific list yet for quantal === Dependencies on other teams to make deliverables, blocking items, release wide concerns? === * The libreoffice 3.5.4 SRU for precise is ready for a week but blocked on SRU team - TB discussions (the SRU team says that such updates don't qualify for SRU without a MRE and the MRE request which has been sent to the TB didn't really see lot of action yet) ... not sure how to unblock the situation but the update fixes several important bugs including data lost ones so it would be nice to get out to precise users. -- 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 -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: SRUs and the development release
Le 03/06/2012 16:03, Iain Lane a écrit : https://launchpad.net/ubuntu/+source/unity/5.12-0ubuntu2 It's not clear to me what we can do about people not test-building their uploads, Speaking about the unity example, it got built tested and run tested but by people still on precise (the priority was to get the SRU out to the lts users) but could the SRU team make it clear that just uploading to the development release is not enough — the fixes have to *work* there too? I don't think there is a communication issue on that point, nobody is making the fix not work on purpose... It's a small amount of extra work to additionally check the build status, but hopefully it'll pay off in a more solid dev release, which is a meme we've been trying to establish, after all. Checking the build status is not the issue there, the issue has been noticed when launchpad tried the build and sent ftbfs issue and upstream unity has been pinged about it, the resolution is just taking some time because that make it run into several level of issues (need to transition to new versions or lib, need to fix errors with the new toolchains, and now need to figure a segfault issue). Ideally builds would be tested on a q build system before upload, while that's not hard work it's also not a small amount of extra work if you are running still the stable serie (it's easy enough to set a pbuilder or so but it's still work and I'm not sure we should force people who contribute a SRU fix to go through that) The other option there would have been to block the LTS SRU on getting those issues resolved and we wanted to see some of the bugs fixed and sooner that later so I'm unsure delaying the SRU was the right way either... -- Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[Desktop] Release Meeting 2012-06-01
=== What was done engineering wise? === * Specs writing is done * Continued on SRUs for precise * Good progresses on the third party drivers installation spec * New firefox (13) and thunderbird are ready for the coming release * Got firefox to build with the quantal toolchain * Libreoffice 3.5.4 SRU is ready for upload * Work on xorg for lts point release updates continued * compiz got refactored to be only one source rather than five, the packaging got updated and the new version is finally building === What's about to land that might impact the other teams and release as a whole? === * Nothing specific === Summary of bugs working on by team (reasonably reliable) === * No specific list yet for quantal === Dependencies on other teams to make deliverables, blocking items, release wide concerns? === * Nothing to report -- 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
Re: [QA] Release Meeting 2012-06-01
Le 01/06/2012 11:22, Jean-Baptiste Lallement a écrit : Boot speed for Quantal: http://reports.qa.ubuntu.com/reports/boot-speed/ Hey, That page has boot times for precise alpha1 and alpha2 but not for any later milestone, could we get the 12.04 stable times as a reference as well? -- Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
[Desktop]-team Release Meeting 2012-05-25
=== What was done engineering wise? === * Catchup after UDS * Specs writing * Started quantal work, merges, some updates * Some SRUs for precise === What's about to land that might impact the other teams and release as a whole? === * Nothing specific out of the churns coming with Debian syncs and merges at the start of the cycle. Some GNOME updates are planned but they shouldn't impact much on others === Summary of bugs working on by team (reasonably reliable) === * No specific list yet for quantal === Dependencies on other teams to make deliverables, blocking items, release wide concerns? === * Nothing to report -- 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
[Desktop] Status 2012-02-10
== What was done engineering wise? == * New GTK changed the theme API slightly, the themes got updated but there are still a few issues to resolve. * Land music store for Rhythmbox. * accountsservice now writes user locale configuration to `~/.pam_environment` instead of `~/.profile`, to avoid having to touch an actual shell script, and `~/.profile` to overwrite the PAM environment settings. * FreeRDP 1.0 hit precise. It's undergoing the final tweaks to pass our security review. Once it's in main, we'll update remmina and put it into main (MIR already approved), dropping the old and rather insecure rdesktop/vinagre. * Land new ALSA. Introduced a regression which was fixed quickly, should be good now. * Update to the latest pieces of the GNOME a11y stack in precise. Land network-manager, Unity launcher, and some other a11y fixes. * Add WhatProvides plugin support to PackageKit and aptdaemon, and add plugin for language support packages to language-selector. This allows upstream control-center's region panel to work on Ubuntu. * Lots of language-selector code cleanup and bug fixing. * XRandR library development progressing well. * Went over remaining precise work items, and moved a few blueprints to the Q cycle which will not make it. == What's about to land that might impact the other teams? == * New compiz will be uploaded RSN (Didier has a first version being tested in his ppa) . It shouldn't directly affect other teams, but if you notice window manager regressions, please tell us. == Dependencies on other teams, blocking items == None. == New Desktop Release Notes == Nothing new this week. Cumulative notes at https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus#relnotes == Release targetted bugs being worked on/monitored == Good progress this week, details at https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus#rcbugs -- Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Fwd: New component-mismatches for source universe - main
On ven., 2011-06-10 at 17:14 +0200, Martin Pitt wrote: hey Seb, the recent cheese upload caused some serious component-mismatches trouble: Hi, Yeah, I knew that before uploading but we have work items for some of those and I will extra ones for the others, I figured we would be better having it uploaded so the version is current and we have some motivation to fix the build-depends and depends issue. We might want to discuss if we still want to use it if it brings the clutter stack in Seb -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
