Triage/migration report: 32 Oct 2019
== Triage == Date range identified as: "Wednesday triage" Found 13 bugs LP: #1840963 - (Expired)[vsftpd] - 500 OOPS: unrecognised variable in config file: ssl_tlsv1_1 * Was a user error, they just didn't know how to close it as invalid. --> Closed as invalid Of the remainder, half were libvirt/qemu bugs just getting closed as fixed, or other state changes. No triager action needed. Just one of interest: LP: #1848556 - *(Triaged) [qemu] - qemu-img check failing on remote image in Eoan * Reporter has checked the PPA and confirms behavior is fixed. * Guessing next step will be to roll fix into package for SRU review? --> Not sure on action, maybe assign to Christian? Another half were spam to apache2 by a "Chinese girl" about shoes. == Backlog == LP: #1800040 - (Triaged)[bacula] - bacula-fd segfault on status client from Bat * User had provided slightly more information the backtrace, but still is not fully diagnosed. As per Robie's initial triage, it's a low priority issue we could look at if a fix/patch were identified. None of the more recently collected info seems to change that assessment, so the backlog seems like the best place for it. --> No triaging action needed. == Proposed Migration == 28 packages needing attention * Bulk of these look like they are depending on perl or python, and guessing they're affected by ongoing transitions. Didn't look further. * asterisk / mysql-8.0 - Error is "Unable to connect to remote asterisk" - No one had done a re-test, so just triggered that, in case it's just spurious. * memcached, tmux, unbound: Look green, only 3 days old, & marked "Candidate". Guessing they're just waiting in queue. Bryce -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
NGINX (again) and 20.04 Development Cycle
Whenever we approach an April release, we have to always be considering NGINX and the fact that around the same time we release a new stable version is cut from Mainline. What this means is, as NGINX decides to release a Stable version they use the NGINX Mainline branch to do more active feature development, feature implementations, etc. and then once it's cut 'no longer support the older versions of NGINX' before it. Currently, we have been tracking NGINX 1.16.x which in April will become the "No Longer Supported" branch and at this point will be over a year old. NGINX Mainline is currently at 1.17.5 and has bugfixes, feature changes/revisions/updates, etc. and will eventually become NGINX 1.18.x around when we release 20.04 LTS. In the past around the LTS releases we've switched from tracking NGINX Stable to NGINX Mainline in anticipation of a right-before-release or shortly-after-release upload to change the version string from 1.17.x to 1.18.0 to coincide with NGINX upstream releases. I'm not fond of keeping 1.16.x in the repos for 20.04 LTS if I can avoid it, since it's technically no longer supported once NGINX releases upstream. around when we release 20.04. Do we want to pursue this approach of tracking Mainline again with the intention of FFes and MREs during the dev cycle up until the 1.18.x release after which we SRU that version string change that in? The other alternative is to keep 1.16.x in the repositories and then forcibly jump to 1.18.0 later but that's a more major version bump with a lot of feature changes. (I'd like at least for 20.04 to get on the latest NGINX Mainline branch with the intention of keeping it updated with FFes during dev and then a final version string change either just before or just after release to get us tracking 1.18.x as the version number.) I'd be happy to file any relevant requests to the Release Team ahead of time to get any of the devel cycle headaches handled. Thomas -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
