Ubuntu Monthly Update Cadence Proposal

[Xen]

Bryan Quigley schreef op 02-02-2018 17:55:

>> Stability means: no changes in functionality.

> Ah, this is the key point of my proposal.  Stability for my purposes
> means predictability when changes in functionality will occur.

I understand, I was just meaning to say that there is no culture or 
policy that says "use older versions of libraries".

One of the reasons MS Windows has been stable for so long is that they 
basically use ancient libraries.

The system got released, installed, and the core library set was stable 
over a long period save for some "runtime" updates (VC++ 
redistributables and later .NET redistributables).

After that, any applications that wanted their own libraries had to 
install them themselves.

In Linux I believe there is a tendency to always use the latest and the 
greatest.

Part of that is logical but in practice many version dependencies are 
not really defined because developers forgot about them, when everything 
is upgraded together, no issues, if you upgrade stuff in isolation but 
according to Apt dependencies, stuff might break.

I am just saying that this rather makes your efforts a lot more 
difficult to actually attain.

But if you can limit your "components" to smaller, more important 
elements and leave the bulk to the traditional upgrade mechanism, then 
perhaps there is not so much an issue.

> I did consider that parts of this proposal might be easier in snaps,
> which would be a bit more like you describe.

I know.

I just wanted to say I guess that the limited ability of Apt to actually 
undo operations makes it a lot harder for users to deal with breakage, 
it appears a quite un-considered use-case in the Apt ecosystem 
(downgrade? Why?)

This in turn makes it more difficult to determine what an upgrade really 
means and what undoing an upgrade really means.

Ie. upgrading to a newer kernel is standard, undoing it is non-standard.

So if the goal is stability in the face of updates, then users would be 
a lot more forgiving of breakage if "undo" was an accessible operation.

> I tried to limit to items that we could test for a 6 month period of 
> time.

Yes in general it occurs to me that certain core components might have 
reduced dependency sets (like the kernel) although I am sure that 
particularly the graphics stack thinks differently about that.

Isn't your main goal to achieve clarity for kernel and mesa updates?

I mean, to give them more proper "handles" so that you can define an 
Ubuntu installation in terms of their installed "stacks".

Right now packages are just a huge swamp (not trying to diss anyone, it 
is just an unidentifiable whole) without clear sign posts.

Defining "groups" would make it easier to give version numbers to "core 
components" and make stuff like Mesa more of a familiar "part" of some 
Ubuntu computer.

For me in Kubuntu the only graphical way to know the Mesa version is to 
run KInfoCenter and go down into Graphics -> OpenGL; but for me Mesa is 
something I don't know about.

Whereas today it seems to become more and more important.

Particularly the updates for e.g. Xenial have been all about the Mesa 
version (and the Kernel).

Your goal is to make it visible to the user right?

>> 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.
> 
> Then we have monthly releases, I specifically didn't want to do that.

Barring that, you could never easily downgrade.

However, I think you want to reorganize, temporally restructure, 
refactor as it were...............

You want to redistribute in time when these updates happen.

It just has very little benefit if you can't also downgrade.....

But what you're basically suggesting is let all of the other upgrades go 
on without issue and simply plan ahead for the bigger ones, coalesce 
them, announce them, give them a version number (milestone), and make it 
a public schedule.

If downgrading is not a necessity then it's only about changing the 
order of things right.

It's just a little more structural planning in the hopes that e.g. the 
kernel can be upgraded first, then the graphics stack a month later.

Then the structure can be published (not trying to condescend here) and 
people will be happy ;-).

But I don't see the big difference with announcing ahead of time when 
the hardware-enable-ment stacks will occur.

I also don't see the big difference between an LTS that has HWE updates.

What would this "rolling release" have extra over LTS + HWE?