Ubuntu Monthly Update Cadence Proposal

[Xen]

Hi Bryan,

Pardon me if my opinion is not worth much here, but I would still like 
to offer some five points.



1. The lack of staging in Linux makes it rather hard as mr. Basak points 
out, there are few foundations of stable libraries; Linux would need 4 
layers of stability in the sense of layer 1 (glibc) remaining stable 
over the longest period, layer 2 remaining stable for half that period, 
layer 3 for half that, and layer 4 can do whatever it wants.

I mean that if glibc remained stable for 4 years, the next layer for 2 
years, the next for 1 year, then layer 2 could depend on layer 1, and 
layer 3 could depend on layer 2, and layer 4 could depend on layer 3.

Stability means: no changes in functionality.

2. If any such stability was achieved upstream it would make it easier 
to achieve your goal here; it tends to be the case that newest libraries 
constantly depend on newest libraries, newer versions breaking older 
programs.

3. If regardless you accomplish identifying sets, it would lead to my 
next point.

4. Apt is geared towards advancement, not retreat. Meta packages can't 
be used to uninstall, and rarely to downgrade. Any component grouping 
would benefit from being real atomic entities that can be removed as a 
whole as well.

5. My main point is that components could introduce new apt jargon in 
the sense that:

      "apt groups" would list all components
      "apt list <group>" would list the packages for that component
      other apt commands remain the same, but might have slightly 
different operation.

Once this tooling is in place management of these components would 
become a lot easier.





Additionally with respect to point 4, I think it is essential that 
people can also downgrade to a previous 'Monthly'.

This means that all the library versions of that monthly still have to 
be available in the repos essentially creating 'frozen' sets for each 
month.

Also, if meta packages (or new "groups") pull in the upgrades they must 
be specified on exact versions so that pervious meta packages can 
downgrade what was upgraded.

Ie. the meta package "monthly-latest" pulls in "monthly-18.10.4", with 
"monthly-18.10.4" pulling in the changes, but "monthly-18.10.3" would be 
able to undo all of that.

This would imply that those monthly metas do not only indicate what they 
upgrade, but also what they didn't upgrade.

The monthly metas then indicate the exact versions of all core 
components.



As an additional colloquium:

   Core components might also need to specify ALL libraries being pulled 
in by their upgrade, and might require those libraries to be split off 
into components of their own if these libraries are shared between core 
components.

   At the same time this creates inflexibility; you cannot keep using an 
older version of udev if it breaks some device.