© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
e3ace39
(Get the code!)
@vorlon: I agree that upgrading to v242 comes with risks, but the risk fairly hard to assess exactly.
One measure can be the number of upstream stable backports and this is as follows:
rbalint@
v242-108-
rbalint@
v241-188-
This measure does not give a clear guidance, since lack of backports can mean lack of regressions or the lack of interest to backport as well.
Fedora 30 is also on systemd 241 and Fedora rawhide already moved to 243:
https:/
It is still a question of Ubuntu wanting to use Eoan to get feedback on v242 features and regressions in preparing for 20.04 LTS - or we want to have v241 in Eoan to have lower risk of regression and lower required effort to keep systemd in Eoan but having a bigger version bump at the Eoan -> 20.04 upgrade.
If the decision is to keep v241 for Eaon then we can merge changes from Debian stable and upstream v241 stable when needed and I move on to land a good v243 at the beginning of the 20.04 cycle.
If we decide to approve this FFe, I can upload 242 today, we can merge 242 changes from Debian but only in the next few weeks - maybe two months, until Debian moves on to v243 then we are on our own maintaining v243 debs with the help of upstream's v242-stable branch.
I can decrease the unknown risk by merging everything from v242-stable and doing a test round _before_ uploading 242 to Eoan, but I did not want to do that if the decision is sticking to v241 no matter how this testing run goes. So the third option would be conditionally accepting the FFe, only accepting v242 to Eoan if it includes all patches from v242-stable and the autopktests all pass. Picking this I need ~one more day to update the package and run the tests so it could land early next week.