# DataCentre Move Update: 2020-06-17
Hi everyone,
I hope you are all having a good week! I would like to give you some
updates on the Data Centre Move project that some members of the CPE
team have been involved in over the last few months.
As you are probably aware at this point, the Fedora hardware has been
moving from the current data centre in Phoenix, Arizona to IAD2 in
Washington and to facilitate this move, we have been reducing services
available in Fedora to what is essential for operations over a 6-8
week period.
We are now officially operating in the reduced Fedora service and the
final hardware shipment has been packed up and is in transit to its
new home!
We are expecting to begin re-racking the hardware in the new
datacentre from next week, beginning June 22nd.
### Service Bringup Schedule
The team intend to prioritize the bringup of the following, but not
limited to, services between the period of 22nd June to August 14th:
* Builder systems - est by July 3rd
* Additional high availability capacity
* Staging environment - est by July 28th
* CommuniShift (in RDU-CC which was paused in May to allow for the
bringup of the reduced Fedora service) - est by July 28th
* Remainder of applications for Fedora, such as Nuancier, Fedocal, etc
- est by August 12th
For a full list of services that are impacted by this move, please see
previous hackmnd note https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA?view
### Additional Communications for Context
For additional context, Kevin Fenzi has sent mails last week on a
daily basis alerting the community on services as and when they are
being brought down.
Please see copy of emails sent here:
Day 1 https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr…
Day 2 https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr…
Day 3 & 4 https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr…
We also have a 'What this move means for you' email that went to
devel-announce(a)fedoraproject.org
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
### What can you do to help?
We would ask you to please be patient and be aware that at times PR,
build requests, and other build items may not work due to resource
limitations. Please open tickets when this happens as we may not be
able to get to it immediately or know the problem is occurring.
We also have a list of services that we are asking for help validating
once bringup is complete in IAD2, so if you are able to assist us,
please check this hackmd and reach out to Kevin Fenzi (nirik) and/or
Stephen Smoogen (smooge) for instruction as the validation process may
be different in the new datacentre
https://hackmd.io/op6N_nIaR7aMzw9Ib-sDAQ
Thank you for your patience and understanding during this crucial time
as we complete the final 9 weeks of this project!
Kind regards,
Batman, Robin and Alfred :)
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
https://fedoraproject.org/wiki/Changes/DefaultAnimatedBackground
== Summary ==
Fedora Workstation 33 uses animate background as default.
== Owner ==
* Name: [[User:luya| Luya Tshimbalanga]]
* Email: luyaATfedoraproject.org
* Product: Workstation
== Detailed Description ==
Starting from Release 33, Fedora Workstation uses default animated
background as a visual showcase. Spins and lab maintainers running on
desktop environment unable to support animated wallpaper will be able
to select a different frame from the default (and variant) background.
== Benefit to Fedora ==
Fedora Workstation will showcase its animated background seamlessly as default.
Does this improve specific Spins or Editions?
Design Suite Labs, which is based from Workstation, and
Fedora Silverblue will take advantage of its change. Other Spins and
Labs will remains unaffected unless their respective maintainers wish
to use the default animated background.
== Scope ==
* Proposal owners:
Fedora Workstation may need a slight increase of its ISO file size in
order to implement the animated backgrounds which are in PNG format.
Each frame from animation will be selectable from the Background
Settings.
* Other developers: N/A (not a System Wide Change)
* Release engineering: Possibly a slight increase of ISO file.
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
Users will notice an animation of the default background related to
the time of the day.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Revert to the default static background
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
N/A
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/ModularReposSubpackage
== Summary ==
Reintroduce the fedora-repos-modular package. Have the
<code>/etc/yum.repos.d/*-modular.repo</code> files in it instead of
fedora-repos.
We install/keep fedora-repos-modular by default, users (admins) can
uninstall it if desired. No defaults are changed.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok(a)redhat.com
== Detailed Description ==
As a Fedora user, who doesn't consume any modules, I'd like an easy
way to disable modular repos to save some traffic, disk space and
time.
Currently, I can do it by editing all
<code>/etc/yum.repos.d/*-modular.repo</code> files and changing:
enabled=1
To:
enabled=0
This has downsides: When the files are changed in next update, I won't
get them updated, because they are shipped as
<code>%config(noreplace)</code>. (If they were not shipped as
<code>%config(noreplace)</code>, it would be even worse, as my changes
would be overridden.) It's also multiple files. I can make mistakes
and break other files by accident.
In order to not to have to resort to manually editing RPM-package
shipped configuration, I propose to have a better way of disabling
modular repos, namely via: <code>sudo dnf remove
fedora-repos-modular</code>.
In this change, we move modular repos into a separate package
(subpackage of fedora-repos).
Basically revert this plus some extra comps/kickstarts changes:
https://src.fedoraproject.org/rpms/fedora-repos/c/7b32bee388d093c446017f1e3…
Current fedora-repos Pull Request:
https://src.fedoraproject.org/rpms/fedora-repos/pull-request/62
== Feedback ==
This was proposed in early May 2020 on the devel mailing list:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
The proposal received only positive feedback.
This was then opened as a pull request in:
https://src.fedoraproject.org/rpms/fedora-repos/pull-request/62
Where it received thorough review and positive feedback, until it was
blocked by an unrelated modularity discussion that slightly touched
this topic. FESCo sentiment was positive or neutral (however, one
FESCo member doubted the usefulness of this, saying it is pointless).
https://src.fedoraproject.org/rpms/fedora-repos/pull-request/62#comment-453…https://pagure.io/fesco/issue/2114#comment-654115 and below
Later, the spirit of this change was approved by FESCo in
https://pagure.io/fesco/issue/2406
== Why don't we...? ==
=== Why don't we have config overrides for system provided repo files? ===
It would be great if DNF supported system-repos in
<code>/usr/share</code> and override options in <code>/etc</code>, but
that is not (yet) the case. Feel free to work on this feature, but the
change owner won't.
=== Why don't we disable modular repos by default? ===
This would require much bigger and heated discussion. Let it happen
elsewhere. This self-contained change proposal maintains the status
quo and only creates a way for users to opt out form the modular
repos, when they so desire. It does not disable anything.
=== Why are you against ...? ===
This change is not against modularity, it is not against default
modular streams, it is not against the people who created modularity,
it is not against ELN, it is not against you. This change proposal
maintains the status quo by default and only creates a way for users
to opt out form the modular repos, when they so desire. The
maintenance burden of having one extra repo package is considered
insignificant compared to the benefit. This is not a death of a
thousands cuts proposal with a hidden agenda, this is a proposal that
adds a significant benefit.
== Benefit to Fedora ==
Users who don't consume modules have the ability to disable modular
repositories in a safe and supported way. This can save their traffic,
disk space and time.
Container maintainers can benefit form this change as well by
disabling modular repos first by a single command or not having it at
all from start, if they so desire.
Package maintainers can benefit from this change by not using modular
repos when repoquerying non-modular repos, if they so desire.
Mirror operators can benefit from this change by saving their traffic
if the users actually do disable the repos, while there is no downside
if they don't.
== Scope ==
* Proposal owners:
* Finish and merge https://pagure.io/fesco/issue/2114
* Ensure fedora-repos-modular are installed by default on Fedora 33
(fresh installs)
* Ensure fedora-repos-modular are installed by default on Fedora 33
(upgrades from previous releases)
* Other developers: no action required
* Release engineering: no action required (possibly building the
updated fedora-repos package if provenpackagers can't)
* Policies and guidelines: nada
* Trademark approval: zip
== Upgrade/compatibility impact ==
It is expected that users who upgrade from previous Fedora releases
will have fedora-repos-modular installed during the upgrade to Fedora
33 or 34.
It is expected that rawhide users who will have fedora-repos-modular
installed during regular packages upgrade.
If this is not the case, it should be treated like a bug.
== How To Test ==
Install Fedora 33 (any edition or flavor), check that modular repos
are still installed and enabled by default.
Update to Fedora 33 (from Fedora 31 or 32), check that modular repos
are still installed and enabled by default.
Check that you can remove the fedora-repos-modular package (e.g. via
<code>sudo dnf remove fedora-repos-modular</code>) and it removes the
modular repos.
Check that you can install the fedora-repos-modular package again
(e.g. via <code>sudo dnf install fedora-repos-modular</code>) and it
adds the modular repos, enabled.
== User Experience ==
Users can disable or enable modular repos by removing or installing
fedora-repos-modular. This is significantly better UX than editing
config files.
== Dependencies ==
No dependencies.
== Contingency Plan ==
* Contingency mechanism: If the outlined constraints are seriously
broken and beyond fixing, QA can decide to revert the change.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
Documentation shall be added about disabling/enabling the modular repos.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/LXQt_0.15.0
== Summary ==
Update LXQt to 0.15.0 or later in Fedora.
== Owner ==
* Name: [[User:Zsun|Zamir SUN]]
* Email: zsun#AT#fedoraproject.org
== Detailed Description ==
LXQt 0.15.0 just released with a bunch of bugfixes and enhancements.
It's always good to keep Fedora users running on most recent software.
Detailed LXQt release note is available
https://lxqt.github.io/release/2020/04/24/lxqt-0-15-0/ here].
== Benefit to Fedora ==
This change brings bug fixes and enhancements to LXQt in Fedora.
== Scope ==
* Proposal owners:
1. Update all the LXQt related packages in Fedora.
2. Make lxqt-l10n noarch
3. Fix comps and/or kickstart if needed.
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/9530 #9530]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== User Experience ==
Users shouldn't feel any difference rather than bug fixes and new features.
== Dependencies ==
The package libqtxdg is updated. Only Deepin related packages depends
on this. I am also part of the DeepinDE SIG and I've reminded our
packagers. So no risk here now.
== Contingency Plan ==
* Contingency mechanism: Not announcing the update.
* Contingency deadline: Fedora 33 Beta Freeze
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have
written yourself? Link to that material here so other interested
developers can get involved. -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/NSSDBMRemoval
== Summary ==
Network Security Services (NSS) historically supports 2 different
database backends, based on SQLite and dbm. Since Fedora 28, the
SQLite backend has been used by default and the dbm backend has been
deprecated ([[Changes/NSSDefaultFileFormatSql|NSS Default File Format
SQL]]). This Change is about removing the support for the dbm backend
entirely.
== Owner ==
* Name: [[User:ueno| Daiki Ueno]]
* Email: dueno(a)redhat.com
== Detailed Description ==
Applications that use the NSS library often use a database for storage
of keys, certificates and trust. NSS supports two different storage
formats, one is based on SQLite and another one is based on dbm files.
Today's default file format used by NSS, used when applications omit
the type parameter, is the SQLite file format, and the older dbm
format has been considered as deprecated since Fedora 28, because it
has several drawbacks such as lack of support for parallel access to
the storage.
As the default change was made 2 years ago, and NSS provides a
transparent migration mechanism from the dbm format to the SQLite
format, the suggestion is to completely disable the dbm backend.
== Benefit to Fedora ==
There are a few benefits:
* By disabling the dbm database, the size of the library binary will
be slightly smaller
* The NSS developers will be able to focus on the new file format
== Scope ==
* Proposal owners:
A build time environment variable (NSS_DISABLE_DBM) needs to be set.
* Other developers: N/A
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The impact should be limited, as long as the users always update from
the previous version. That would ensure the existing databases on the
system are properly migrated. Therefore, we propose this as a Self
Contained Change, rather than a System Wide Change.
In the discussion on the fedora-devel list, it was pointed that pesign
package embedded the dbm format database. It has now been resolved in
[https://bugzilla.redhat.com/show_bug.cgi?id=1827902 bug 1827902].
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No user visible changes.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Revert the shipped configuration
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
== Summary ==
All retired packages are obsoleted by `fedora-retired-packages`.
== Owner ==
* Name: [[User:msuchy| Miroslav Suchý]]
* Email: msuchy(a)redhat.com
== Detailed Description ==
Right now `fedora-obsoletes-package` retires packages which cause an
issue during an upgrade. We do nothing about all other retired
packages. Now imagine the following story (it already happened many
times):
We have package "foo". It is a leaf package. No one requires it. It
uses just basic libraries.
A user installs it during F32 lifetime.
Around F35 the upstream dies. Around F37 Fedora maintainer retires the
package (or orphan and it later become retired).
Because the package is a leaf package, it causes no pain during
upgrade F37->F38. Not even during upgrade to F39, F40, F41, F42. And
then during upgrade to F43 it suddenly causes a problem. But because
it is .fc37 everyone will hesitate to add it
fedora-obsolete-packages.fc43.
Additionally, during F38-F43, users may expect that their system is
fully updated and they have no security issues. But it is not true
about package "foo", which no one maintains. And users are not aware
of that because he does not follow fedora-devel mailing list.
Obviously.
What I propose is: As part of the retirement process we add the to
fedora-retired-packages:
Obsoletes: foo < %{latestversion+1}
And during upgrade from F37->F38 the package will be removed.
If the user wants to preserve the package (e.g., because it moved to
Copr), he simply uninstalls and protects the installation of
fedora-retired-packages. But that will be an informed decision.
The benefits are:
* we do not leave unmaintained packages on a user's machine.
* We make sure that archaic packages do not break upgrade between two
versions of Fedora.
== Feedback ==
After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5
discussion with fedora-obsolete-package maintainer] I filed this
Change proposal to include a wider audience.
See relevant [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
thread on devel mailing list].
== Benefit to Fedora ==
* We do not leave unmaintained packages on a user's machine.
* We make sure that archaic packages do not break upgrade between two
versions of Fedora.
== Scope ==
* Proposal owners:
Create package `fedora-retired-packages` as sub-package of
`fedora-obsolete-packages`
[https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532]
Edit https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsol…
guidelines with:
The retired package should be obsoleted by one of:
* fedora-obsoleted-packages - if the package can cause problem during
upgrade to next version of Fedora
* fedora-retired-packages - in all other cases
It is enough to open an issue on
https://src.fedoraproject.org/rpms/fedora-obsolete-packages
* Other developers:
No other work should be necessary.
* Release engineering:
This is optional. I may work with rel-eng to change
https://pagure.io/releng/blob/master/f/docs/source/sop_retire_orphaned_pack…
to automatically create PR for `fedora-obsolete-packages`
* Policies and guidelines: As stated above
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsol…
will need an update.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
During an upgrade, all retired packages will be automatically removed.
User may opt-out by:
<pre>
$ cat /etc/dnf/dnf.conf
[main]
...
exclude=fedora-retired-packages
</pre>
== How To Test ==
1. Upgrade to next version of Fedora.
2. Check all retired packages are removed.
== User Experience ==
- Packages that are no longer maintained are removed during a
distribution upgrade.
== Dependencies ==
This update has no dependencies on any other package.
== Contingency Plan ==
* Contingency mechanism: Drop `fedora-retired-package`. Or remove
`Obsoletes` from this sub-package.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
TBD
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
== Summary ==
<code>%cmake</code> macro will be adjusted (<code>-B</code> parameter)
to use separate build folder (already standardized
<code>%{_vpath_builddir}</code> macro). Additionally,
<code>%cmake_build</code>, <code>%cmake_install</code> and
<code>%ctest</code> macro will be created (and backported to the older
supported Fedora releases) to perform various operations that are
commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
etc.) way.
Packages that will stop building are trivial to fix and will be
adjusted either by maintainers or change owners.
== Owner ==
* Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
Esser]], [[User:ngompa|Neal Gompa]]
* Email: ignatenkobrain(a)fedoraproject.org, besser82(a)fedoraproject.org,
ngompa13(a)gmail.com
== Detailed Description ==
Historically, software builds had a singular build configuration and
required running the build within the project root. Nowadays, there
are many build modes and options that can be configured in projects,
different build settings (e.g. compiler flags) / types (release,
debug) that can be applied and different tools that can be used to
actually execute builds (compilers like gcc/clang, build job
schedulers like make/ninja, and so on). Thus, CMake upstream strongly
discourages users of doing in-source builds and recommends doing
out-of-source builds.
From <code>cmake.1</code>:
<pre>
To maintain a pristine source tree, perform an out-of-source build by
using a separate dedicated build tree. An in-source build in which the
build tree is placed in the same directory as the source tree is also
supported, but discouraged.
</pre>
The other part of the change is introduction of additional macros is
creation of set of macro that can build, install and run tests in a
backend-agnostic, vpath-aware (out-of-source, in-source) way.
=== Migration ===
==== <code>%cmake</code> + <code>%(make|ninja)_(build|install)</code> ====
There are multiple paths to complete the migration:
* Add <code>-C "%{_vpath_builddir}"</code> to the <code>%(make|ninja)_*</code>
* Replace <code>%(make|ninja)_build</code> and
<code>%(make|ninja)_install</code> with <code>%cmake_build</code> and
<code>%cmake_install</code> respectively
* Redefine vpath builddir <code>%global _vpath_builddir .</code> to
continue performing in-source builds (and optionally converting to the
<code>%cmake_*</code>)
Depending on the package, one of these options may be used to adapt to
this change.
==== <code>%cmake -B builddir</code> +
<code>%(make|ninja)_(build|install) -C builddir</code> ====
No changes are needed.
== Benefit to Fedora ==
* Follow CMake upstream recommendations when building packages
* Brings Fedora package builds more in-line with how upstream projects
expect them to be built
* Improve compatibility with other RPM distributions that already do this
* Support backend-agnostic way of building CMake projects
== Scope ==
* Proposal owners: Implement necessary macros, try to build packages
that <code>BuildRequires: cmake</code> in a side tag, analyze failures
and fix the relevant ones (introduced by this change).
* Other developers: While proposal owners will try to fix all affected
packages, there might be some cases where package is already FTBFS so
the fix can't be performed. Other package maintainers will have to fix
the issue themselves after they fix FTBFS.
* Release engineering: [https://pagure.io/releng/issue/9524 #9524]
* Policies and guidelines: CMake page will be adjusted to mention
newly created macros and the documentation about relevant VPATH macros
needs to be restructured a bit (they are already documented on the
Meson page, they need to be moved to the separate page and referenced
both from CMake and Meson page).
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Existing packages can (and most likely will) become FTBFS, but
proposal owners will fix as many Fedora packages as possible. However
fixing third-party packages is not possible and out of scope.
Third-party packagers will need to adapt based on the recommendations
noted in this Change.
== How To Test ==
# Grab the new cmake RPM from the Koji sidetag (TBC)
# Try to build package that uses <code>%cmake</code>,
<code>%cmake_build</code>, <code>%cmake_install</code> and
<code>%ctest</code> macro
== User Experience ==
The end-users (non-packagers) will not notice any changes.
== Dependencies ==
There are around 1100 RPMs in Fedora that depend on CMake at
build-time. All proposal owners are provenpackagers so they are able
to commit necessary fixes. No external dependencies.
== Contingency Plan ==
* Contingency mechanism: Proposal owners will adjust macros to not do
out-of-source builds by default, but will preserve newly created macro
(essentially to bring them to the targeted state of older supported
Fedora releases).
* Contingency deadline: Beta freeze.
* Blocks release? No
== Documentation ==
The only place that needs to be adjusted is packaging guidelines.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Greetings, all!
The elections for FESCo election for Fedora 32 have concluded, and the results
are shown below.
FESCo is electing 4 seats this time.
A total of 273 ballots were cast, meaning a candidate
could accumulate up to 2730 votes (273 * 10).
The results for the elections are as follows:
# votes | name
- --------+----------------------
1507 | Neal Gompa (ngompa)
1450 | Stephen Gallagher (sgallagh)
1372 | Igor Raits (ignatenkobrain)
1148 | Clément Verna (cverna)
- --------+----------------------
1124 | Justin Forbes (jforbes)
997 | Chris Murphy (chrismurphy)
937 | Petr Šabata (psabata)
904 | Frantisek Zatloukal (frantisekz)
755 | James Cassell (cyberpear)
730 | Michal Novotný (clime)
Congratulations to the winning candidates, and thank you all
candidates for running this elections!
For a full election rundown, see the Community Blog post:
https://communityblog.fedoraproject.org/fedora-32-elections-results/
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
The Fedora Packaging Committee has some open seats and is accepting
submissions from interested candidates to serve on the FPC.
The FPC would like to thank Orion Poplawski, and Jonathan Wakely for
their service.
This position involves not only reviewing Packaging Guideline drafts
submitted to the FPC for consideration, but also helping rewrite drafts
to resolve issues in a more acceptable fashion. Additionally, the FPC
reviews UID/GID soft static assignment.
Currently the FPC meets on IRC weekly, on Thursdays based around 12:00
east coast US time, for approximately an hour.
That can change slightly, but any new time would need to be good for
all the members (East Coast US and German TZs, at least).
FPC members serve for as long as they are willing, there are currently
no term limits. All decisions are voted on using a +1 (for), 0
(abstain), and -1 (against) mechanism, and all decisions must be
approved by a majority (+5). FPC Meetings do not happen if a quorum (5
members) is not present. Candidates who are interested should provide
the following details to the FPC for consideration, by emailing it
directly to me (james(a)fedoraproject.org).
The FPC will consider all candidates, but strongly prefers candidates
who have extensive experience packaging in Fedora. Due to the current
environment we will be accepting applications for the next _five_ weeks
(deadline Wednesday, 2018-06-24).
Name:
FAS Account:
Provenpackager? (Yes/No):
Main area of packaging interest/expertise:
Reason(s) for wanting to join the FPC:
Thanks in advance,
~James