Recently, there have been a lot of discussions on this list as well as
we have internally about onboarding. During our internal brainstorming,
we were initially discussing that it could be useful to have some
package one can experiment with without being too much worried about the
However, discussing this back and forth, we figured that it might also
be good idea to actually have something such as "onboarding" package,
where new coming package maintainer could gradually gain experience with
the packaging workflows. So the simplest tasks could be:
1) Add changelog entry into onboarding package and open PR with the
change. This would not require too many privileges. Alternatively this
could include change to "CONTRIBUTORS" file. I suspect that also some
current Fedora contributors might be interested to send such PR ;)
2) Second step could be something similar, but that would require the
packager to be already sponsored and they could go through the whole
process themeselves just with some light guidance if needed.
This could be extended in the future. E.g. next step could be:
3) Submit module update.
Apart from gaining experience, this could also help with the common
question "where should I start". And of course our sponsoring guidelines
could be refreshed suggesting/requesting to take these steps at some point.
I've tagged 13.0.1-rc1. Testers can begin testing and uploading binaries.
There is still time to submit fixes for the final 13.0.1. I'll give more
details about timelines and how to do this once the bugzilla migration is
complete. Currently, bugzilla is read-only, so we can't submit any fixes
Now that we've released F35, I'd like to share the first semi-annual
release retrospective survey:
I kept it intentionally short and open-ended. It should only take a
few moments of your time. If you have any questions, please let me
know. If you have suggestions for the next time around, there's a
field for that in the survey!
The survey is open through 4 December. I'll share results on the
Community Blog in late December or early January.
If you haven't seen, Adam is running a QA-specific retrospective as
well. If you only have QA feedback, you can record it on the wiki page
and I'll incorporate the responses into my final analysis.
He / Him / His
Fedora Program Manager
= Users are administrators by default in the installer GUI =
== Summary ==
The Anaconda installer GUI will have the administrative rights
checkbox on the User screen ticked by default.
== Owner ==
* Name: [[User:Vladimirslavik| Vladimir Slavik]]
* Email: vslavik(a)redhat.com
== Detailed Description ==
Currently, the Anaconda installer GUI presents an unticked checkbox
"Make this user administrator" on the user setup screen by default.
This means users have to discover the control, understand its meaning,
and consciously decide to change the value from the default one.
However, computer usage by individuals is heavily skewed towards
single user machines where the (sole) user has administrative powers
over the machine by invoking `sudo`. This has been always reflected by
the design of the screen, which allows only a single user to be
created. The GNOME first time setup also creates a single user - and
makes them an administrator without asking.
The proposed change merely changes the default GUI state to be in line
with this expectation.
Further, this change of defaults complements the default for root
account. The redesign of root setup screen in Fedora 35 makes it clear
that root should be left locked. This change makes it clear that the
user should be the administrator. Together, these defaults will let
the user satisfy all user account options by filling in nothing more
than the user name and the password (twice to confirm).
== Benefit to Fedora ==
One less footgun in the installer for entry-level users. They will be
able to rely on defaults and achieve the expected outcome.
== Scope ==
* Proposal owners: Isolated change - adjust Anaconda code to do so as
suggested here. Low effort.
* Other developers: No changes needed.
* Release engineering: Different defaults ''could'' impact installer
testing. [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives: None.
== Upgrade/compatibility impact ==
No impact. Installation implies teardown of previous system, including users.
== How To Test ==
Start Anaconda installer for the Server variant, open the user setup
screen, "Make this user administrator" is checked = pass.
Should be variant / spin / hardware agnostic, with the caveat that the
presence of user screen is configurable, so in many cases the screen
is not reachable.
Kickstart installs are not affected.
== User Experience ==
Users installing Fedora will no longer be forced to spend time
deciding how to arrange the administrative powers (they, root, both?)
and configuring that. They will be able to fill in user name and
password and the default configuration will be valid. They can give in
to the power of defaults.
For users that want to configure the system differently from the
majority use case, the controls to do so are still as they were, only
the defaults are different.
For those installing Fedora manually often, muscle memory for user
screen will break, as the checkbox will no longer have to be toggled.
== Dependencies ==
== Contingency Plan ==
Any Fedora QA and OpenQA changes reflecting this will have to be
reverted. Other than that, there is no technical or process
requirement for this change, so no impact. The change does not happen
and previous defaults remain.
* Contingency mechanism: N/A
* Contingency deadline: N/A
* Blocks release? No
== Documentation ==
== Release Notes ==
In the User spoke, the "Make this user administrator" checkbox is now
checked by default. This improves installation experience for users
who do not know and need to rely on the default values to guide them.
He / Him / His
Fedora Program Manager
Hi, I have a question for the FESCo and Council candidates: do you
support allowing Fedora src-git repositories to be hosted on
gitlab.com, which a proprietary software git forge?
Fedora Council has already effectively stated that dist-git
infrastructure must remain open source, but has no such promises for
src-git. I understand Council has previously stated that Fedora
infrastructure should depend on proprietary software only if no open
source alternative is suitable. Do you believe that there exist no open
source git forges that would be suitable for Fedora src-git?
The most obvious open source alternative would be the open source
version of GitLab. There is also Pagure. I think we're giving up on
open source infrastructure rather quickly here. I'd like to know what
the candidates think before voting.
anyone had a successful experience with Fedora 35 Cloud images, and
Seems like we switched from ext4 or xfs to 'btrfs', and guestfish
doesn't work with the images, am I right? At least I had problems
on EL8 hypervisors so far.
Fedora 33 will go end of life for updates and support on 30th of
November 2021. No further updates, including security updates, will be
available for Fedora 33 after the said date. All the updates of Fedora
33 being pushed to stable will be stopped as well.
Fedora 34 will continue to receive updates until approximately one
month after the release of Fedora 36. The maintenance schedule of
Fedora releases is documented on the Fedora Project wiki . The
fedora Project wiki also contains instructions  on how to upgrade
from a previous release of Fedora to a version receiving updates.