| Message ID | 20200101163446.5132-4-ludo@gnu.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Move 'HACKING' to the manual, and a proposal for commit access | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | fail | Apply failed |
Ludovic Courtès <ludo@gnu.org> writes: > DRAFT: Subject to discussion! > > * doc/contributing.texi (Commit Access): Draft a cooptation policy. I like this! > +Find three committers who would vouch for you, emailing a signed > +statement to @email{guix-maintainers@@gnu.org} (a private alias for the > +collective of maintainers). You can view the list of committers at > +@url{https://savannah.gnu.org/project/memberlist.php?group=guix}. I misinterpreted this to mean that the three committers would need to sign their endorsement… > + > +@item > +Send @email{guix-maintainers@@gnu.org} a signed message stating your > +intent, listing the three committers who support your application, and > +giving the fingerprint of the OpenPGP key you will use to sign commits > +(see below). I think it may be necessary to state that “signed” means the use of a cryptographic signature here and not just “~~ Rekado” (as it would be done on the Wikipedia for example). Perhaps we could link to the email self defense guide of the FSF? https://emailselfdefense.fsf.org/en/ Thank you for the draft! -- Ricardo
Hi, Nice proposal! On Wed, 1 Jan 2020 at 17:36, Ludovic Courtès <ludo@gnu.org> wrote: > +Committers are expected to have had some interactions with you as a > +contributor and to be able to judge whether you are sufficiently > +familiar with the project's practices. It is @emph{not} a judgment on > +the quality of your work, so a refusal should rather be interpreted as > +``let's try again later''. Cutting the hairs: on one hand "be able to judge" on practices and on the other hand "not a judgment on the quality". Even if I understand the idea behind (I guess), I do not find it well worded, if I might. I mean, I bet that "the quality of work" is a strong part when motivating the acceptance or the refusal, so yes it is "a judgment on the quality of your work" (but not only). Quality implies standards and practices; quality can be measured (more or less). From my understanding. Instead of 'quality', I propose 'value' which is more subjective. Well, my English is not very good... > +However, note that the project is working towards a more automated patch > +review and merging system, which, as a consequence, may lead us to have > +fewer people with commit access to the main repository. Stay tuned! > +@end quotation I find inappropriate the "Stay tuned!" in the manual. Cheers, simon
Ludovic Courtès <ludo@gnu.org> writes: > +Find three committers who would vouch for you, emailing a signed > +statement to @email{guix-maintainers@@gnu.org} (a private alias for the > +collective of maintainers). You can view the list of committers at > +@url{https://savannah.gnu.org/project/memberlist.php?group=guix}. > + > +Committers are expected to have had some interactions with you as a > +contributor and to be able to judge whether you are sufficiently > +familiar with the project's practices. It is @emph{not} a judgment on > +the quality of your work, so a refusal should rather be interpreted as > +``let's try again later''. Maybe it is superfluous, because maintainers have the final say anyways. But I think getting vouching approval by three committers and one maintainer would be a fine idea. Wdyt?
Brett Gilio <brettg@gnu.org> writes: > Ludovic Courtès <ludo@gnu.org> writes: > >> +Find three committers who would vouch for you, emailing a signed >> +statement to @email{guix-maintainers@@gnu.org} (a private alias for the >> +collective of maintainers). You can view the list of committers at >> +@url{https://savannah.gnu.org/project/memberlist.php?group=guix}. >> + >> +Committers are expected to have had some interactions with you as a >> +contributor and to be able to judge whether you are sufficiently >> +familiar with the project's practices. It is @emph{not} a judgment on >> +the quality of your work, so a refusal should rather be interpreted as >> +``let's try again later''. > > Maybe it is superfluous, because maintainers have the final say > anyways. But I think getting vouching approval by three committers and > one maintainer would be a fine idea. One long term goal is to reduce the dictatorial powers of maintainers and shift more towards finding consensus or seeking consent. Maintainers can’t know every new contributor, but they probably know the committers who vouch for the new contributor. -- Ricardo
Hello! Ricardo Wurmus <rekado@elephly.net> skribis: > Ludovic Courtès <ludo@gnu.org> writes: > >> DRAFT: Subject to discussion! >> >> * doc/contributing.texi (Commit Access): Draft a cooptation policy. > > I like this! > >> +Find three committers who would vouch for you, emailing a signed >> +statement to @email{guix-maintainers@@gnu.org} (a private alias for the >> +collective of maintainers). You can view the list of committers at >> +@url{https://savannah.gnu.org/project/memberlist.php?group=guix}. > > I misinterpreted this to mean that the three committers would need to > sign their endorsement… That’s actually what I meant, but perhaps this is ambiguous? >> + >> +@item >> +Send @email{guix-maintainers@@gnu.org} a signed message stating your >> +intent, listing the three committers who support your application, and >> +giving the fingerprint of the OpenPGP key you will use to sign commits >> +(see below). > > I think it may be necessary to state that “signed” means the use of a > cryptographic signature here and not just “~~ Rekado” (as it would be > done on the Wikipedia for example). Perhaps we could link to the email > self defense guide of the FSF? > > https://emailselfdefense.fsf.org/en/ Good points. Taking these comments into accounts, I get: --8<---------------cut here---------------start------------->8--- @enumerate @item Find three committers who would vouch for you. You can view the list of committers at @url{https://savannah.gnu.org/project/memberlist.php?group=guix}. Each of them should email a statement to @email{guix-maintainers@@gnu.org} (a private alias for the collective of maintainers), signed with their OpenPGP key. Committers are expected to have had some interactions with you as a contributor and to be able to judge whether you are sufficiently familiar with the project's practices. It is @emph{not} a judgment on the quality of your work, so a refusal should rather be interpreted as ``let's try again later''. @item Send @email{guix-maintainers@@gnu.org} a message stating your intent, listing the three committers who support your application, signed with the OpenPGP key you will use to sign commits, and giving its fingerprint (see below). See @uref{https://emailselfdefense.fsf.org/en/}, for an introduction to public-key cryptography with GnuPG. @item Once you've been given access, please send a message to @email{guix-devel@@gnu.org} to say so, again signed with the OpenPGP key you will use to sign commits. That way, everyone can notice and ensure you control that OpenPGP key. @c TODO: Add note about adding the fingerprint to the list of authorized @c keys once that has stabilized. @item Make sure to read the rest of this section and... profit! @end enumerate --8<---------------cut here---------------end--------------->8--- Thanks for your feedback! Ludo’.
Hello! zimoun <zimon.toutoune@gmail.com> skribis: > On Wed, 1 Jan 2020 at 17:36, Ludovic Courtès <ludo@gnu.org> wrote: > >> +Committers are expected to have had some interactions with you as a >> +contributor and to be able to judge whether you are sufficiently >> +familiar with the project's practices. It is @emph{not} a judgment on >> +the quality of your work, so a refusal should rather be interpreted as >> +``let's try again later''. > > Cutting the hairs: on one hand "be able to judge" on practices and on > the other hand "not a judgment on the quality". > Even if I understand the idea behind (I guess), I do not find it well > worded, if I might. > I mean, I bet that "the quality of work" is a strong part when > motivating the acceptance or the refusal, so yes it is "a judgment on > the quality of your work" (but not only). > Quality implies standards and practices; quality can be measured (more > or less). From my understanding. > > Instead of 'quality', I propose 'value' which is more subjective. I agree that “value” sounds more appropriate here. Fixed! >> +However, note that the project is working towards a more automated patch >> +review and merging system, which, as a consequence, may lead us to have >> +fewer people with commit access to the main repository. Stay tuned! >> +@end quotation > > I find inappropriate the "Stay tuned!" in the manual. Because it’s too informal, or because it’s confusing? (The former is fine with me.) Thanks, Ludo’.
Hi Brett, Brett Gilio <brettg@gnu.org> skribis: > Ludovic Courtès <ludo@gnu.org> writes: > >> +Find three committers who would vouch for you, emailing a signed >> +statement to @email{guix-maintainers@@gnu.org} (a private alias for the >> +collective of maintainers). You can view the list of committers at >> +@url{https://savannah.gnu.org/project/memberlist.php?group=guix}. >> + >> +Committers are expected to have had some interactions with you as a >> +contributor and to be able to judge whether you are sufficiently >> +familiar with the project's practices. It is @emph{not} a judgment on >> +the quality of your work, so a refusal should rather be interpreted as >> +``let's try again later''. > > Maybe it is superfluous, because maintainers have the final say > anyways. But I think getting vouching approval by three committers and > one maintainer would be a fine idea. The way I see it, it’s more about notifying maintainers than it’s about asking them for approval; they could refuse someone, but the idea is they’d usually do what other people agreed on. Cooptation may allow us to scale better: it’s easy for maintainers to simply lose track of who has been working on what and who should be given commit access. Thanks for your feedback, Ludo’.
Hi Ludo, On Thu, 2 Jan 2020 at 12:53, Ludovic Courtès <ludo@gnu.org> wrote: > zimoun <zimon.toutoune@gmail.com> skribis: > > I find inappropriate the "Stay tuned!" in the manual. > > Because it’s too informal, or because it’s confusing? (The former is > fine with me.) Maybe a bit of both. :-) It is an analogy, but I feel the same than if I read a manual of maths with "stay tuned" after a theorem as the proof. I feel in the same time not enough formal for a manual and I am confused: is it already proved and not written down yet or is it not proven yet? Well, it is my feedback when I read it. :-) And I feel cutting the hair in small pieces... French bias. ;-) Thank you for the initiative. Cool! All the best, simon
Hi! zimoun <zimon.toutoune@gmail.com> skribis: > On Thu, 2 Jan 2020 at 12:53, Ludovic Courtès <ludo@gnu.org> wrote: > >> zimoun <zimon.toutoune@gmail.com> skribis: > >> > I find inappropriate the "Stay tuned!" in the manual. >> >> Because it’s too informal, or because it’s confusing? (The former is >> fine with me.) > > Maybe a bit of both. :-) > > It is an analogy, but I feel the same than if I read a manual of maths > with "stay tuned" after a theorem as the proof. I feel in the same > time not enough formal for a manual and I am confused: is it already > proved and not written down yet or is it not proven yet? Heh. Well I guess it doesn’t bring much anyway, we can remove it. Thanks, Ludo’.
Ludo', Thank you for this series. Ludovic Courtès 写道： > +@item > +Send @email{guix-maintainers@@gnu.org} a signed message stating > your > +intent, listing the three committers who support your > application, and > +giving the fingerprint of the OpenPGP key you will use to sign > commits > +(see below). > + > +@item > +Once you've been given access, please send a message to ^^^^ Probably just me, but this glosses over maintainer approval just a bit too deftly, and that even with 3 signed referrals commit access isn't guaranteed, just extremely likely. Unless that will actually change, I think we should briefly mention it as well. People react worse to ‘let's try again later’ when they think they've already passed. Understandably so. > +@email{guix-devel@@gnu.org} to say so, again signed with the > OpenPGP key > +you will use to sign commits. That way, everyone can notice > and ensure > +you control that OpenPGP key. Best to add an explicit ‘before pushing your first commit’ here, if that is the intent. > +When you get commit access, please make sure to follow ^^^^ ‘If’? Same point as the first @items above. Kind regards, T G-R
Tobias Geerinckx-Rice 写道： > Ludo', > > Thank you for this series. Speaking of being explicit: LGTM! Kind regards, T G-R
Tobias Geerinckx-Rice via Guix-patches via <guix-patches@gnu.org> writes: > Probably just me, but this glosses over maintainer approval just a bit > too deftly, and that even with 3 signed referrals commit access isn't > guaranteed, just extremely likely. > > Unless that will actually change, I think we should briefly mention it > as well. People react worse to ‘let's try again later’ when they > think they've already passed. Understandably so. Hi Tobias, This is definitely not just you. I felt similarly, as per a previous email on the matter where I suggested that it be 3 commiters and 1 maintainer. But that process turned out to be redundant, if not completely superfluous by Ricardo's mention of how the process is likely to change in the future with a different integration model. Regardless, I hear your point. I also think that getting refused after achieving three referrals is a hard point. I think it should be documented clearly that the mainters have the final say. Additionally, and this is just a point for my part, depending on what kind of merit we are taking for credence in a committer making a referral, should we only consider committers who have worked closely with the person requesting commit access, or is somebody who has reviewed and seen their patches in passing also a viable subject? For example, I have been asked a few times by people to push patches for them over IRC, but their patches were unrelated to software I use / would use / know how to approach (examples being GNOME). So, I kindly refused to push their patch citing that I do not feel comfortable in knowledge to understand the ramifications of their patches. Hypothetically, if such a person approached me in the future and asked for a commit access referral, since I had not worked closely with them what kind of weight would be referral hold? I hope this makes sense. Maybe I am being overly nitpicky, I just really like clarity. :)
Hi, My end-user opinion does not matter. But the transparency is good. :-) On Tue, 7 Jan 2020 at 01:19, Brett Gilio <brettg@gnu.org> wrote: > > Tobias Geerinckx-Rice via Guix-patches via <guix-patches@gnu.org> > writes: > > > Probably just me, but this glosses over maintainer approval just a bit > > too deftly, and that even with 3 signed referrals commit access isn't > > guaranteed, just extremely likely. > > > > Unless that will actually change, I think we should briefly mention it > > as well. People react worse to ‘let's try again later’ when they > > think they've already passed. Understandably so. [...] > This is definitely not just you. I felt similarly, as per a previous > email on the matter where I suggested that it be 3 commiters and 1 > maintainer. But that process turned out to be redundant, if not > completely superfluous by Ricardo's mention of how the process is likely > to change in the future with a different integration model. I am not native English speaker so maybe I misread. From my understanding, the proposal clarifies how the access is granted. Currently, only the maintainers grant; from what I have observed, it is more because of historical reasons than an explicit model. The new integration model proposes to enforce the trust and goes to reduce/distribute the "power" of maintainers -- which is good IMHO. Therefore, the maintainers trust the current committers, and if 3 committers approve, why should 1 maintainer reject the applicant? It is a chain of trust. > Regardless, I hear your point. I also think that getting refused after > achieving three referrals is a hard point. I think it should be > documented clearly that the mainters have the final say. I do not see why. If 3 referrals vouch an applicant and 1 maintainer refuses, then there is an issue elsewhere. The chain of trust is broken and it means that the project is not healthy. > Additionally, and this is just a point for my part, depending on what > kind of merit we are taking for credence in a committer making a > referral, should we only consider committers who have worked closely > with the person requesting commit access, or is somebody who has > reviewed and seen their patches in passing also a viable subject? As an end-user, I do not want to pull "bad" code; which means not GNU compliant. And a rule of thumb usually is: when you (committer) are annoyed to review patches because you know that you would not do better yourself; concretely, significant contributions with no final tweaks. > For example, I have been asked a few times by people to push patches for > them over IRC, but their patches were unrelated to software I use / > would use / know how to approach (examples being GNOME). So, I kindly > refused to push their patch citing that I do not feel comfortable in > knowledge to understand the ramifications of their > patches. Hypothetically, if such a person approached me in the future > and asked for a commit access referral, since I had not worked closely > with them what kind of weight would be referral hold? The bottleneck is the review. Well, I have tried to point out this here [1]. Sometime ago, "maintainer" of submodule had been discussed. For example, one could imagine that the commit access comes with the "responsibility" to take care of a submodule; with great power comes great responsibility. ;-) [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38846#71 > I hope this makes sense. Maybe I am being overly nitpicky, I just really > like clarity. :) Me too, :-) All the best, simon
Hi Ludo, Thank you for taking the time to draft this new policy. Ludovic Courtès <ludo@gnu.org> writes: [...] > Taking these comments into accounts, I get: > > @enumerate > @item > Find three committers who would vouch for you. You can view the list of > committers at > @url{https://savannah.gnu.org/project/memberlist.php?group=guix}. Each > of them should email a statement to @email{guix-maintainers@@gnu.org} (a > private alias for the collective of maintainers), signed with their > OpenPGP key. > > Committers are expected to have had some interactions with you as a > contributor and to be able to judge whether you are sufficiently > familiar with the project's practices. It is @emph{not} a judgment on > the quality of your work, so a refusal should rather be interpreted as > ``let's try again later''. > > @item > Send @email{guix-maintainers@@gnu.org} a message stating your intent, > listing the three committers who support your application, signed with > the OpenPGP key you will use to sign commits, and giving its fingerprint > (see below). See @uref{https://emailselfdefense.fsf.org/en/}, for an > introduction to public-key cryptography with GnuPG. Note that Email Self-Defense focuses on the use of Thunderbird + the Enigmail plugin, both of which are missing from our collection of packages. I don't have a better resource to suggest, though. > @item > Once you've been given access, please send a message to > @email{guix-devel@@gnu.org} to say so, again signed with the OpenPGP key > you will use to sign commits. That way, everyone can notice and ensure > you control that OpenPGP key. > > @c TODO: Add note about adding the fingerprint to the list of authorized > @c keys once that has stabilized. > > @item > Make sure to read the rest of this section and... profit! > @end enumerate > > Thanks for your feedback! > > Ludo’. I like the proposal drafted so far. I agree with others that it is important to say that the maintainers reserve the final say in whether or not a contributor is granted push rights to the Guix repository, for transparency. LGTM :-) Maxim
Hello, Tobias Geerinckx-Rice <me@tobias.gr> skribis: > Ludovic Courtès 写道： >> +@item >> +Send @email{guix-maintainers@@gnu.org} a signed message stating >> your >> +intent, listing the three committers who support your application, >> and >> +giving the fingerprint of the OpenPGP key you will use to sign >> commits >> +(see below). >> + >> +@item >> +Once you've been given access, please send a message to > ^^^^ > > Probably just me, but this glosses over maintainer approval just a bit > too deftly, and that even with 3 signed referrals commit access isn't > guaranteed, just extremely likely. > > Unless that will actually change, I think we should briefly mention it > as well. People react worse to ‘let's try again later’ when they > think they've already passed. Understandably so. Good points (from Maxim, too). >> +@email{guix-devel@@gnu.org} to say so, again signed with the >> OpenPGP key >> +you will use to sign commits. That way, everyone can notice and >> ensure >> +you control that OpenPGP key. > > Best to add an explicit ‘before pushing your first commit’ here, if > that is the intent. Indeed. >> +When you get commit access, please make sure to follow > ^^^^ > > ‘If’? Same point as the first @items above. Yes. I’ve now pushed the whole series: ef09cb866c doc: Add a cooptation policy for commit access. 98ebcf1c1b doc: Encourage patch review. 2d315cd428 doc: Move "Commit Access" section from 'HACKING' to the manual. a7bde77d24 doc: Add "Tracking Bugs and Patches" section. I believe I’ve taken into account all the changes that were proposed. If you think anything still needs to be adjusted, let’s do that. Thanks everyone! Ludo’.
diff --git a/doc/contributing.texi b/doc/contributing.texi index 74b4718eb3..6e2cc1a369 100644 --- a/doc/contributing.texi +++ b/doc/contributing.texi @@ -1099,8 +1099,52 @@ this nifty tool! @cindex commit access, for developers For frequent contributors, having write access to the repository is -convenient. When you deem it necessary, feel free to ask for it on the -mailing list. When you get commit access, please make sure to follow +convenient. When you deem it necessary, consider applying for commit +access by following these steps: + +@enumerate +@item +Find three committers who would vouch for you, emailing a signed +statement to @email{guix-maintainers@@gnu.org} (a private alias for the +collective of maintainers). You can view the list of committers at +@url{https://savannah.gnu.org/project/memberlist.php?group=guix}. + +Committers are expected to have had some interactions with you as a +contributor and to be able to judge whether you are sufficiently +familiar with the project's practices. It is @emph{not} a judgment on +the quality of your work, so a refusal should rather be interpreted as +``let's try again later''. + +@item +Send @email{guix-maintainers@@gnu.org} a signed message stating your +intent, listing the three committers who support your application, and +giving the fingerprint of the OpenPGP key you will use to sign commits +(see below). + +@item +Once you've been given access, please send a message to +@email{guix-devel@@gnu.org} to say so, again signed with the OpenPGP key +you will use to sign commits. That way, everyone can notice and ensure +you control that OpenPGP key. + +@c TODO: Add note about adding the fingerprint to the list of authorized +@c keys once that has stabilized. + +@item +Make sure to read the rest of this section and... profit! +@end enumerate + +@quotation Note +Maintainers are happy to give commit access to people who have been +contributing for some time and have a track record---don't be shy and +don't underestimate your work! + +However, note that the project is working towards a more automated patch +review and merging system, which, as a consequence, may lead us to have +fewer people with commit access to the main repository. Stay tuned! +@end quotation + +When you get commit access, please make sure to follow the policy below (discussions of the policy can take place on @email{guix-devel@@gnu.org}).