[Proposal] New way to handle upstream updates

Today @giacomo and I were thinking about this solution and its feasibility. How to implement it?

We found two alternatives.

1. Software center banner

As upstream problems occurred with minor releases (7.3->7.4), we could display a banner in Software center page that explains what will happen if the system is updated. In other words, instead of the usual yellow “Updates available” banner, we could display a scaring red one: “System upgrade”.

This solution is an enhancement of the current policy. It does not implement the fast/slow policy but still leaves the responsibility of updating the system to the sysadmin.

It provides a better awareness of what’s going to happen (hopefully).

2. “Slow” policy mirror infrastructure

The fast/slow policy requires a set of additional mirrors to serve the “slow” updates. Whilst “fast” would rely on the upstream mirror infrastructure (as we’re doing by now), the “slow” must be implemented with our own servers.

This solution seems quite expensive because upstream mirrors are on a different order of size compared to our tiny NethServer repositories. Disk requirements (yum repolist -v) are the following

At minimum:

base, updates / 26 GB

But also sclo and extras should be mirrored for completeness:

base, updates, sclo, extras / 40 GB

Moreover, the less mirrors, the more bandwidth/load is required!

What do you think? Who’s available to host a such mirror? Isn’t the banner enough?

7 Likes