Whilst I understand NS is based on CentOS and the fact that CentOS is based upon RHEL, would it not be sensible to provide our own documented interpretation of these polices.
Whilst I do not wish to appear to be rude or discourteous, is it not a bit of a lazy cop-out and overly bureaucratic to suggest that developers and repository administrators should refer to a load of decentralised documents (written by non NS members) for these important policies?
I agree, we should write them down!
Let’s find a solution to handle upstream updates and document it properly!
Well, IMHO you’d document only what’s different from the upstream policy… no need to rehinvent the wheel…
the KISS phylosophy firts of all
@Stefano_Zamboni,
I understand that we do not need “reinvent the wheel” or to make any major alterations to any existing documentation but do think that there needs to be some form of policy / procedures easily available to the community.
I am afraid to say that the attitude that is being expressed by yourself reminds me of similar attitudes expressed by British civil servants / public servants (ie. “it is not my responsibility to provide this information and you must trail through a number of documents before you are provided with the relevant information”).
Also, I do consider that using “business speak” / poorly formed acronyms such as “the KISS philosophy” demonstrates a level of indifference and a form of lazy thought process.
We are here not only to provide a product (in the form of the NethServer infrastructure / framework) but also to support and aid the community, and not to act like a load of bureaucratic, imbecilic “jobworths” (no offence intended).
well… we already have NS’ specific documentation about NS’ unique features…
NS heavily depends on upstream… for all the topics where NS adheres to upstream there’s no reason to rewrite any documentation, because:
@Stefano_Zamboni,
“Time is money” and the rest of the community, be damned!
When are we going to start using the above statement as our mantra / slogan?
I think we should ship @stephdl 's module with 7.4
It works fine:
and you can have different update-levels, install or download only, send mails…
It covers my needs. 
I don’t think so in community environment. Here no one should be moneydriven.
@medworthy
We can only try to improve processes, but we never can be 100% save not to hit a bug with an update.
Normally we do not want to touch running system, but we do need to install updates because of security reasons. So this is a dilemma.
@flatspin,
I understand that we will never be 100% perfect but that should not be used as an excuse to hold us back from trying.
maybe you misunderstood me… my time, your time, everyone’s time is valuable… if we have to invest it on the product, we’d rellay invest in something that is new, unique, not just rewriting something someone else already did.
I’d prefer to spend 2 hours a week to test and debug something new, instead of copy and paste Centos’ documentation to document something useless (already existant)
hope my POV is clearer now
That’s right, but to be also a little philosophic:
If you reach a certain level, the effort to getting better grows exponentially and at some level it doesn’t make sense to invest more, because the investment doesn’t stand in any relation to the improvement.
The question now is: Are we allready at that level? 
@Stefano_Zamboni,
This is a large and diverse community (I use the term “diverse” in a broader meaning and not within the current limited politically correct / corporate speak definition).
Sure, you may not have time or the inclination to examine the wider issues related to this subject, but there are others that would like to see a more integrated approach to these related issues.
Remember, no man is an island, we are all part of a community with similar / overlapping aims and objectives.
probablement à l’insu de mon plein gré (french joke)
More seriously, what this module needs more ?
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?
Of course not
But please guys don’t go off-topic, we should focus on what we can do NOW with our repositories in order to fix the problem turned out at the conference, as @giacomo correctly explained.
I was pointed to Proxmox subscription plans and this thread came to mind. We could cover the slow updates repository costs with a paid subscriptions plan.
https://www.proxmox.com/en/proxmox-ve/pricing
Probably worth a new thread @alefattorini.
You make me think the two “alternatives” aren’t mutually exclusive.
We can implement both the banner and an alternative (slow/managed) updates channel!
------------------------------------------------------------------------------------------------------------------------
74,4 GiB /smeserver
60,8 GiB /archlinux
3,1 GiB /nethserver
733,3 MiB /stephdl
actually the 4 repositories hosted on my mirror
While we can keep going the discussion on a possible paid subscription plan, I would like to have some firm points to proceed with next NethServer release.
If anyone agree, I’d go with:
yum-cron package to the core, so anyone can enable automatic security updates (please bear in mind that a security update could also disable insecure feature causing incompatibilities usually with legacy clients)I think it belongs to the manual- splitting up to much makes things more complicated, than they already are.