Dear Ubuntu Developers, Firstly, I sent this email to the Technical Board originally, but Robie made a solid point that I should open this up to a wider audience. Thanks, Robie!
This is largely a copy/paste of that message, sorry if I've missed changing any wording from the TB to Ubuntu Developers generally (or if something doesn't sound quite right.) The TB is welcome (in fact, encouraged) to chime in, though. :) I have a set of policy considerations regarding Debian Import Freeze, and some thoughts on how to schedule it in a way that will be sustainable and stable in time for the 26.04 LTS cycle. While these are technical considerations, I would like to ask you to take some time on a response and discussion, and read the questions in spirit as much as the letter. To be clear, I am not asking for a vote on something specific or pointed; rather, I would like the relevant parties to develop a schedule and clear policy that works well given Debian's upcoming release. Please note that I tend to follow RFC-2119 when defining terms such as (but not limited to): "may," "could," "should," and "must." Here are the considerations I have in mind: - Firstly, this link is to Debian's current freeze policy: https://release.debian.org/testing/freeze_policy.html - Depending on the final date of Full Freeze and how close it is to Q cycle's Feature Freeze, we could extend Debian Import Freeze (but not Feature Freeze), under the assumption that we trust the Debian Release Team. - This could involve an extended sync blocklist with a small amount of automation. - Depending on the final release date, we may want to consider whether autosync should be disabled in R cycle altogether. - I understand this is a bold suggestion. That being said, many transitions happen in Debian immediately after a release, generally speaking. - Do we want the effects of Debian's post-release floodgate opening to be picked up via autosync immediately before an LTS release? - Let's go over the reflections, notes, and statistics on the Noble cycle (being the previous LTS cycle) and the circumstances that led to an unusual cycle/release. - Would it be a fair idea to set stricter feature-based requirements during the R cycle, to avoid major changes being stuck in the proposed pocket? - Do we already have a general idea of what transitions will be happening the next two cycles, or more specifically, R cycle? - Is there anything left to deprecate or remove before the R cycle? - Something major along the lines of an old GCC version, GTK 2, or X11. - Anything else you can think of. My aim is for this to be constructive, and to give everyone plenty of time to think about and consider these points before they become a tangible concern. As the highest-level technical policy making body in the Ubuntu project, I originally thought that these questions would be solely appropriate for the Technical Board, which could work to drive consensus and smooth coordination among sub-teams and Canonical partners as appropriate. In time, please do let me know what you think. Warm regards, -- Simon Quigley si...@tsimonq2.net @tsimonq2:ubuntu.com on Matrix tsimonq2 on LiberaChat and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
