Is it still Open Source? Are we all beta testers?

[danb35 (Dan)]

@davidep

Isn’t an alert message already shown in Software Center? Do you think we need to reword it differently?

I don’t think that message adequately conveys “you will break your system if you install these updates”.

[davidep (Davide Principi)]

I feel kinda dejavouz… Just a recap

The only thing we catch in Software Center by now is the availability of a new minor release, by watching the centos-release RPM version. Instead of just saying “update available” we show “distro release available”.

How can the Software center decide/know if the update breaks the system? It is not automatic. Not everybody installs nDPI or dahdi kernel modules that could be broken; who knows if the nut package from EPEL will break again in the next release? …and so on.

CentOS follows the RHEL release cycle. They claim to be just 7, but RHEL uses to upgrade packages at minor distro release to limit patching. We rely on this convention and we know (as any CentOS sysadmin) that an upstream minor release is critical, more critical than others.

This cannot be avoided and leads to the issues we know well. The howto/feature proposal would solve those issues but has a (big?) limitation: it does not stop updates from EPEL and SCL. They can break the system too!

Solutions are welcome

[alefattorini (Alessio Fattorini)]

There is a solution: keeping all NethServer NOT updated until the end of the world
Just joking

[davidep (Davide Principi)]

@pike

And prone to be broken by bugs and incompatibilities, when CentOS start to release a Y.x+1 version.
There’s nothin particularly wrong with that, if its clearly stated into documentation as “major warning” at first page.

How can we improve the documentation? I think this is already stated here

http://docs.nethserver.org/en/v7/packages.html#software-updates

If I read it to the end, the Installation section finishes with a link to it (install additional software).

Our rules for developers about updates are documented here

http://docs.nethserver.org/projects/nethserver-devel/en/v7/development_process.html#package-updates

[pike (Michael Kicks)]

@danb35

That sounds like something you could change pretty easily.

Yes, it could. But for do a suggestion/request i must register both the community and github, mandatory?
My answer is “no, should not be mandatory for suggesting improvements and asks feature”.
I am not pretending that all requests and suggestions should be translated into improvements and implementation…

@alefattorini

There is a solution: keeping all NethServer NOT updated until the end of the world

Just joking

There’s another solution much more “stable” by adopter perspective: this situation should not happen.
I’m glad that you’re laughing, Alessio, but being as constructive as possible, “joking” won’t ease the situation. Which by my persective is quite crucial for the adopters.

@davidep

How can we improve the documentation? I think this is already stated here

I think that some warnings and mandatory checkboxes could help to warn the installers.
I know that is always better read documentation before setup. Sometimes it’s just not enough to avoid mess and critical situations.
For the account provider (which can be choosed after installation and update) it’s quite well specified that you can’t go back if you take a path or another.

[danb35 (Dan)]

@pike

Yes, it could. But for do a suggestion/request i must register both the community and github, mandatory?

“Must” is probably too strong a term, and “submit a PR” hasn’t been the standard response to most feature requests. In this specific case, you’ve made a suggestion. The devs (apparently) see it as something that isn’t objectionable, but is also pretty low-value–it won’t hurt anything, but it isn’t going to do much good either. If you want this in the software, you can either:

• Do the work yourself and package it up so that all they need to do is push a button,
• Wait for some other user to do this, or
• Wait for the devs to get around to it, if/when they ever do.

The first definitely involves a learning curve, and the fork/branch/edit/submit PR process isn’t the most intuitive (though there are lots of tutorials out there, and in this case you could do it all on the github.com web site). But github is used for a lot of Free Software projects, so it’s experience that would be pretty useful in this world. And if you do that, it seems quite likely the change will be incorporated.

Edit: I think the bottom line is that, if you want something added, the more of the work you can do yourself the better. The more value others perceive in your suggestion, the more likely they’ll help.

[pike (Michael Kicks)]

I am not a developer, nor HTML editor, nor a skilled linux sysadmin. Maybe do something by myself could help broke the whole wheel.
IMHO, not a good idea

[danb35 (Dan)]

Neither am I any of those things, but I was able to figure it out:

Remove direct link to server manager from default index page.

Edit: The HTML knowledge applied here was knowing how the <a> tag works. If I hadn’t already known that, I probably could have figured it out from the context of the rest of the file. If not, the link to the correct page of the manual probably isn’t necessary at all, but I thought it would be helpful. Take a look at https://www.familybrown.org/ for the result of my edits.

[stephdl (Stéphane de Labrusse)]

@pike

I am not a developer, nor HTML editor, nor a skilled linux sysadmin. Maybe do something by myself could help broke the whole wheel.

IMHO, not a good idea

I became a developer because I saw that SME Server lacked of dev, my first question was: what is a patch…I started from far. If you really want it, you can.

I was 40, OK I missed a lot of sleep hours