GNU bug report logs -
#38846
[PATCH 0/4] Move 'HACKING' to the manual, and a proposal for commit access
Previous Next
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Wed, 1 Jan 2020 16:31:02 UTC
Severity: normal
Tags: patch
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Thu, 09 Jan 2020 23:39:16 +0100
with message-id <87y2ugqmp7.fsf <at> gnu.org>
and subject line Re: [bug#38846] [PATCH 4/4] DRAFT doc: Add a cooption policy for commit access.
has caused the debbugs.gnu.org bug report #38846,
regarding [PATCH 0/4] Move 'HACKING' to the manual, and a proposal for commit access
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
38846: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38846
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Hello Guix!
Happy new year, merry 12 nivôse, or whatever celebration is
appropriate for you! :-)
These patches do three things:
1. Move text from ‘HACKING’ to ‘doc/contributing.texi’.
2. Encourage patch review for committers.
3. Add a tentative policy for granting commit access (the last
patch of this series).
I expect #1 and #2 to be uncontroversial, but I’d like feedback on #3!
So far, we’ve been giving commit access in a very ad-hoc fashion.
Often it was Ricardo or myself who ended up taking care of that,
even though other people have admin rights on Savannah to add/remove
members.
We briefly discussed it among maintainers after the maintainer
collective expanded, and it seems to me that perhaps now is a good time
to formalize things a bit—to clarify what contributors may expect and
to increase transparency. Hence this proposal of a simple co-optation
policy.
As you know, Chris Baines has been working towards automated testing
of submitted patches. One of the goals is to allow part of the
QA to be automated, such that, eventually, approved merges could be
automated. In that spirit, we would have an incentive to not add more
committers (probably also a good thing security-wise). That’s why I
added a note on this topic.
What do people think?
Thanks,
Ludo’.
Ludovic Courtès (4):
doc: Add "Tracking Bugs and Patches" section.
doc: Move "Commit Access" section from 'HACKING' to the manual.
doc: Encourage patch review.
DRAFT doc: Add a cooption policy for commit access.
HACKING | 58 +-------------
doc/contributing.texi | 171 ++++++++++++++++++++++++++++++++++++++++--
doc/guix.texi | 2 +-
3 files changed, 168 insertions(+), 63 deletions(-)
--
2.24.1
[Message part 3 (message/rfc822, inline)]
Hello,
Tobias Geerinckx-Rice <me <at> 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’.
This bug report was last modified 5 years and 135 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.