emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#38846: closed ([PATCH 0/4] Move 'HACKING' to the manual, and a propo


From: GNU bug Tracking System
Subject: bug#38846: closed ([PATCH 0/4] Move 'HACKING' to the manual, and a proposal for commit access)
Date: Thu, 09 Jan 2020 22:40:01 +0000

Your message dated Thu, 09 Jan 2020 23:39:16 +0100
with message-id <address@hidden>
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
address@hidden.)


-- 
38846: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38846
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: [PATCH 0/4] Move 'HACKING' to the manual, and a proposal for commit access Date: Wed, 1 Jan 2020 17:29:45 +0100
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




--- End Message ---
--- Begin Message --- Subject: Re: [bug#38846] [PATCH 4/4] DRAFT doc: Add a cooption policy for commit access. Date: Thu, 09 Jan 2020 23:39:16 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Hello,

Tobias Geerinckx-Rice <address@hidden> 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’.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]