-----BEGIN PGP SIGNATURE-----
wsF5BAABCAAjFiEEXHq+og+GMEWcyMi14n8s+EWML6QFAmfHoEwFAwAAAAAACgkQ4n8s+EWML6SJ
wA//TSQor8GA3UXoQyVbHf0gvVyLoLjX2/bS2OJi34YdO+dDGaMKzdgueMFAuOgypW9/aCo4OEEL
C9kcqMamkvKWx7vXyNh3NxAsqqMb1T9weZ1859NW9jIXRkHm8Wj41CcxyUyoFW+g8VvU+rJDrXbL
pE3h7GqxB3Hh32eNenBAGWu/Nrzl4x/KB1xV18jj3xDgBtk0u4AR+EpbNDQ+VCjbR1Q3Zgm0JbpB
GCJBj2C8zrCq36bm4BKky3TIAlbRrGuu5+EFI+sR1jUAGVXSdFMWh1hm7LlKCg8uruu2IjoMCqYL
l6BBg4SVErlgRj81ZXoIJfdGW73kEOJnp+ocae8m07stnNyfzj9iRZyDs5v8YB7EjPV+UkMou5LS
fx3U17TrDo5B57ntAJAXz8v0g4hT054kQYu92ECiCbo/CkJAEA//Ucd7WjKiIU/qkIg81AZnpAdr
oKJQhNl7rYJSiLDcTU8aV9f+pB3M6hJS+Ur2ShJpSUwc8oXAD/myG0YQnAabaX29ECQM9zACWkly
Sa7UZK+b51MV8ubgpacBc3iNH2jnF85Ik81JAmmF5aqqWqTRjAl2TG5T6yddXdeQ49xAtx+1v9Hx
T9lzJbtrlcEaDZIA8Gbsrhz2bC4LM+zEt7QDsE/YuEv4d+7oT7lUfDw4KLp5Lq27byMfrMcLrWCX
Lcw=
=QGxy
-----END PGP SIGNATURE-----
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
simon@tsimonq2.net
@tsimonq2:ubuntu.com on Matrix
tsimonq2 on LiberaChat and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4
