Re: [arch-dev-public] RFC: Using RFCs
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 pgpfmnXtdN4Y5.pgp Description: PGP signature
Re: [arch-dev-public] RFC: Using RFCs
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/23dae7a83ea79f3b5da1e5c3b6c598266ae89b65 [1]: https://github.com/NixOS/rfcs/ -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: Using RFCs
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 signature.asc Description: PGP signature
