Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • foxboron/rfcs
  • raffomania/rfcs
  • svenstaro/rfcs
  • lahwaacz/rfcs
  • xiretza/rfcs
  • dvzrv/rfcs
  • antiz/rfcs
  • ponies/rfcs
  • daandemeyer/rfcs
  • torxed/rfcs
  • heftig/rfcs
  • tpkessler/rfcs
  • anthraxx/rfcs
  • serebit/rfcs
  • billjessm/rfcs
  • ainola/rfcs
  • klausenbusk/rfcs
  • shibumi/rfcs
  • ffy00/rfcs
  • kgizdov/rfcs
  • archlinux/rfcs
21 results
Show changes
Commits on Source (90)
Hide whitespace changes
Inline Side-by-side
Showing
with 693 additions and 518 deletions
.gitignore 0 → 100644
View file @ a82796f0
/public/
/resources/
/.hugo_build.lock
.gitlab-ci.yml
View file @ a82796f0
......@@ -3,12 +3,65 @@
default:
image: "archlinux:latest"
variables:
GIT_SUBMODULE_STRATEGY: recursive
stages:
- lint
- build
- deploy
lint-markdownlint:
stage: lint
needs: []
before_script:
- pacman -Syu --needed --noconfirm make markdownlint
script:
- make lint-markdownlint
rstcheck:
lint-typos:
stage: lint
needs: []
before_script:
- pacman -Syu --needed --noconfirm make typos
script:
- make lint-typos
lint-vale:
stage: lint
needs: []
before_script:
- pacman -Syu --needed --noconfirm make vale
script:
- make lint-vale
build:
stage: build
needs: []
before_script:
- pacman -Syu --needed --noconfirm make hugo git
script:
- make build
artifacts:
paths:
- public
pages:
stage: deploy
needs:
- lint-markdownlint
- lint-typos
- lint-vale
- build
dependencies: []
tags:
- secure
before_script:
- pacman --noconfirm -Syu --needed make rstcheck
- pacman -Syu --needed --noconfirm make hugo git
script:
- make lint
- make build
artifacts:
paths:
- public
rules:
- if: $CI_PROJECT_PATH == "archlinux/rfcs" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
.gitmodules 0 → 100644
View file @ a82796f0
[submodule "themes/hugo-book"]
path = themes/hugo-book
url = https://github.com/alex-shpak/hugo-book.git
.mdl_style.rb 0 → 100644
View file @ a82796f0
all
exclude_rule 'MD013'
.mdlrc 0 → 100644
View file @ a82796f0
ignore_front_matter true
show_kramdown_warnings true
style '.mdl_style.rb'
.typos.toml 0 → 100644
View file @ a82796f0
[default]
extend-ignore-re = [
"`\\.rela\\.dyn`",
]
.vale.ini 0 → 100644
View file @ a82796f0
StylesPath = "."
Vocab = rfc
MinAlertLevel = suggestion
[*]
BasedOnStyles = Vale
LICENSE
View file @ a82796f0
......@@ -33,7 +33,7 @@ exhaustive, and do not form part of our licenses.
material not subject to the license. This includes other CC-
licensed material, or material used under an exception or
limitation to copyright. More considerations for licensors:
wiki.creativecommons.org/Considerations_for_licensors
wiki.creativecommons.org/Considerations_for_licensors
Considerations for the public: By using one of our public
licenses, a licensor grants the public permission to use the
......@@ -48,9 +48,9 @@ exhaustive, and do not form part of our licenses.
rights in the material. A licensor may make special requests,
such as asking that all changes be marked or described.
Although not required by our licenses, you are encouraged to
respect those requests where reasonable. More_considerations
for the public:
wiki.creativecommons.org/Considerations_for_licensees
respect those requests where reasonable. More considerations
for the public:
wiki.creativecommons.org/Considerations_for_licensees
=======================================================================
......@@ -303,8 +303,8 @@ apply to Your use of the Licensed Material:
contents in a database in which You have Sui Generis Database
Rights, then the database in which You have Sui Generis Database
Rights (but not its individual contents) is Adapted Material,
including for purposes of Section 3(b); and
c. You must comply with the conditions in Section 3(a) if You Share
all or a substantial portion of the contents of the database.
......
Makefile
View file @ a82796f0
DOC_FILES=$(wildcard rfcs/*.rst) $(wildcard *.rst)
FILES=*.md rfcs
all:
all: check build
devel-watchexec:
watchexec -e .scss -e .html -e .toml -e .rst -e .svg -e .png -e .md -e .txt -e .ini make
devel-http-server:
python -m http.server -d public
build:
hugo
check: lint
lint:
rstcheck --report-level warning $(DOC_FILES)
lint: lint-markdownlint lint-typos lint-vale
lint-markdownlint:
mdl $(FILES)
lint-typos:
typos $(FILES)
lint-vale:
vale $(FILES)
clean:
rm -rf public resources
README.md 0 → 100644
View file @ a82796f0
---
title: Arch Linux RFCs
---
# Request for Comment
A Request for Comment ([RFC](https://en.wikipedia.org/wiki/Request_for_Comments)) is a way for Arch Linux contributors to propose, design and discuss new features and changes in project direction in a focused environment.
RFCs start as merge requests in: <https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests>
Once accepted, they can be found in: <https://gitlab.archlinux.org/archlinux/rfcs/-/tree/master/rfcs>
## What does an RFC do
The RFC process is intended to bring focus and structure to discussions of important changes and new features in Arch Linux.
It provides a space for sharing and collaborating on ideas and design documents, keeping community discussion organized and focused on the goal of reaching a decision.
Visibility and inclusivity are important values for RFCs.
They are advertised to both staff and user communication channels so everyone can participate.
An RFC is only a design document, and not a single line of code needs to be written for the discussion to be approved, although prototyping can be a good idea.
An approved RFC has no timeline for when it needs to be implemented.
## Who can file an RFC
Anyone can file an RFC.
However, the following restriction exists for contributors, that are not part of the Arch Linux Developer or Package Maintainer teams:
At least one Developer or Package Maintainer has to support the RFC and must be willing to work on it in a joint effort with the contributor.
## When should I file an RFC
If you have an idea for something and are unsure if it needs an RFC, the best way to find out is to just ask (e.g. by [opening an issue in this repository](https://gitlab.archlinux.org/archlinux/rfcs/-/issues/new) and filling out the \"idea\" template).
An RFC is much more likely to succeed if it begins life as a discussion, and collaborators are encouraged to start off by talking to other project members before submitting an RFC.
This can also help gauge early support for the feature and work out any obvious issues or design decisions.
RFCs are used for proposing \"substantial\" changes.
The meaning of \"substantial\" is subjective, but a good start would be anything that benefits from design discussion.
Put a different way, it is recommended to file an RFC if the design or implementation is not immediately clear, or if there are drawbacks or potential consequences that require discussion first.
These might be worth consideration for an RFC:
- New features
- Breaking changes
- Organizational changes, including changes to the RFC process itself
## Proposing an RFC
### Step 0: Decide if you should file an RFC
As an RFC author, it is best if you only have one RFC of yours open at any moment.
This restriction is a guideline, but you are advised to be respectful of other contributors who would also like their RFCs to receive attention, and to be cognizant of the potential cost of spreading the community\'s attention thinly across a multitude of proposals.
> ::: note
> ::: title
> Note
> :::
>
> To view previous or current ideas, have a look at the
> [issues](https://gitlab.archlinux.org/archlinux/rfcs/-/issues).
> :::
### Step 1: Fork this repository
Fork this repository if you have not already.
### Step 2: Write RFC
Copy [`rfcs/0000-template.md`](/rfcs/0000-template.md) as a template while using an appropriate title related to the proposed topic and begin working on the RFC.
Please put a lot of thought into your writing.
A great RFC explains and justifies its motivations and carefully considers all drawbacks and alternatives.
Show the reader what the problems are and how the proposal concretely and practically addresses them.
### Step 3: File merge request
Create a merge request toward <https://gitlab.archlinux.org/archlinux/rfcs>.
The open merge request itself **is** the RFC.
Discussion of the RFC is held in the comments of the merge request.
> ::: note
> ::: title
> Note
> :::
>
> When creating the merge request, make sure to tick the **Allow commits
> from members who can merge to the target branch.** checkbox in the
> **Contribution** section.
> :::
After the merge request is created, the merge request number (e.g. 42) is your RFC number.
Then do the following:
1. In the branch, rename the file from `rfcs/0000-\<my-proposal-title\>.md` to `rfcs/0042-\<my-proposal-title\>.md`.
This makes all the proposals show up in ascending chronological order when someone visits the [RFCs](/rfcs/) directory.
1. In the file itself, there is a bullet point labeled **RFC MR:**.
Update this so that it links to the merge request.
This ensures that the discussion is immediately accessible from the RFC text.
These are minor housekeeping steps that keep the RFC a nice, tidy, and easily navigable archive.
If you make a mistake in this process, it is no huge issue -someone else can fix it for you.
### Step 4: Announce
After the RFC is ready to go, please announce it to [arch-dev-public](https://lists.archlinux.org/hyperkitty/list/arch-dev-public@lists.archlinux.org/).
> ::: note
> ::: title
> Note
> :::
>
> If you lack the permission to send mail to the mailing list yourself,
> the person from the Developer or Package Maintainer team, that is
> supporting your RFC, will do it for you.
> :::
Here is a template:
``` email
Subject: RFC: Deprecate BadFeature
A new RFC (request for comment) has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/42
Please visit the above link for discussion.
Summary: <insert the summary section from your RFC here>
```
## Discussing an RFC
Discussion about the RFC should happen on the RFC merge request on Arch Linux\'s GitLab.
If discussions happen outside the GitLab thread, it is best to link and summarize them in the RFC thread to make the conversations easier to track.
The RFC will likely undergo numerous revisions in the discussion process.
While discussing an RFC, it is everyone\'s responsibility to work towards **reaching a conclusion**.
When you make a post to the RFC thread, focus on the contents and implications of the RFC only.
Here are some guidelines:
- **Think about these important questions:**
- Do you agree with the proposal in its current form?
- Are concerns and questions adequately addressed?
- Do you have suggestions for how the RFC can be revised or expanded, especially in the Unresolved Questions section?
- **Do not be shy:** Even if you are not an active Arch Linux contributor, or if you do not feel \"qualified\" to discuss the topic, please feel free to directly state your opinion on an RFC, especially if it affects you in some way.
- **Stay on topic:** Starting or continuing tangential or off-topic discussions is disrespectful to the RFC author and is strongly discouraged.
Such discussions often dilute the thread and make it hard to identify what the community\'s decision should be.
The purpose of the RFC thread is to reach a conclusion, and any commentary that does not contribute to that is damaging to the RFC process.
- **Civility and respect:** Like all other discussions that happen in the Arch Linux community, RFC discussions are governed by our [Code of Conduct](https://terms.archlinux.org/docs/code-of-conduct/).
Creating an RFC is a laborious project.
Commenting on an RFC should be done with respect and empathy for the hard work that the author has put into it.
- **Avoid scope creep:** You should make suggestions on how the RFC can be revised or expanded, but be careful not to expand it too much and develop it into something far more ambitious than was originally intended.
## Finalizing an RFC
When the RFC seems ready to conclude, all staff members may make a motion for a Final Comment Period.
The Final Comment Period lasts 14 days, and has a *disposition* to either **pass** or **reject**.
To make a motion for a Final Comment Period, leave a comment on the merge request thread or use GitLab\'s approval functionality (for a positive affirmation).
The Final Comment Period should also be announced on [arch-dev-public](https://lists.archlinux.org/hyperkitty/list/arch-dev-public@lists.archlinux.org/).
Here is a template:
``` email
Subject: RFC Final Comment Period: Deprecate BadFeature
An RFC has now entered Final Comment Period. In 14 days, discussion will end
and the proposal will either be accepted, rejected or withdrawn:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/42
Please visit the above link for discussion.
Summary: <insert the summary section from your RFC here>
```
When should the Final Comment Period start? There does not need to be a consensus with everyone involved (which is usually impossible), but the RFC should be in a state where the author feels that the writing effort is complete, the arguments have been clearly articulated, discussions are resolved and drawbacks acknowledged in the RFC\'s text, and there is not a strong consensus *against* the proposal.
Sometimes, RFCs can reach points of disagreement where no clear consensus is in sight.
Unfortunately, there is no way that this RFC process can solve such issues, and these have to be handled on a case-by-case basis.
If no important developments occur during this time frame, someone with write access merges (for passed RFCs) or closes (for rejected RFCs) the RFC PR.
At any point, the RFC author can also choose to **withdraw** an RFC, with no 14-day grace period necessary.
Implementation of an RFC can start before, during, or after it has been approved.
In fact, if you propose an RFC, you do not need to be the person to implement it, but usually the implementer is the same person as the RFC author.
## About the RFC process
This is not a legal document, and you should not spend a lot of time analyzing its wording.
This process is intentionally quite informal and subjective.
Situations will come up that may not have been anticipated by this article, and they should be handled on a case-by-case basis.
If something is ambiguous in this article, that means it is left up to discussion.
If something is a persistent cause of confusion, then it may be wise to amend the RFC process itself for clarification.
## License
All contributions are licensed by their respective authors under the terms of the [CC-BY-SA 4.0 License](https://creativecommons.org/licenses/by-sa/4.0/legalcode).
README.rst deleted 100644 → 0
View file @ d499df13
===============
Arch Linux RFCs
===============
A Request for Comment (`RFC
<https://en.wikipedia.org/wiki/Request_for_Comments>`_) is a way for Arch Linux
contributors to propose, design and discuss new features and changes in
project direction in a focused environment.
RFCs start as merge requests in:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests
Once accepted, they can be found in:
https://gitlab.archlinux.org/archlinux/rfcs/-/tree/master/rfcs
What does an RFC do?
--------------------
The RFC process is intended to bring focus and structure to discussions of
important changes and new features in Arch Linux. It provides a space for
sharing and collaborating on ideas and design documents, keeping community
discussion organized and focused on the goal of reaching a decision.
Visibility and inclusivity are important values for RFCs. They are advertised
to both staff and user communication channels so everyone can participate.
An RFC is only a design document, and not a single line of code needs to be
written for the discussion to be approved, although prototyping can be a good
idea. An approved RFC has no timeline for when it needs to be implemented.
Who can file an RFC?
--------------------
Anyone can file an RFC. However, the following restriction exists for
contributors, that are not part of the Arch Linux Developer or Trusted User
teams:
At least one Developer or Trusted User has to support the RFC and must be
willing to work on it in a joint effort with the contributor.
When should I file an RFC?
--------------------------
If you have an idea for something and are unsure if it needs an RFC, the best
way to find out is to just ask (e.g. by `opening an issue in this repository
<https://gitlab.archlinux.org/archlinux/rfcs/-/issues/new>`_ and filling out
the "idea" template).
An RFC is much more likely to succeed if it begins life as a discussion, and
collaborators are encouraged to start off by talking to other project members
before submitting an RFC. This can also help gauge early support for the
feature and work out any obvious issues or design decisions.
RFCs are used for proposing "substantial" changes. The meaning of "substantial"
is subjective, but a good start would be anything that benefits from design
discussion. Put a different way, it is recommended to file an RFC if the design
or implementation is not immediately clear, or if there are drawbacks or
potential consequences that require discussion first. These might be worth
consideration for an RFC:
- New features
- Breaking changes
- Organizational changes, including changes to the RFC process itself
Proposing an RFC
----------------
Step 0: Decide if you should file an RFC
________________________________________
As an RFC author, it is best if you only have one RFC of yours open at any
moment. This restriction is a guideline, but you are advised to be respectful
of other contributors who would also like their RFCs to receive attention, and
to be cognizant of the potential cost of spreading the community's attention
thinly across a multitude of proposals.
.. note::
To view previous or current ideas, have a look at the `issues
<https://gitlab.archlinux.org/archlinux/rfcs/-/issues>`_.
Step 1: Fork this repository
____________________________
Fork this repository if you have not already.
Step 2: Write RFC
_________________
Copy **rfcs/0000-template.rst** to **rfcs/0000-<my-proposal-title>.rst** and begin
working on the RFC.
Please put a lot of thought into your writing. A great RFC explains and
justifies its motivations and carefully considers all drawbacks and
alternatives. Show the reader what the problems are and how the proposal
concretely and practically addresses them.
Step 3: File merge request
__________________________
Create a merge request toward https://gitlab.archlinux.org/archlinux/rfcs. The
open merge request itself **is** the RFC. Discussion of the RFC is held in the
comments of the merge request.
.. note::
When creating the merge request, make sure to tick the **Allow commits from
members who can merge to the target branch.** checkbox in the
**Contribution** section.
After the merge request is created, the merge request number (e.g. 42) is your RFC
number. Then do the following:
1. In the branch, rename the file from **rfcs/0000-<my-proposal-title>.rst** to
**rfcs/0042-<my-proposal-title>.rst**. This makes all the proposals show up
in ascending chronological order when someone visits the `rfcs <rfcs/>`_
directory.
2. In the file itself, there is a bullet point labeled **RFC MR:**. Update this
so that it links to the merge request. This ensures that the discussion is
immediately accessible from the RFC text.
These are minor housekeeping steps that keep the RFC a nice, tidy, and easily
navigable archive. If you make a mistake in this process, it is no huge issue -
someone else can fix it for you.
Step 4: Announce
________________
After the RFC is ready to go, please announce it to `arch-dev-public
<https://lists.archlinux.org/listinfo/arch-dev-public>`_.
.. note::
If you lack the permission to send mail to the mailing list yourself, the
person from the Developer or Trusted User team, that is supporting your
RFC, will do it for you.
Here is a template:
.. code::
Subject: RFC: Deprecate BadFeature
A new RFC (request for comment) has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/42
Please visit the above link for discussion.
Summary: <insert the summary section from your RFC here>
Discussing an RFC
-----------------
Discussion about the RFC should happen on the RFC merge request on Arch Linux's
GitLab. If discussions happen outside the GitLab thread, it is best to link and
summarize them in the RFC thread to make the conversations easier to track.
The RFC will likely undergo numerous revisions in the discussion process.
While discussing an RFC, it is everyone's responsibility to work towards
**reaching a conclusion**. When you make a post to the RFC thread, focus on the
contents and implications of the RFC only.
Here are some guidelines:
- **Think about these important questions:**
- Do you agree with the proposal in its current form?
- Are concerns and questions adequately addressed?
- Do you have suggestions for how the RFC can be revised or expanded,
especially in the Unresolved Questions section?
- **Do not be shy:** Even if you are not an active Arch Linux contributor, or
if you do not feel "qualified" to discuss the topic, please feel free to
directly state your opinion on an RFC, especially if it affects you in some
way.
- **Stay on topic:** Starting or continuing tangential or off-topic discussions
is disrespectful to the RFC author and is strongly discouraged. Such
discussions often dilute the thread and make it hard to identify what the
community's decision should be. The purpose of the RFC thread is to reach a
conclusion, and any commentary that does not contribute to that is damaging
to the RFC process.
- **Civility and respect:** Like all other discussions that happen in the Arch
Linux community, RFC discussions are governed by our `Code of Conduct
<https://terms.archlinux.org/docs/code-of-conduct/>`_.
Creating an RFC is a laborious project. Commenting on an RFC should be done
with respect and empathy for the hard work that the author has put into it.
- **Avoid scope creep:** You should make suggestions on how the RFC can be
revised or expanded, but be careful not to expand it too much and develop it
into something far more ambitious than was originally intended.
Finalizing an RFC
-----------------
When the RFC seems ready to conclude, all staff members may make a motion for a
Final Comment Period. The Final Comment Period lasts 14 days, and has a
*disposition* to either **pass** or **reject**.
To make a motion for a Final Comment Period, leave a comment on the merge
request thread or use GitLab's approval functionality (for a positive
affirmation). The Final Comment Period should also be announced on
`arch-dev-public <https://lists.archlinux.org/listinfo/arch-dev-public>`_.
Here is a template:
.. code::
Subject: RFC Final Comment Period: Deprecate BadFeature
An RFC has now entered Final Comment Period. In 14 days, discussion will end
and the proposal will either be accepted, rejected or withdrawn:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/42
Please visit the above link for discussion.
Summary: <insert the summary section from your RFC here>
When should the Final Comment Period start? There does not need to be a
consensus with everyone involved (which is usually impossible), but the RFC
should be in a state where the author feels that the writing effort is
complete, the arguments have been clearly articulated, discussions are resolved
and drawbacks acknowledged in the RFC's text, and there is not a strong
consensus *against* the proposal.
Sometimes, RFCs can reach points of disagreement where no clear consensus is in
sight. Unfortunately, there is no way that this RFC process can solve such
issues, and these have to be handled on a case-by-case basis.
If no important developments occur during this time frame, someone with write
access merges (for passed RFCs) or closes (for rejected RFCs) the RFC PR.
At any point, the RFC author can also choose to **withdraw** an RFC, with no
14-day grace period necessary.
Implementation of an RFC can start before, during, or after it has been
approved. In fact, if you propose an RFC, you do not need to be the person to
implement it, but usually the implementer is the same person as the RFC author.
About the RFC process
---------------------
This is not a legal document, and you should not spend a lot of time analyzing
its wording. This process is intentionally quite informal and subjective.
Situations will come up that may not have been anticipated by this article, and
they should be handled on a case-by-case basis.
If something is ambiguous in this article, that means it is left up to
discussion. If something is a persistent cause of confusion, then it may be
wise to amend the RFC process itself for clarification.
License
-------
All contributions are licensed by their respective authors under the terms of
the `CC-BY-SA 4.0 License
<https://creativecommons.org/licenses/by-sa/4.0/legalcode>`_.
archetypes/default.md 0 → 100644
View file @ a82796f0
---
title: "{{ replace .Name "-" " " | title }}"
date: {{ .Date }}
draft: true
---
config.toml 0 → 100644
View file @ a82796f0
baseURL = 'https://rfc.archlinux.page'
contentDir = 'rfcs'
languageCode = 'en-us'
title = 'Arch Linux RFCs'
theme = 'hugo-book'
enableGitInfo = true
pluralizeListTitles = false
[params]
BookSearch = false
BookComments = false
BookSection = '*'
BookRepo = 'https://gitlab.archlinux.org/archlinux/rfcs'
BookCommitPath = 'commit'
[security]
[security.exec]
allow = ['^git$']
config/vocabularies/rfc/accept.txt 0 → 100644
View file @ a82796f0
[Mm]irrorlist[s]?
PKGBUILD[s]?
userspace
kernelspace
namespace(|d|s)
CPUs
rebase
[Rr]ebasing
profiler[s]?
tracepoint[s]?
testcase[s]?
bootloader
relocation[s]?
keyserver
debuginfo
stacktrace[s]?
callstack[s]?
backtrace[s]?
inlin(e|ed|ing)
buildflag[s]?
microarchitecture[s]?
bitness
distro
config
virtualize[d]?
charset[s]?
onboarded
inclusivity
undermaintained
recognizability
intransparent
unoptimized
[Uu]pstream[s]?
deduplicate
ruleset[s]?
repo[s]?
unwinder
DevOps
toolchain
relicensing
rfcs/0000-template.rst → rfcs/0000-template.md
View file @ a82796f0
=====
Title
=====
---
draft: true
title: 0000 Template
---
# Title
- Date proposed: yyyy-mm-dd
- RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0000
- RFC MR: <https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0000>
**update this number after RFC merge request has been filed**
Summary
-------
## Summary
Short description, 1-2 sentences.
Motivation
----------
## Motivation
Introduce the topic. If this is a not-well-known section of Arch Linux, a
detailed explanation of the background is recommended.
Introduce the topic.
If this is a not-well-known section of Arch Linux, a detailed explanation of the background is recommended.
Some example points of discussion:
- What specific problems are you facing right now that you're trying to address?
- Are there any previous discussions? Link to them and summarize them (don't
force your readers to read them though!).
- Are there any previous discussions? Link to them and summarize them (don't force your readers to read them though!).
- Is there any precedent set by other software? If so, link to resources.
Specification
-------------
## Specification
A concrete, thorough explanation of what is being planned.
Drawbacks
---------
## Drawbacks
Carefully consider every possible objection and issue with your proposal. This
section should be updated as feedback comes in from discussion.
Carefully consider every possible objection and issue with your proposal.
This section should be updated as feedback comes in from discussion.
Unresolved Questions
--------------------
## Unresolved Questions
Are there any portions of your proposal which need to be discussed with the
community before the RFC can proceed? Be careful here -- an RFC with a lot of
remaining questions is likely to be stalled. If your RFC is mostly unresolved
questions and not too much substance, it may not be ready.
Are there any portions of your proposal which need to be discussed with the community before the RFC can proceed? Be careful here, an RFC with a lot of remaining questions is likely to be stalled.
If your RFC is mostly unresolved questions and not too much substance, it may not be ready.
Alternatives Considered
-----------------------
## Alternatives Considered
A list of alternatives, that have been considered and offer equal or similar
features to the proposed change.
A list of alternatives, that have been considered and offer equal or similar features to the proposed change.
rfcs/0001-using-rfcs.md 0 → 100644
View file @ a82796f0
---
title: 0001 Using RFCs
---
# Using RFCs
- Date proposed: 2021-02-03
- RFC MR: <https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/1>
## Summary
A Request for Comment (RFC) is a way for Arch Linux contributors to propose, design, and discuss new features and changes in project direction in a focused environment.
## Motivation
Finding consensus on overarching or more involved topics in Arch Linux has historically been driven by discussions on mailing lists, in the distribution's various IRC channels, the wiki and the forums.
While under certain circumstances this process is still valid and does work, it has a tendency to lead to unfocused and inconclusive discussions while lacking a transparent process.
In addition, the results of decision-making are often oblique to newcomers, as they may only exist in the logs of chats or mailing lists, that are not accessible to everyone.
When considering the different entities (project leader, developers, trusted users, support staff) that Arch Linux consists of, it becomes apparent that distribution-wide topics do not have a platform, as the specific entities have specialized (access-restricted) communication channels and concern themselves (sometimes exclusively) with a specialized topic.
With the wiki article [Governance And Decision Making](https://wiki.archlinux.org/index.php/DeveloperWiki:Governance_And_Decision_Making), an attempt has been made to outline the existing decision making processes and put them into context with one another.
The RFC process is meant to guide and transform the distribution as a whole, in contrast to the various specialized entities (project leader, developers, trusted users, support staff) and their respective communication channels.
To increase transparency, source and value the knowledge and inspiration of the entire community, an RFC based process can be used to achieve a more focused workflow for discussing overarching topics and reaching a conclusion for the entire distribution, while archiving discussion and consensus in a standardized form.
## Specification
The [GitLab repository](https://gitlab.archlinux.org/archlinux/rfcs) is used to explain how to create, discuss, finalize and to host the accepted and rejected RFCs.
A RFC is filed by creating a merge request toward the repository.
Anyone is able to create an RFC.
However, contributors outside of the Arch Linux Developer or Trusted User teams are only allowed to create an RFC, if at least one Developer or Trusted User supports the effort and helps develop it.
New RFC proposals are announced on the [arch-dev-public](https://lists.archlinux.org/listinfo/arch-dev-public) mailing list and are open for discussion and contribution in the merge request until finalized.
Once finalized, the RFC is entering its final comment period, which is again announced on the [arch-dev-public](https://lists.archlinux.org/listinfo/arch-dev-public) mailing list and lasts for 14 days.
The final comment period is used to gather the motion of all participants (again as part of the merge request) to either lead to a passed (by merging the merge request) or rejected (by rejecting the merge request) RFC.
Participants can either use GitLab's approval feature to approve of the RFC, or leave a comment for a more nuanced motion.
The described process allows developers, trusted users, support staff and users alike to write an RFC and propose a change in direction for the distribution.
Ideas for RFCs may be proposed and discussed by creating a [new issue using the idea template](https://gitlab.archlinux.org/archlinux/rfcs/-/issues/new?issuable_template=idea).
Existing ideas for RFCs can be found by browsing the [issues](https://gitlab.archlinux.org/archlinux/rfcs/-/issues).
## Drawbacks
The RFC workflow breaks with the old way of reaching consensus and might be perceived as bureaucratic.
## Unresolved Questions
None.
## Alternatives Considered
### Mailing lists
The existing mailing list infrastructure has been used to reach consensus on various topics over the years.
However, finding the reached consensus in a comprehensible format is not easy and depending on topic can be hidden on an access restricted mailing list.
### IRC channels
The existing staff related IRC channels on freenode.net are frequently used to reach consensus on minor topics, which then usually find their way into e-mails or other announcements.
However, not all staff is present on IRC (at all times of the day), so it is easy to miss discussions or any reached consensus in this medium, if it is not propagated publicly elsewhere.
rfcs/0001-using-rfcs.rst deleted 100644 → 0
View file @ d499df13
==========
Using RFCs
==========
- Date proposed: 2021-02-03
- RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/1
Summary
-------
A Request for Comment (RFC) is a way for Arch Linux contributors to propose,
design, and discuss new features and changes in project direction in a focused
environment.
Motivation
----------
Finding consensus on overarching or more involved topics in Arch Linux has
historically been driven by discussions on mailing lists, in the distribution's
various IRC channels, the wiki and the forums.
While under certain circumstances this process is still valid and does work, it
has a tendency to lead to unfocused and inconclusive discussions while lacking
a transparent process.
In addition, the results of decision-making are often oblique to newcomers, as
they may only exist in the logs of chats or mailing lists, that are not
accessible to everyone.
When considering the different entities (project leader, developers, trusted
users, support staff) that Arch Linux consists of, it becomes apparent that
distribution-wide topics do not have a platform, as the specific entities have
specialized (access-restricted) communication channels and concern themselves
(sometimes exclusively) with a specialized topic.
With the wiki article `Governance And Decision Making
<https://wiki.archlinux.org/index.php/DeveloperWiki:Governance_And_Decision_Making>`_,
an attempt has been made to outline the existing decision making processes and
put them into context with one another.
The RFC process is meant to guide and transform the distribution as a whole,
in contrast to the various specialized entities (project leader, developers,
trusted users, support staff) and their respective communication channels.
To increase transparency, source and value the knowledge and inspiration of the
entire community, an RFC based process can be used to achieve a more focused
workflow for discussing overarching topics and reaching a conclusion for the
entire distribution, while archiving discussion and consensus in a standardized
form.
Specification
-------------
The repository https://gitlab.archlinux.org/archlinux/rfcs is used to explain
how to create, discuss, finalize and to host the accepted and rejected RFCs.
An RFC is filed by creating a merge request toward the repository.
Anyone is able to create an RFC. However, contributors outside of the Arch
Linux Developer or Trusted User teams are only allowed to create an RFC, if at
least one Developer or Trusted User supports the effort and helps develop it.
New RFC proposals are announced on the `arch-dev-public
<https://lists.archlinux.org/listinfo/arch-dev-public>`_ mailing list and are
open for discussion and contribution in the merge request until finalized.
Once finalized, the RFC is entering its final comment period, which is again
announced on the `arch-dev-public
<https://lists.archlinux.org/listinfo/arch-dev-public>`_ mailing list and lasts
for 14 days. The final comment period is used to gather the motion of all
participants (again as part of the merge request) to either lead to a passed
(by merging the merge request) or rejected (by rejecting the merge request)
RFC. Participants can either use GitLab's approval feature to approve of the
RFC, or leave a comment for a more nuanced motion.
The described process allows developers, trusted users, support staff and users
alike to write an RFC and propose a change in direction for the distribution.
Ideas for RFCs may be proposed and discussed by creating a new `issue
<https://gitlab.archlinux.org/archlinux/rfcs/-/issues/new>`_ using the "idea"
template. Existing ideas for RFCs can be found by browsing the `issues
<https://gitlab.archlinux.org/archlinux/rfcs/-/issues>`_.
Drawbacks
---------
The RFC workflow breaks with the old way of reaching consensus and might be
perceived as bureaucratic.
Unresolved Questions
--------------------
None.
Alternatives Considered
-----------------------
- Mailing lists: The existing mailing list infrastructure has been used to
reach consensus on various topics over the years. However, finding the
reached consensus in a comprehensible format is not easy and depending on
topic can be hidden on an access restricted mailing list.
- IRC channels: The existing staff related IRC channels on freenode.net are
frequently used to reach consensus on minor topics, which then usually find
their way into e-mails or other announcements. However, not all staff is
present on IRC (at all times of the day), so it is easy to miss discussions
or any reached consensus in this medium, if it is not propagated publicly
elsewhere.
rfcs/0002-march.rst deleted 100644 → 0
View file @ d499df13
================================================
Provide a x86-64-v3 microarchitecture level port
================================================
- Date proposed: 2020-03-02
- RFC MR: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0002
Summary
-------
Provide a second Arch Linux port using -march=x86-64-v3 in the build flags.
Motivation
----------
Arch used to pride itself in providing optimised binaries out of the box.
However, the days where our i686 showed improvements over other
distributions are long behind us.
Recently, AMD, Intel, Red Hat, and SUSE collaborated to define three
x86-64 microarchitecture levels on top of the x86-64 baseline. The three
microarchitectures group together CPU features roughly based on hardware
release dates.
The first of these microarchitecture levels, x86-64-v2, assumes the
following on top of base level x86_64 instructions:
``CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3``.
This basically raises the processor feature level requirement to around
Intel Nehalem, and supports any x86_64 processor made in the last decade.
The x86-64-v3 microarchitecture requires the following instruction sets:
``AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE``.
That is close to a Haswell processor, but does exclude some recent low
end Intel CPU that removed AVX support.
Finally, x86-64-v4 requires:
``AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL``
These microarchitecture became available in GCC version 11 (unreleased)
and LLVM version 12 (unreleased), and are supported in glibc-2.33 and
binutils-2.36.
You can see what architecture is support by your CPU by running:
``/lib/ld-linux-x86-64.so.2 --help``
::
Subdirectories of glibc-hwcaps directories, in priority order:
x86-64-v4
x86-64-v3 (supported, searched)
x86-64-v2 (supported, searched)
RHEL9 will use use x86-64-v2 as its baseline.
This RFC is proposing adding an x86_64_v3 port in Arch Linux. Assuming
SSE4 and AVX2 (and others) while compiling will provide greater
out-of-the-box performance in Arch Linux. There are also implications
in terms of battery life for laptop users.
Benchmarks
----------
It is difficult to benchmark an entire system, and workloads that benefit
most often have CPU detection inbuilt and use optimised paths. Also, the
relevant GCC and LLVM releases are not yet available. To make some tests
equivalent to x86-64-v3 using current GCC and LLVM, we can compile
packages using:
::
CFLAGS="$CFLAGS -mcx16 -msahf -mpopcnt -msse3 -msse4.1 -msse4.2 -mssse3 \
-mavx -mavx2 -mbmi -mbmi2 -mf16c -mfma -mlzcnt -mmovbe -mxsave"
CXXFLAGS="$CFLAGS"
Some benchmarks performed rebuilding packages with and without the above
CFLAGS additions against repositories from 2021-03-12:
**firefox-86.0.1-1**: benchmarking on Basemark Web 3.0
(https://web.basemark.com/) seven times (alternativing installs) gave a
median score of 514.68 for v1 and 565.42 for v3, representing a 9.9%
improvement. Note, this was rebuilding only firefox itself, and none of
its dependencies, thus representing a lower bound.
**openssl-1.1.1.j-1**: benchmarking using ``openssl speed rsa`` showed
improvements in the range of 3.4% to 5.1% for signing and verifying with
keys of different sizes.
Benchmarks posted on the arch-general mailing list [1] show a median
performance benefit of *-march=haswell* (roughly x86_64-v3) of around 10%.
[1] https://lists.archlinux.org/pipermail/arch-general/2021-March/048739.html
Specification
-------------
We will provide a second port where the distributed makepkg.conf
includes the following:
::
CARCH="x86_64_v3"
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=x86-64-v3 -mtune=generic ...
CXXFLAGS="$CFLAGS"
Alternatives Considered
-----------------------
Moving the baseline to x86-64-v2 was discussed, but the gains were not
considered enough to justify removal of support for hardware without
SSE4.2.
Providing all four architectures would require a lot of resources in
terms of build time, and mirror space. Providing x86-64 and x86-64-v3
only is a trade-off in gaining support for more optimised binary support
for new hardware (while not requiring the absolute latest) and additional
build time and storage associated with providing multiple architectures.
Drawbacks
---------
Providing a second architecture would increase our repo size by
approximately 66% (~32GB).
Building two architectures will take additional packager time unless
automated.
Some developers may not have hardware to debug issues found purely in
x86-64-v3 packages. It is likely these issues are very rare.
Unresolved Questions
--------------------
When "Architecture = auto" is set in pacman.conf, pacman will use
uname to detect the architecture. As this "port" is more of an
optimised rebuild rather than a architecture change, uname will report
x86_64. We could patch pacman to use x86_64_v3 instead, but that may
not be the correct solution.
It would be preferable if pacman on x86_64_v3 could still install
packages from x86_64, particularly for non-Arch repositories that
may not want to build for both architectures. This would also allow a
transition into x86_64_v3 when firstly [core] gets rebuilt, followed
by other repos one at a time. Your friendly pacman developers may be
willing to add the ability to specify multiple architectures in
pacman.conf.
rfcs/0002-x86-64-v3-microarchitecture.md 0 → 100644
View file @ a82796f0
---
title: 0002 Provide a x86-64-v3 microarchitecture level port
---
# Provide a x86-64-v3 microarchitecture level port
- Date proposed: 2020-03-02
- RFC MR: <https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0002>
## Summary
Provide a second Arch Linux port using `-march=x86-64-v3` in the build flags.
## Motivation
Arch used to pride itself in providing optimised binaries out of the box.
However, the days where our `i686` showed improvements over other distributions are long behind us.
Recently, AMD, Intel, Red Hat, and SUSE collaborated to define three `x86-64` microarchitecture levels on top of the `x86-64` baseline.
The three microarchitectures group together CPU features roughly based on hardware release dates.
The first of these microarchitecture levels, `x86-64-v2`, assumes the following on top of base level `x86_64` instructions:
`CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3`.
This basically raises the processor feature level requirement to around Intel `Nehalem`, and supports any `x86_64` processor made in the last decade.
The `x86-64-v3` microarchitecture requires the following instruction sets:
`AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE`.
That is close to a `Haswell` processor, but does exclude some recent low end Intel CPU that removed AVX support.
Finally, `x86-64-v4` requires:
`AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL`
These microarchitecture became available in GCC version 11 (unreleased) and LLVM version 12 (unreleased), and are supported in glibc-2.33 and binutils-2.36.
You can see what architecture is supported by your CPU by running:
```text
/lib/ld-linux-x86-64.so.2 --help
Subdirectories of glibc-hwcaps directories, in priority order:
x86-64-v4
x86-64-v3 (supported, searched)
x86-64-v2 (supported, searched)
```
RHEL9 will use `x86-64-v2` as its baseline.
This RFC is proposing adding an `x86_64_v3` port in Arch Linux.
Assuming SSE4 and AVX2 (and others) while compiling will provide greater out-of-the-box performance in Arch Linux.
There are also implications in terms of battery life for laptop users.
## Benchmarks
It is difficult to benchmark an entire system, and workloads that benefit most often have CPU detection inbuilt and use optimised paths.
Also, the relevant GCC and LLVM releases are not yet available.
To make some tests equivalent to `x86-64-v3` using current GCC and LLVM, we can compile packages using:
```sh
CFLAGS="$CFLAGS -mcx16 -msahf -mpopcnt -msse3 -msse4.1 -msse4.2 -mssse3 \
mavx -mavx2 -mbmi -mbmi2 -mf16c -mfma -mlzcnt -mmovbe -mxsave"
CXXFLAGS="$CFLAGS"
```
Some benchmarks performed rebuilding packages with and without the above CFLAGS additions against repositories from 2021-03-12:
**firefox-86.0.1-1**: benchmarking on [`Basemark Web`](https://web.basemark.com/) 3.0 seven times (alternating installs) gave a median score of 514.68 for v1 and 565.42 for v3, representing a 9.9% improvement.
Note, this was rebuilding only Firefox itself, and none of its dependencies, thus representing a lower bound.
**openssl-1.1.1.j-1**: benchmarking using `openssl speed rsa` showed improvements in the range of 3.4% to 5.1% for signing and verifying with keys of different sizes.
[Benchmarks posted](https://lists.archlinux.org/pipermail/arch-general/2021-March/048739.html) on the arch-general mailing list show a median performance benefit of `-march=haswell` (roughly `x86_64-v3`) of around 10%.
## Specification
We will provide a second port where the distributed `makepkg.conf` includes the following:
```sh
CARCH="x86_64_v3"
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=x86-64-v3 -mtune=generic ..."
CXXFLAGS="$CFLAGS"
```
## Drawbacks
Providing a second architecture would increase our repo size by approximately 66% (~32GB).
Building two architectures will take additional packager time unless automated.
Some developers may not have hardware to debug issues found purely in `x86-64-v3` packages.
It is likely these issues are very rare.
## Unresolved Questions
When `Architecture = auto` is set in `pacman.conf`, `pacman` will use `uname` to detect the architecture.
As this port is more of an optimised rebuild rather than a architecture change, `uname` will report `x86_64`.
We could patch `pacman` to use `x86_64_v3` instead, but that may not be the correct solution.
It would be preferable if `pacman` on `x86_64_v3` could still install packages from `x86_64`, particularly for non-Arch repositories that may not want to build for both architectures.
This would also allow a transition into `x86_64_v3` when firstly `[core]` gets rebuilt, followed by other repos one at a time.
Your friendly `pacman` developers may be willing to add the ability to specify multiple architectures in `pacman.conf`.
## Alternatives Considered
Moving the baseline to `x86-64-v2` was discussed, but the gains were not considered enough to justify removal of support for hardware without SSE4.2.
Providing all four architectures would require a lot of resources in terms of build time, and mirror space.
Providing `x86-64` and `x86-64-v3` only is a trade-off in gaining support for more optimised binary support for new hardware (while not requiring the absolute latest) and additional build time and storage associated with providing multiple architectures.
rfcs/0003-buildflags.md 0 → 100644
View file @ a82796f0
---
title: 0003 Updates to build flags
---
# Updates to build flags
- Date proposed: 2020-03-04
- RFC MR: <https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/0003>
## Summary
Updating our buildflags will improve our packages security.
## Motivation
Compiler security features have advanced since we last updated our buildflags.
While we have enabled some of these by default in our compilers, there is further improvements to be made.
This RFC puts forward a set of compiler flags that have seen real world usage in other distributions e.g. [Fedora](https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md.) and [Ubuntu](https://wiki.ubuntu.com/ToolChain/CompilerFlags).
## Specification
We will change the distributed `makepkg.conf` to the following:
```sh
#CPPFLAGS=""
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
-Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Werror=format-security \
-fstack-clash-protection -fcf-protection"
CXXFLAGS="$CFLAGS"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
```
Details of new additions:
- Move `-D_FORTIFY_SOURCE=2` from CPPFLAGS to CFLAGS using -Wp
Unfortunately, there are still build systems which use CFLAGS but not CPPFLAGS.
Or configure tests that use CPPFLAGS and not CFLAGS which creates errors due to fortify source needing optimisation.
Ultimately, we can cover more code with this workaround.
- Add `-fexceptions`
Provide exception unwinding support for C programs.
This also hardens cancellation handling in C programs, and makes it possible to unwind the stack (using C++ throw or Rust panics) from C callback functions.
- Add `-Wp,-D_GLIBCXX_ASSERTIONS`
Enable lightweight assertions in the C++ standard library.
This flag is added to both CFLAGS and CXXFLAGS; C compilations will simply ignore it.
- Add `-Werror=format-security`
Turn on format string warnings and treat them as errors.
This catches a set of readily exploitable bugs.
This can occasionally result in compilation errors, but this should be minimal as it is widely used by other distributions.
- Add `-fstack-clash-protection`
Ensures all variable length memory allocated from the stack (via `alloca()` or GCC variable length arrays etc) are probed at the time they are allocated.
This mitigates stack-clash attacks by ensuring all stack memory allocations are valid (or by raising a segmentation fault if they are not, and turning a possible code-execution attack into a denial of service).
Without this flag, vulnerabilities can result where the stack overlaps with the heap, or thread stacks spill into other regions of memory.
- Add `-fcf-protection`
Generates instructions to support Intel\'s Control-flow Enforcement Technology (CET).
Instrument binaries to guard against ROP/JOP attacks.
Used on `i686` and `x86_64`.
## Drawbacks
Moving `-D_FORTIFY_SOURCE=2` is zero cost.
Adding `-Werror=format-security` may cause limited build issues, but patches are readily available.
There is a minimal performance overhead of adding `-Wp,-D_GLIBCXX_ASSERTIONS`, though many of the added checks are optimised away by the compiler.
Adding `-fstack-clash-protection` also has very little run-time overhead.
Adding `-fexceptions` can produce some data size overhead in C programs, though does not affect execution.
GCC enables it by default for C++.
Using `-fcf-protection` is incompatible with `-mindirect-branch` (which is used to implement `retpoline`).
In such cases it is recommended to disable `-fcf-protection`, such as with `-fcf-protection=none` in CFLAGS/CXXFLAGS.
## Unresolved Questions
None.
## Alternatives Considered
- Add `-grecord-gcc-switches` to our debug builds
This is the default in GCC.
- Add `-fasynchronous-unwind-tables` to our debug builds
This is the default in GCC, at least for x86_64.