RE: Further reducing my involvement with Ubuntu
I have a feeling that'll happen, but I'll leave that to the Release team. Eithier way, I have a code clone so I can start examining the code (and potentially improving it for my own needs or using it as a base for stuff). Yay for open source software, am I right? đ Thomas -Original Message- From: StĂ©phane Graber Sent: Friday, February 16, 2024 18:25 To: Thomas Ward Cc: Steve Langasek ; ubuntu-release@lists.ubuntu.com Subject: Re: Further reducing my involvement with Ubuntu Yep, My original e-mail included a link to the bzr repo for the code. I suspect that part of moving it to a new home will include converting that to git and writing down more up to date instructions on how to install and run it. StĂ©phane On Fri, Feb 16, 2024 at 6:16âŻPM Thomas Ward wrote: > > The code exists somewhere right? I may want to adapt a version of > this for Lubuntu on our Matrix channels at some point independent of > the AA/Release Team at some point (or for a private equivalent bot to > send me notices on specific packages). Asking because I'd like to do > some extra coding work myself and help maybe improve the bot's code > long term if theres no objection to coding suggestions :) > > > > Sent from my Galaxy > > > > Original message > From: StĂ©phane Graber > Date: 2/16/24 17:55 (GMT-05:00) > To: Steve Langasek , StĂ©phane Graber > , ubuntu-release@lists.ubuntu.com > Subject: Re: Further reducing my involvement with Ubuntu > > Current config minus bot password (reach out on IRC for that): > > ``` > [general] > verbose = false > > [server] > host = irc.libera.chat > port = 6697 > nick = queuebot > local_address = 2602:fc62:a:1::1 > password = PASSWORD > ipv6 = true > ssl = true > > [#ubuntu-release] > queue = New, Unapproved > tracker = Builds > packageset = Packageset > > [#ubuntu-quality] > tracker = Builds > > [#edubuntu] > queue = New, Unapproved > queue_filter = edubuntu > > tracker = Builds > tracker_filter = edubuntu > > packageset = Packageset > packageset_filter = edubuntu > > [#kubuntu-devel] > tracker = Builds > tracker_filter = kubuntu > > packageset = Packageset > packageset_filter = kubuntu > > [#ubuntu-dmb] > packageset = Packageset > > [#ubuntu-ci-eng] > landing = Landings > > [#lubuntu-devel] > tracker = Builds > tracker_filter = lubuntu > > queue = New, Unapproved > queue_filter = lubuntu > > packageset = Packageset > packageset_filter = lubuntu > > [#ubuntu-qt] > queue = New, Unapproved > queue_filter = qt5 > > packageset = Packageset > packageset_filter = qt5 > ``` > > On Fri, Feb 16, 2024 at 3:58âŻPM Steve Langasek > wrote: > > > > On Thu, Feb 15, 2024 at 06:59:00PM -0500, StĂ©phane Graber wrote: > > > Following some recent interactions[1] which have made me question > > > my trust in the Ubuntu Community, I have made the decision to > > > further cut back my involvement with the Ubuntu project. > > > > > In the case of the Ubuntu Release team, this specifically relates > > > to the operation of the IRC bot "queuebot". > > > I've been operating and occasionally tweaking and fixing that IRC > > > bot for over a decade (since 2012) and it's been running on my own > > > infrastructure ever since. > > > > > You'll find the current (rather ugly python) code here: > > > https://code.launchpad.net/~ubuntu-archive/queuebot/queuebot > > > > > I'd like to turn the lights off on my side by the end of March. > > > Should someone want to take over hosting and operating it, please > > > let me know and we'll organize the transfer of the production > > > configuration to minimize the downtime for its users. It's > > > currently running in an Ubuntu 20.04 container and needs around > > > 500MB of RAM to keep track of all the various packages. > > > > Thanks for reaching out, StĂ©phane. I've thought for a while that it > > would be a good idea for us to move hosting of this somewhere at > > Canonical that multiple active members of the Release Team might have > > access to. > > > > I've identified a place we can quickly spin this up that both Brian > > and I (as well as some non Release Team folks) will have admin > > access on. Feel free to dump the production config info. > > > > (If other members of the Release Team care about having access, we > > can also make that happen; I'm just arranging for now to move it > > somewhere expedient / low-overhead.) > > &g
RE: Further reducing my involvement with Ubuntu
The code exists somewhere right? I may want to adapt a version of this for Lubuntu on our Matrix channels at some point independent of the AA/Release Team at some point (or for a private equivalent bot to send me notices on specific packages). Asking because I'd like to do some extra coding work myself and help maybe improve the bot's code long term if theres no objection to coding suggestions :) Sent from my Galaxy Original message From: StĂ©phane Graber Date: 2/16/24 17:55 (GMT-05:00) To: Steve Langasek , StĂ©phane Graber , ubuntu-release@lists.ubuntu.com Subject: Re: Further reducing my involvement with Ubuntu Current config minus bot password (reach out on IRC for that): ``` [general] verbose = false [server] host = irc.libera.chat port = 6697 nick = queuebot local_address = 2602:fc62:a:1::1 password = PASSWORD ipv6 = true ssl = true [#ubuntu-release] queue = New, Unapproved tracker = Builds packageset = Packageset [#ubuntu-quality] tracker = Builds [#edubuntu] queue = New, Unapproved queue_filter = edubuntu tracker = Builds tracker_filter = edubuntu packageset = Packageset packageset_filter = edubuntu [#kubuntu-devel] tracker = Builds tracker_filter = kubuntu packageset = Packageset packageset_filter = kubuntu [#ubuntu-dmb] packageset = Packageset [#ubuntu-ci-eng] landing = Landings [#lubuntu-devel] tracker = Builds tracker_filter = lubuntu queue = New, Unapproved queue_filter = lubuntu packageset = Packageset packageset_filter = lubuntu [#ubuntu-qt] queue = New, Unapproved queue_filter = qt5 packageset = Packageset packageset_filter = qt5 ``` On Fri, Feb 16, 2024 at 3:58âŻPM Steve Langasek wrote: > > On Thu, Feb 15, 2024 at 06:59:00PM -0500, StĂ©phane Graber wrote: > > Following some recent interactions[1] which have made me question my > > trust in the Ubuntu Community, I have made the decision to further cut > > back my involvement with the Ubuntu project. > > > In the case of the Ubuntu Release team, this specifically relates to > > the operation of the IRC bot "queuebot". > > I've been operating and occasionally tweaking and fixing that IRC bot > > for over a decade (since 2012) and it's been running on my own > > infrastructure ever since. > > > You'll find the current (rather ugly python) code here: > > https://code.launchpad.net/~ubuntu-archive/queuebot/queuebot > > > I'd like to turn the lights off on my side by the end of March. Should > > someone want to take over hosting and operating it, please let me know > > and we'll organize the transfer of the production configuration to > > minimize the downtime for its users. It's currently running in an > > Ubuntu 20.04 container and needs around 500MB of RAM to keep track of > > all the various packages. > > Thanks for reaching out, StĂ©phane. I've thought for a while that it would > be a good idea for us to move hosting of this somewhere at Canonical that > multiple active members of the Release Team might have access to. > > I've identified a place we can quickly spin this up that both Brian and I > (as well as some non Release Team folks) will have admin access on. Feel > free to dump the production config info. > > (If other members of the Release Team care about having access, we can also > make that happen; I'm just arranging for now to move it somewhere expedient > / low-overhead.) > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org -- 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: Further reducing my involvement with Ubuntu
Stephane, I can handle operation of the bot if its just in an LXD container then migrating it over should be simple if the Release team does not mind me assisting with running components. Thomas Sent from my Galaxy Original message From: Stéphane Graber Date: 2/15/24 18:59 (GMT-05:00) To: ubuntu-release@lists.ubuntu.com Subject: Further reducing my involvement with Ubuntu Hello, Following some recent interactions[1] which have made me question my trust in the Ubuntu Community, I have made the decision to further cut back my involvement with the Ubuntu project. In the case of the Ubuntu Release team, this specifically relates to the operation of the IRC bot "queuebot". I've been operating and occasionally tweaking and fixing that IRC bot for over a decade (since 2012) and it's been running on my own infrastructure ever since. You'll find the current (rather ugly python) code here: https://code.launchpad.net/~ubuntu-archive/queuebot/queuebot I'd like to turn the lights off on my side by the end of March. Should someone want to take over hosting and operating it, please let me know and we'll organize the transfer of the production configuration to minimize the downtime for its users. It's currently running in an Ubuntu 20.04 container and needs around 500MB of RAM to keep track of all the various packages. If nobody steps in, then I'll just turn it off at the end of March assuming that it's no longer a useful service to the Ubuntu community. Thanks! Stéphane [1] https://hachyderm.io/@stgraber/111936620602456692 -- 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: Lubuntu LTS Requalification: 24.04 Noble Numbat
I was just about to reply with a decision from Team Lead and Council as follows, which sort of affirms what Aaron said (though this DID need to come from leadership, not Aaron): Primary contact: Simon (tsimonq2) Secondary Contact: Dan (kc2bez) Third-tier contact (if Simon and Dan don't reply): Aaron (arraybolt3) For an all else fails contact, you can contact me - Thomas (teward) - as Lubuntu Team Lead, I have executive authority to act if others are unreachable or in cases where it requires executive overrule (see Simon's reference to me dictating the "rest period" for Lubuntu started on Dec 20 instead of Simon's suggestion of Dec 25th through New Year). I'm also always open to pass on escalations if the others are unreachable, Simon and Aaron both know I'm no stranger to dropping bags of work on them when it's necessary. (Note that my Lubuntu duties are independent of my other roles and hats) Thomas (Sorry for not replying in line, Outlook is the only mail client I have right now and it's a pain for replying because it does top-replies). -Original Message- From: Ubuntu-release On Behalf Of Steve Langasek Sent: Thursday, January 18, 2024 12:14 AM To: Aaron Rainbolt Cc: Simon Quigley ; ubuntu-release@lists.ubuntu.com Subject: Re: Lubuntu LTS Requalification: 24.04 Noble Numbat On Wed, Jan 17, 2024 at 10:34:04PM -0600, Aaron Rainbolt wrote: > > One of the points on https://wiki.ubuntu.com/RecognizedFlavors for > > LTS approval is > >Flavor's support plan presented to Tech Board and approved; support plan > >should indicate period of time if beyond 9 months (3 yrs or 5 yr), key > >contacts, and setting expectations as to level of support. > > Who are you identifying as the "contacts" for escalation of any > > issues regarding Lubuntu 24.04 LTS, from the technical board or the release > > team? > Perhaps this got missed, but in the Lubuntu Constitution (our personal > "how things work in our project" policy), this is very well-defined. Well yes, that was not part of the information submitted to the Technical Board as part of the qualification request. It's healthy for a flavor to have such structures in place and also speaks well of the maturity and health of the Lubuntu flavor community; but please don't assume that members of the broader Ubuntu community are conversant with such flavor-specific governance details. > The contacts are Simon, Dan and myself (Aaron), and Thomas, in that order. > Simon therefore is the primary contact as he is the Lubuntu Release > Manager, me and Dan are secondary contacts, and Thomas is the "if all else > fails" > fallback by virtue of him being Team Lead. Thanks. With that clarification, I am +1 for the 3-year Lubuntu 24.04 LTS. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Lubuntu 24.04 LTS Participation/Recertification
All: I wish to apologize for the tardiness of this note, but on behalf of the Lubuntu Council and the Lubuntu Team, I would like to reassert that Lubuntu will be participating in 24.04 LTS with a 3 year support period on our part. Simon Quigley was present at today's TB meeting and made a note that he has a draft written up for the recertification paperwork and messages going to the TB, but I wanted to reassert that we're working on getting it fully filed, but I wanted to affirm we are still participating despite the delay in getting information to the TB and Release teams. I wish to apologize on our slowness, lots of things happened towards EOY 2023 and everyone got very busy, and this was delayed and overlooked, so my apologies to the Release Team and the Technical Board. Thomas Ward LP: ~teward Lubuntu Team Lead Secondary Lubuntu Release Manager Lubuntu Council Member -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Special One-Time SRU Handling request for torbrowser-launcher
Robie, To cherry pick this would require extensive reverse engineering of the code to figure out which pieces apply to the *older* versions of torbrowser-launcher. Unfortunately, since there are no *bugfix* releases of torbrowser-launcher upstream and everything is interspersed among larger-scale feature changes, this prevents us from easily cherrypicking the code. Essentially, to reverse engineer this patch would take much MUCH more time and effort to make functional. However, we have a second consideration point. With torbrowser-launcher 0.3.6, we have a major *upstream* change from Tor Browser itself (which is downloaded by torbrowser-launcher and installs it in userspace as Tor Browser prefers to live in) which involves the loss of all localization packages and one unified package for Tor Browser. To nitpick *those* fixes is equivalent to a large feature change that is well-ingrained in the 0.3.5 -> 0.3.6 codebase change, and reverse engineering that from what I've attempted to do initially for Tor Browser is a nightmare. Which leaves us with, really, two choices:  1. Backport 0.3.6-2 in -updates to the older releases  2. Won't Fix 277 and other bugs which will make the package unusuable (effectively: Critical bugging the older version which a lot of people use, because it's "no longer supported"). This is tantamount to Bitcoin from the history where Bitcoin would make hard forks or major non-reverse-compatible changes that can't be backported and in turn would require the newer version to be backported in order for `bitcoin` to even function. The only difference between Bitcoin and torbrowser-launcher (and Tor Browser) is that this is the first major *historically breaking* change in upstream Tor Browser that prohibits simply 'backporting' these changes. The two-line fix for launch window is minor, and we could theoretically survive that. However, the URL fix is nontrivial to backport within the code, hence the request for a one-time special SRU to backport 0.3.6 to all current releases (except 18.04 because that's approaching it's EoSS date) in order to make everything function in the currently supported releases. Thomas On 4/6/23 15:55, Robie Basak wrote: Hi Thomas, Thank you for caring for this package in Ubuntu! I'm not sure I follow why this is difficult to fix by cherry-picking fixes. It seems to me that there are two bugs mentioned - one which is a two line fix, and one which refers to upstream URLs changing, which presumably is a change in a constant somewhere or similar. Will cherry-picking or rewriting these trivial fixes not be enough to fix the reported bugs? If not, why not? Robie On Sun, Mar 19, 2023 at 07:55:48PM -0400, Thomas Ward wrote: I'm following up on this today, because Debian finally got off their lazy butt and uploaded 0.3.6-2 to Debian that addresses the core problems in Debian. However, that does not solve the problems for everything in Ubuntu. With the blessing of the Release team, I did a sync last night (forced) of 0.3.6-2 from Debian Unstable to Ubuntu Lunar, which addresses https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277 in Lunar. Unfortunately the fix that is applied for this in 0.3.6-2 is interwoven with all the changes from 0.3.3 to 0.3.6 upstream which includes new features. I have not heard back from the Release team on this, or the SRU team, so I'm re-asking this. Is the SRU / Release team willing to let us do a one-time backport from Lunar of 0.3.6-2 to the older releases currently supported (to Bionic but no further backwards)? Thomas On 2/1/23 14:26, Thomas Ward wrote: Hello, release team. Pursuant to a recent change for torbrowser-launcher and Tor Browser, we have a little bit of a conundrum that is leading to a one time request for SRUing the latest `torbrowser-launcher` to all currently supported releases. With Tor Browser 12 (TB12 for short here), upstream tor browser no longer uses locales, requiring folder cleanup from TB12 and download URL changes in order for things to properly function. Unfortunately, the code changes necessary to implement the changes to torbrowser-launcher are not easily nitpicked and include more than just these fixes, as it has new changes and such to make it work properly. Refer to https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277 as the current bug on this. Debian is behind on updating upstream, so later today I will be preparing a package for Lunar that will have a -0ubuntu1 prefix for the latest upstream version. That works fine in Lunar. It also works fine in Kinetic and in initial tests in Jammy. Iâm installing test environments for Focal and Bionic. The problem here is, though, we have a mix of ânew featuresâ and âbug fixesâ together â there is no âmajor version bumpâ for feature branches vs. âbugfixâ branches, making it a comin
Re: Special One-Time SRU Handling request for torbrowser-launcher
I'm following up on this today, because Debian finally got off their lazy butt and uploaded 0.3.6-2 to Debian that addresses the core problems in Debian. However, that does not solve the problems for everything in Ubuntu. With the blessing of the Release team, I did a sync last night (forced) of 0.3.6-2 from Debian Unstable to Ubuntu Lunar, which addresses https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277 in Lunar. Unfortunately the fix that is applied for this in 0.3.6-2 is interwoven with all the changes from 0.3.3 to 0.3.6 upstream which includes new features. I have not heard back from the Release team on this, or the SRU team, so I'm re-asking this. Is the SRU / Release team willing to let us do a one-time backport from Lunar of 0.3.6-2 to the older releases currently supported (to Bionic but no further backwards)? Thomas On 2/1/23 14:26, Thomas Ward wrote: Hello, release team. Pursuant to a recent change for torbrowser-launcher and Tor Browser, we have a little bit of a conundrum that is leading to a one time request for SRUing the latest `torbrowser-launcher` to all currently supported releases. With Tor Browser 12 (TB12 for short here), upstream tor browser no longer uses locales, requiring folder cleanup from TB12 and download URL changes in order for things to properly function. Unfortunately, the code changes necessary to implement the changes to torbrowser-launcher are not easily nitpicked and include more than just these fixes, as it has new changes and such to make it work properly. Refer to https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277 as the current bug on this. Debian is behind on updating upstream, so later today I will be preparing a package for Lunar that will have a -0ubuntu1 prefix for the latest upstream version. That works fine in Lunar. It also works fine in Kinetic and in initial tests in Jammy. Iâm installing test environments for Focal and Bionic. The problem here is, though, we have a mix of ânew featuresâ and âbug fixesâ together â there is no âmajor version bumpâ for feature branches vs. âbugfixâ branches, making it a comingled problem of ânew featuresâ and âbug fixesâ. Therefore, Iâd like to request a one-time exception for SRU processes to accept the same version packaged for each release using Lunar as a base, and adjusting the packaging as needed accordingly for older releases. That is, this will be an SRU, but it will accept the ânew featuresâ thatâre part of torbrowser-launcher that were not present in Bionic or Focal but are present in later releases. Most of the âfeatureâ changes allow choosing additional options, etc. but nothing that as far as I can tell changes the core functionality of the package. Iâm happy to discuss this further with the SRU and Release teams (IRC is always a way to reach me heh), but given the complexities of including the fixes and changes just to make tor browser 12 work with the older launchers, itâd make more sense and ease of fixing this âbreaks the launcher tool entirelyâ issue by simply taking the current version and making it match in the entire packaging structure. Iâm happy to spearhead this, but I wanted to put this to the Release Team and the SRU team for consideration before I go through the process of building all this for the SRU/MRE/Version Bump processes as well. A full changelog upstream is available on their GitHub - https://github.com/micahflee/torbrowser-launcher Thomas LP: https://launchpad.net/~teward Ubuntu Core Developer -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Special One-Time SRU Handling request for torbrowser-launcher
Hello, release team. Pursuant to a recent change for torbrowser-launcher and Tor Browser, we have a little bit of a conundrum that is leading to a one time request for SRUing the latest `torbrowser-launcher` to all currently supported releases. With Tor Browser 12 (TB12 for short here), upstream tor browser no longer uses locales, requiring folder cleanup from TB12 and download URL changes in order for things to properly function. Unfortunately, the code changes necessary to implement the changes to torbrowser-launcher are not easily nitpicked and include more than just these fixes, as it has new changes and such to make it work properly. Refer to https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/277 as the current bug on this. Debian is behind on updating upstream, so later today I will be preparing a package for Lunar that will have a -0ubuntu1 prefix for the latest upstream version. That works fine in Lunar. It also works fine in Kinetic and in initial tests in Jammy. I'm installing test environments for Focal and Bionic. The problem here is, though, we have a mix of "new features" and "bug fixes" together - there is no 'major version bump' for feature branches vs. 'bugfix' branches, making it a comingled problem of "new features" and "bug fixes". Therefore, I'd like to request a one-time exception for SRU processes to accept the same version packaged for each release using Lunar as a base, and adjusting the packaging as needed accordingly for older releases. That is, this will be an SRU, but it will accept the 'new features' that're part of torbrowser-launcher that were not present in Bionic or Focal but are present in later releases. Most of the 'feature' changes allow choosing additional options, etc. but nothing that as far as I can tell changes the core functionality of the package. I'm happy to discuss this further with the SRU and Release teams (IRC is always a way to reach me heh), but given the complexities of including the fixes and changes just to make tor browser 12 work with the older launchers, it'd make more sense and ease of fixing this "breaks the launcher tool entirely" issue by simply taking the current version and making it match in the entire packaging structure. I'm happy to spearhead this, but I wanted to put this to the Release Team and the SRU team for consideration before I go through the process of building all this for the SRU/MRE/Version Bump processes as well. A full changelog upstream is available on their GitHub - https://github.com/micahflee/torbrowser-launcher Thomas LP: https://launchpad.net/~teward Ubuntu Core Developer -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: New Official Flavor Process Issues (Was Re: Ubuntu Cinnamon Remix packages)
l be silenced if you don't approach this situation with civility, discipline, and the ability to not be enraged at each individual person you talk to on this matter. Everyone understands frustration. It's how you voice your opinions/concerns that matters, and if you do that wrong consistently in a way that may be against CoC especially on public lists, then it becomes a Problem(TM) that may come back to bite you. So as I said in the beginning of my message, take a deep breath and relax a little. If you truly believe that I need to be a core dev, (CC, DMB) Where did it say you need core-dev? You don't need to be MOTU or Core Dev to have upload rights for a package - just apply via the DMB PPU process. Get the upload rights for what you need specifically in the flavor. then you are saying any community member who wants to create a flavor needs to spend YEARS getting to that high of privilege. (DMB, Core Dev) No, you don't need YEARS to get the privilege of upload for the packages you need. Refer to the PPU application process. And that is not community friendly at all. I am a student, and I'm going to a magnet school in September (a CS school might I add). (CC) Irrelevant to the point that was raised. School is going to get more intense and I'm not going to be spending 6 hours a day on Ubuntu development. (Personal) I am not employed by Canonical. The amount of *actual* development work I do with Ubuntu nowadays is interspersed among my free time and is not easily noticed to the public at large. And while I may not have a ton of uploads going on right now, or a ton of development on packages being done here at the moment, most of my energy goes into my Full Time job and being paid for things, or going to school like I did for university and such did NOT interfere from me putting a couple hours a week into Ubuntu. You don't have to go hard core six hours a day of Ubuntu work. I haven't, and yet I sit on the CC, DMB, and have Core Dev rights today after putting a few hours work a week or so at most over the course of time in to get the recognition and hats I have. That didn't come from six hours a day of Ubuntu contributions, that came from me volunteering time I have when I have it and want to contribute, over the course of years, to get to where I am now. Nobody ever said you have to spend 6 hours a day contributing to Ubuntu or any specific flavor. Nor have I seen anybody be saying that now. (DMB) Further, the requirements for PPU are a lot lower to an extent than the requirements for MOTU and Core Dev - we still require you to understand basic things like how the SRU process works, etc. so you don't overstep your rights to upload specific packages, but we also focus *only* on the pacakges you have worked on that you're applying for in comparison to all your contributions. So the scope of what is assessed is different, and it seems you aren't understanding this. Again, to you this is hard to understand because you already **have** the upload rights. (CC) Calm down already. This level of aggressiveness and pointedness/stabbing despite other posts in your message here is the *wrong way* to approach this, and while we all get this way from time to time, there's been **a lot** of this type of frustration voiced by you in ways that **do not** get results and get you labeled as an irritant. Truly, with honesty, -Josh *From:* Jeremy Bicha *Sent:* Thursday, July 28, 2022 10:20 *To:* eeickme...@ubuntu.com *Cc:* Steve Langasek ; technical-bo...@lists.ubuntu.com ; community-coun...@lists.ubuntu.com ; itzswirlz2...@outlook.com ; ubuntu-release@lists.ubuntu.com *Subject:* Re: New Official Flavor Process Issues (Was Re: Ubuntu Cinnamon Remix packages) On Thu, Jul 28, 2022 at 9:55 AM wrote: > This most certainly is not a hasty escalation. I've been aware of > Ubuntu Cinnamon Remix for 3 years and in that time, Joshua's intention > was to make it an official flavor. They have been encouraged to become > an official flavor since Day 0. The escalation from my perspective is that it appears to me like y'all made a request to become an official flavor on Saturday, got a reply on Sunday, and then invoked the authority of the Ubuntu Community Council on Wednesday. I don't think that's being fair to the Tech Board. (CC) I agree with Jeremy here, the optics of this and the way you handled this, Erich, are bad. Next time, wait for Council quorum on an issue before we wave the CC hats around as "oh now this is CC escalated", because the optics are just as important as the real processes, and you didn't *need* to bring *this* up as a CC issue. You could have simply emailed the TB and asked the TB to better document the process, and copy the CC for awareness. This
Re: apache2 hint
Even with the proposed fixes that are made there to 'fix' the autopkgtests, they still fail with the same error. I am in agreement with Dimitri, can we badtest all the current kopano-webapp test failures given that the issue still remains with the deb2snap chromium transition? Thomas On 6/28/19 10:33 AM, Thomas Ward wrote: > > This also blocks nginx as well. > > Keep in mind though, this is being 'worked on' - namely, it's an issue > due to Snapped Chromium / Selenium now. > > https://bugs.launchpad.net/ubuntu/+source/kopano-webapp/+bug/1834052 > > Details on this badtest problem I put in this bug. The issue traces > back to Snapped Chromium though, and how Chromium / Selenium are > launching the test in kopano. > > > Thomas > > > On 6/28/19 10:30 AM, Dimitri John Ledkov wrote: >> apache2 is currently stuck in eoan-proposed >> >> it is blocked on >> >> autopkgtest for kopano-webapp/3.5.6+dfsg1-1: amd64: Regression ⻠, >> arm64: Regression ⻠, armhf: Regression ⻠, i386: Regression ⻠, >> ppc64el: Always failed, s390x: Always failed >> >> which it looks to me, that it has regressed since chromium deb2snap >> transition, cause that autopkgtest tries to use chromium snap as the >> test-browser-engine as part of the test. >> >> otherwise testing on apache2 is ok. >> >> Can kopano-webapp please be marked as force-badtest, due to chromium >> deb2snap transition? >> >> > -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: apache2 hint
This also blocks nginx as well. Keep in mind though, this is being 'worked on' - namely, it's an issue due to Snapped Chromium / Selenium now. https://bugs.launchpad.net/ubuntu/+source/kopano-webapp/+bug/1834052 Details on this badtest problem I put in this bug. The issue traces back to Snapped Chromium though, and how Chromium / Selenium are launching the test in kopano. Thomas On 6/28/19 10:30 AM, Dimitri John Ledkov wrote: > apache2 is currently stuck in eoan-proposed > > it is blocked on > > autopkgtest for kopano-webapp/3.5.6+dfsg1-1: amd64: Regression ⻠, > arm64: Regression ⻠, armhf: Regression ⻠, i386: Regression ⻠, > ppc64el: Always failed, s390x: Always failed > > which it looks to me, that it has regressed since chromium deb2snap > transition, cause that autopkgtest tries to use chromium snap as the > test-browser-engine as part of the test. > > otherwise testing on apache2 is ok. > > Can kopano-webapp please be marked as force-badtest, due to chromium > deb2snap transition? > > -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: nginx exception request
Hello! I've made on-line comments, links, responses, questions, concerns, etc. below. Apologies for the delay in my response, but as July 4th was a holiday in the US, and I was out of town away from my email. On 07/03/2015 04:41 AM, Dave Walker wrote: > On 30 June 2015 at 15:55, Thomas Ward wrote: >> On 06/30/2015 06:08 AM, Robie Basak wrote: >>> On Tue, Jun 23, 2015 at 10:50:05AM +0100, Robie Basak wrote: >>>> Please can we agree on feature freeze and SRU policy exceptions so that >>>> we can execute option A, or otherwise discuss alternatives? >>> Any thoughts please? Although we'd not execute on any exception until >>> 2016, Thomas needs to know now whether to merge 1.9 from Debian or >>> diverge on 1.8 for Wily. >> There is also another option that is likely less desirable than the >> other aforementioned options in the previous emails in this chain by >> Robie: We (or rather, I) could do absolutely nothing for Wily, and we >> can ultimately just deal with this closer to 16.04, such that we can >> have this discussion for a longer period of time. >> >> By doing nothing, 1.6.x will remain in Ubuntu for the duration of Wily. >> Features from 1.7.x which are now present in 1.8.x (nginx stable) will >> not exist in Ubuntu Wily, and even newer features (and to my chagrin, >> the "Disable SSLv3 By Default" change at the source code level) from >> 1.9.x will not exist in Ubuntu Wily either. This option allows us on >> the Server Team, and myself, to not have to immediately worry about >> merging, while users who want the newer features in 1.8.x and 1.9.x can >> simply use the already-existing NGINX PPAs that I maintain which package >> both NGINX versions for all supported Ubuntu releases. >> >> While input from the Release team is sought for Wily, so we can try and >> have less of a merge delta by 16.04, we can theoretically do nothing now >> for Wily, and then go with 1.9.x in 16.04, and then focus on the one-off >> policy exceptions or potential other alternatives then, rather than >> require the release team's input immediately. However, I believe it is >> a better option to consider 1.8.x or 1.9.x now for Wily rather than do >> nothing. >> > Hi, > > Considering there is effort to plan ahead for future releases and > potential SRU/MRE extraordinary updates, I quite think this requires > input from the technical-board. Rather than cross-posting this thread > to there, might I suggest a parallel thread is started there? > > My thought is that Nginx previously hasn't received as much love in > Ubuntu as Apache, so doing as much as possible to align with Debian > support is probably preferential. Although, teward seems to have been > doing a sustained effort at pushing it in Ubuntu. > > Perhaps it would be useful to look at the Nginx PPA statistics, to try > and gauge how many people are using it outside of the primary > archives? - teward, could you do an analysis on this? This produces > some nice charts - http://wpitchoune.net/blog/ppastats/ Well, I think we'll have a problem here. Launchpad and that tool don't get along, since the tool pulls *all* the data at once, which causes some issues to the API, in that it tries to get everything in one hit. That tool also doesn't appear very customizable to pull smaller chunks, and I know for a fact that wgrant was commenting "you'll want to tweak the code that you're using" (to quote him) when I was asking about the errors I'm seeing from Launchpad (in the #launchpad channel on freenode). I'm not fluent enough with pure C code to tweak this to achieve that goal of tweaking it, though. Do you have another tool on-hand that does the same general thing, Dave? I'm a little bit too busy with work the next few months to write a custom Python script myself with smaller data chunks to do this... > Nginx seems to have a pretty reliable upstream reputation, mixed with > how near the scheduled release is to the next LTS and common for the > prior LTS to be used until the next point - I would be confident in > putting weight behind this idea, providing that: > - LTS releases with the latest snapshot from hg upstream, and plan to > minimal SRU to tagged release (which there is prior art of) Unless I'm misunderstanding you here, I'm hesitant to pull the latest hg snapshot (at that time) in this case. The reason being there may be incomplete features there in the hg snapshot, with even more bugs than it may already have due to it being an in-development branch. I'd be more comfortable with LTS having the latest-tagged-release prior to 1.10.x from the hg repository (or nginx.org tarballs) rat
Re: nginx exception request
On 06/30/2015 06:08 AM, Robie Basak wrote: > On Tue, Jun 23, 2015 at 10:50:05AM +0100, Robie Basak wrote: >> Please can we agree on feature freeze and SRU policy exceptions so that >> we can execute option A, or otherwise discuss alternatives? > > Any thoughts please? Although we'd not execute on any exception until > 2016, Thomas needs to know now whether to merge 1.9 from Debian or > diverge on 1.8 for Wily. There is also another option that is likely less desirable than the other aforementioned options in the previous emails in this chain by Robie: We (or rather, I) could do absolutely nothing for Wily, and we can ultimately just deal with this closer to 16.04, such that we can have this discussion for a longer period of time. By doing nothing, 1.6.x will remain in Ubuntu for the duration of Wily. Features from 1.7.x which are now present in 1.8.x (nginx stable) will not exist in Ubuntu Wily, and even newer features (and to my chagrin, the "Disable SSLv3 By Default" change at the source code level) from 1.9.x will not exist in Ubuntu Wily either. This option allows us on the Server Team, and myself, to not have to immediately worry about merging, while users who want the newer features in 1.8.x and 1.9.x can simply use the already-existing NGINX PPAs that I maintain which package both NGINX versions for all supported Ubuntu releases. While input from the Release team is sought for Wily, so we can try and have less of a merge delta by 16.04, we can theoretically do nothing now for Wily, and then go with 1.9.x in 16.04, and then focus on the one-off policy exceptions or potential other alternatives then, rather than require the release team's input immediately. However, I believe it is a better option to consider 1.8.x or 1.9.x now for Wily rather than do nothing. -- Thomas Ward -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
