Thank you for your response Matthew.
At times we can be managing several hundred desktops. They get installed
over time and with a script that makes sure they auto-update packages
and reboot if there is a kernel update. For systems that can't be
allowed to reboot we get an email advising us. All of that is good.
I guess what I was really thinking about was a version free repository.
Similar to the no_arch repository.
This would be for application developers etc who don't need to rely on
distribution version. It could even apply to kernels.
As a package developer my biggest issue has always been keeping enough
versions of Fedora and RH on machines to create versions of the product.
A single release will always need 3-6 OS packages. I'm not sure this is
either productive or efficient.
I'll try to take the discussion to FESCo.
PS really appreciate the work you guys do.
On 9/11/21 07:21, Matthew Miller wrote:
On Mon, Nov 08, 2021 at 03:11:55AM +0000, Rick Marshall wrote:
I'm trying to understand why we have to have Fedora versions.
Fedora is a my favourite Linux however the version upgrade is
problematic when managing large numbers of machines. I have my
reasons for using it in production as a desktop, but not as a
server.
Why do we have versions instead of constant updates as happens
within a version?
We try to concentrate large, planned changes on the release boundaries.
Hopefully that means that we can make the user-impact of those changes
smooth, but it does mean that they tend to be all concentrated at one time.
However... the way we do things lets you choose when you want to absorb that
change.
You can see the changeset in advance:
https://fedoraproject.org/wiki/Releases/35/ChangeSet
https://fedoraproject.org/wiki/Releases/36/ChangeSet
and plan around that, as well as look out for common problems at
https://fedoraproject.org/wiki/Common_F35_bugs
.
If we did a perpetual ("rolling") release, there would be the same amount of
change, but you'd get it sporadically -- maybe some Thursday morning
suddenly becomes a lot of work.
And, of course, if we just had one supported release, you'd be stuck with
needing to do upgrades in April/October, on our schedule. But, we
intentially have two supported releases, with 7 months of overlap. That way,
you can schedule when you want to do the bigger updates — including deciding
to entirely skip a release if you like.
Like all Linux distros, we're always absorbing a lot of change coming from
thousands of upstream projects. We (Fedora) think this approach is the best
one for delivering that change to users in a polished, friendly way (on
desktops _and_ servers). In the past few years, we've put extra work into
making sure the upgrade process is painless — _usually_ not much different
from a really large regular update.
What are the problems you are encountering with managing this on large
numbers of machines? (What is the value of "large" in your case?) Do you
deploy with golden images, via pxe and kickstart, or by some other method?
Do you use ansible or some other config management tool?
Happy to ask elsewhere if this is the wrong place.
This probably isn't the best place, because it's not really a test / QA
decision. FESCo is the governing body for the overall release schedule
(which is then implemented and managed by the Program Manager).
--
*Rick Marshall*
Zenucom - where it all started <https://www.zenucom.com>
Unibase - database and language <https://unibase.zenucom.com>
Uniquote - ERP <https://uniquote.zenucom.com>
LinkedIn <https://www.linkedin.com/in/rick-marshall/>
Mobile: +61 0411287530 <tel:+61411287530>
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
