[arch-dev-public] RFC: Using RFCs
Dear staff,
I have begun work on a Request for Comment (RFC) process for Arch Linux
and I am excited to now be able to open the first RFC... to introduce
"Using RFCs" :)
A new RFC (request for comment) has been opened here:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/1
Please visit the above link for discussion.
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.
Best,
David
P.S.: To all staff members, that do not have an SSO account yet, please
get in touch with Sven-Hendrik Haase
Hey all, it has been roughly two weeks since my first mail and the discussions we have had via comments on the RFC merge request have concluded. Thank you all for your improvement suggestions and feedback! This first RFC is rather special, as it is meant to bootstrap the process and introduce it for adoption (while the process is actually not yet in place). Therefore I am skipping the "Final Comment Period" on the issue tracker and instead move the proposal for adoption of the RFC process back to this mailing list for ratification (aka. the final ACK by you!). I am assuming, that a period of two weeks (starting now) is a good time frame to collect the final motion on this topic from many (if not all) of you. I would like to either merge (accept) or close (reject) the proposal after this time frame has passed. Please reply to this mail with an approval or disapproval of the process, so that a consensus can be reached. In case you have not yet read the RFC and the workflow, you can do so in the merge request [1], or - for a better reading experience - on the branch the merge request is created from [2]. Best, David [1] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/1 [2] https://gitlab.archlinux.org/dvzrv/rfcs/-/tree/rfc_process/ -- https://sleepmap.de
On Mon, Feb 15, 2021 at 06:19:10PM +0100, David Runge via arch-dev-public wrote:
This first RFC is rather special, as it is meant to bootstrap the process and introduce it for adoption (while the process is actually not yet in place). Therefore I am skipping the "Final Comment Period" on the issue tracker and instead move the proposal for adoption of the RFC process back to this mailing list for ratification (aka. the final ACK by you!).
A general concern is "who has access to the repository"? Can anyone take the template and submit an RFC that we'd need to consider on the mailing list after a subsequent discussion? I can see it clear as sky the day Gitlab opens and someone figures they'll submit an RFC to move away from systemd to sysvinit/openrc/runit clear as day. Do we only allow pull-requests from staff with comments from users, or do we allow anyone to send pull-requests? I'm not sure about the correct approach here and curious if the concern is still premature at this stage. -- Morten Linderud PGP: 9C02FF419FECBE16
Em fevereiro 15, 2021 15:27 Morten Linderud via arch-dev-public escreveu:
A general concern is "who has access to the repository"? Can anyone take the template and submit an RFC that we'd need to consider on the mailing list after a subsequent discussion? I can see it clear as sky the day Gitlab opens and someone figures they'll submit an RFC to move away from systemd to sysvinit/openrc/runit clear as day.
We discussed this and I think eventually anyone should be able to propose a RFC. But, since as our gitlab isn't open and, the rfc requires an a-d-p announcement, this is limited to staff members for now. The repository currently allows anyone with access to create MR's, but it can be restricted to members only, if needed. Regards, Giancarlo Razzolini
On Mon, Feb 15, 2021 at 06:45:02PM -0300, Giancarlo Razzolini wrote:
Em fevereiro 15, 2021 15:27 Morten Linderud via arch-dev-public escreveu:
A general concern is "who has access to the repository"? Can anyone take the template and submit an RFC that we'd need to consider on the mailing list after a subsequent discussion? I can see it clear as sky the day Gitlab opens and someone figures they'll submit an RFC to move away from systemd to sysvinit/openrc/runit clear as day.
We discussed this and I think eventually anyone should be able to propose a RFC. But, since as our gitlab isn't open and, the rfc requires an a-d-p announcement, this is limited to staff members for now.
The repository currently allows anyone with access to create MR's, but it can be restricted to members only, if needed.
This doesn't address the issue and just reiterated the points? Gitlab is going to be opened within the next months and we have users on Gitlab today. It's not limited to staff. Is it our obligation to propose any user-made RFC to a-d-p on behalf of them? Do we want that? The process is not clear and either assumes the RFC proposer can announce it, or makes it implicit that it will be announced. -- Morten Linderud PGP: 9C02FF419FECBE16
Em fevereiro 15, 2021 18:54 Morten Linderud escreveu:
On Mon, Feb 15, 2021 at 06:45:02PM -0300, Giancarlo Razzolini wrote:
Em fevereiro 15, 2021 15:27 Morten Linderud via arch-dev-public escreveu:
A general concern is "who has access to the repository"? Can anyone take the template and submit an RFC that we'd need to consider on the mailing list after a subsequent discussion? I can see it clear as sky the day Gitlab opens and someone figures they'll submit an RFC to move away from systemd to sysvinit/openrc/runit clear as day.
We discussed this and I think eventually anyone should be able to propose a RFC. But, since as our gitlab isn't open and, the rfc requires an a-d-p announcement, this is limited to staff members for now.
The repository currently allows anyone with access to create MR's, but it can be restricted to members only, if needed.
This doesn't address the issue and just reiterated the points? Gitlab is going to be opened within the next months and we have users on Gitlab today. It's not limited to staff.
Is it our obligation to propose any user-made RFC to a-d-p on behalf of them? Do we want that?
The process is not clear and either assumes the RFC proposer can announce it, or makes it implicit that it will be announced.
It's my understanding that Allan made some amendments that address this issue specifically. But basically I think that a TU/Dev/Staff should be the one doing the post to a-d-p after vetting/sponsoring the RFC. But I maintain that I think anyone should eventually be able to create RFC's. Regards, Giancarlo Razzolini
On Tue, Feb 16, 2021 at 01:38:06PM -0300, Giancarlo Razzolini wrote:
Em fevereiro 15, 2021 18:54 Morten Linderud escreveu:
On Mon, Feb 15, 2021 at 06:45:02PM -0300, Giancarlo Razzolini wrote:
Em fevereiro 15, 2021 15:27 Morten Linderud via arch-dev-public escreveu:
A general concern is "who has access to the repository"? Can anyone take the template and submit an RFC that we'd need to consider on the mailing list after a subsequent discussion? I can see it clear as sky the day Gitlab opens and someone figures they'll submit an RFC to move away from systemd to sysvinit/openrc/runit clear as day.
We discussed this and I think eventually anyone should be able to propose a RFC. But, since as our gitlab isn't open and, the rfc requires an a-d-p announcement, this is limited to staff members for now.
The repository currently allows anyone with access to create MR's, but it can be restricted to members only, if needed.
This doesn't address the issue and just reiterated the points? Gitlab is going to be opened within the next months and we have users on Gitlab today. It's not limited to staff.
Is it our obligation to propose any user-made RFC to a-d-p on behalf of them? Do we want that?
The process is not clear and either assumes the RFC proposer can announce it, or makes it implicit that it will be announced.
It's my understanding that Allan made some amendments that address this issue specifically. But basically I think that a TU/Dev/Staff should be the one doing the post to a-d-p after vetting/sponsoring the RFC. But I maintain that I think anyone should eventually be able to create RFC's.
Yep! My thinking after I went to bed is that if we do want user contribution it should be explicitly handled in the process. I saw two suggestions: 1. A form of RFC sherparding where the person or a team ensures the submitted RFC are vetted and proposed properly. 2. Some form of explicit sponsoring by Devs and/or TUs. If we don't have this the RFCs that can't be proposed by the submitter probably wont be if the queue catches up to us. See the AUR requests piling up and sometimes dealt with by a few people (or the bugtracker). The first idea is essentially what NixOS does for all their RFCs[1]. But Allan also came up with the second idea after reading this thread (I assume). I like that amendment as we are probably not there yet where we need a sherparding team. Link for the folks following the thread: https://gitlab.archlinux.org/allan/rfcs/-/commit/23dae7a83ea79f3b5da1e5c3b6c... [1]: https://github.com/NixOS/rfcs/ -- Morten Linderud PGP: 9C02FF419FECBE16
On 2021-02-16 13:38:06 (-0300), Giancarlo Razzolini via arch-dev-public wrote:
Gitlab is going to be opened within the next months and we have users on Gitlab today. It's not limited to staff.
True, but as we enforce the access rights to all of our repositories, we can change that if the need arises. Currently, the need has not yet arisen.
Is it our obligation to propose any user-made RFC to a-d-p on behalf of them? Do we want that?
The process is not clear and either assumes the RFC proposer can announce it, or makes it implicit that it will be announced.
Providing an example of how to change the proposal would be very helpful and improve the process.
It's my understanding that Allan made some amendments that address this issue specifically.
Indeed, Allan did. I will extend the README with a section that adds a requirement for outside contributors to be supported by at least one Developer or Trusted User (and also highlight this in the RFC).
But basically I think that a TU/Dev/Staff should be the one doing the post to a-d-p after vetting/sponsoring the RFC. But I maintain that I think anyone should eventually be able to create RFC's.
I agree. Given the above mentioned limitation for outside contributors, it is a good model IMHO. Even if outside contributors would like to discuss "controversial" topics, I don't think it is bad having that discussion (given, that it is not done in an inflammatory fashion). It is something that can be referred back to, in case the same topic comes up again. Best, David -- https://sleepmap.de
Thank you all for the RFC idea, healthy discussion around it and the first RFC about having and RFC :) I think this is a great step for our distro to get a nicely pre shaped proposals before hitting the final review and presentation phase as well as a central point for storing those. I think its pretty tough for fresh staff to find discussions, reasoning and details around a certain topic or formulation and this is a great step of address this. Looking at the timeline, the final comment period seems to have ended and I think we have a consensus here. I will take a nap and click the merge button if nothing pops up in the meanwhile :) cheers, Levente
On Tue, 2021-03-02 at 00:19 +0100, Levente Polyak via arch-dev-public wrote:
I think this is a great step for our distro to get a nicely pre shaped proposals before hitting the final review and presentation phase as well as a central point for storing those. I think its pretty tough for fresh staff to find discussions, reasoning and details around a certain topic or formulation and this is a great step of address this. Same feeling.
Nevertheless after reading the final text, it's still unclear to me how the proposals are stamped accepted or rejected and by how many of us? Even accepted, what does that means? We currently have several groups, with different decision-making systems and dynamics. For example, developers use (some sort of) consensus, the TUs majority, etc. Is each group decide if they will apply them with there voting system? Like companies with real RFC (e.g DANE). Is a larger group could use this to push changes in another? Regards, PS: We should pick an acronym like ARFC instead of RFC which is implicit reference to IETF RFC. -- Sébastien "Seblu" Luttringer
On 3/2/21 2:37 AM, Sébastien Luttringer via arch-dev-public wrote:
On Tue, 2021-03-02 at 00:19 +0100, Levente Polyak via arch-dev-public wrote:
I think this is a great step for our distro to get a nicely pre shaped proposals before hitting the final review and presentation phase as well as a central point for storing those. I think its pretty tough for fresh staff to find discussions, reasoning and details around a certain topic or formulation and this is a great step of address this. Same feeling.
Nevertheless after reading the final text, it's still unclear to me how the proposals are stamped accepted or rejected and by how many of us?
Even accepted, what does that means? We currently have several groups, with different decision-making systems and dynamics. For example, developers use (some sort of) consensus, the TUs majority, etc. Is each group decide if they will apply them with there voting system? Like companies with real RFC (e.g DANE). Is a larger group could use this to push changes in another?
I personally didn't have the impression like we would have colliding voting systems for deciding about distro RFCs. We basically just ratified the process of getting to a proposal plus a central place where those need to be stored. To my understanding once a to be proposed RFC hits this mailinglist, we still follow the very same principles of consensus as we followed so far. If anyone wants to change how a proposal is decided, it would need to be another RFC that reaches consensus :) cheers, Levente
participants (5)
-
David Runge
-
Giancarlo Razzolini
-
Levente Polyak
-
Morten Linderud
-
Sébastien Luttringer