guix-devel
[Top][All Lists]
Advanced

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

Re: bug#61894: [PATCH RFC] Team approval for patches


From: Maxim Cournoyer
Subject: Re: bug#61894: [PATCH RFC] Team approval for patches
Date: Tue, 14 Mar 2023 11:58:58 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hi,

Peter Polidoro <peter@polidoro.io> writes:

> There is a phenomenon in manufacturing quality control where sometimes
> adding inspectors decreases the number of defects that get past
> inspection unnoticed, because one inspector catches a defect that
> another inspector missed, but other times the number of unnoticed
> defects actually goes UP, presumably because if inspectors know others
> are also looking for defects, they, perhaps subconciously, think they
> do not need to look as carefully, because another inspector will catch
> whatever they miss. One inspector looking carefully can be better than
> two inspectors looking less carefully.

Haha!  That seems very human.

> It would be nice if packages that pull from a "trusted source" and
> that need only a bump in the version number and hash could be approved
> by only one person or, more ideally, zero people, if it could be
> tested and automated somehow. Although perhaps that would always be a
> security risk.

That'd be cool.  I think it's not too far fetched that in the future
this may be possible with the QA tooling.

> Is there documentation or a roadmap somewhere online for people new
> the community who submit patches, but someday aspire to arise to
> committer status? The roadmap might be a list of books to read,
> tutorials to complete, packages to create, in order to learn enough to
> be able to help with the committer shortage?

There are some tips in the manual: info '(guix) Commit Access', which
reads like:

    Everyone can contribute to Guix without having commit access (*note
    Submitting Patches::).  However, for frequent contributors, having write
    access to the repository can be convenient.  As a rule of thumb, a
    contributor should have accumulated fifty (50) reviewed commits to be
    considered as a committer and have sustained their activity in the
    project for at least 6 months.  This ensures enough interactions with
    the contributor, which is essential for mentoring and assessing whether
    they are ready to become a committer.  Commit access should not be
    thought of as a “badge of honor” but rather as a responsibility a
    contributor is willing to take to help the project.

The most important part in my opinion is having been around long enough
to have had enough interactions to gain the trust of the other
participants, and shown a rationale, positive response to feedback
provided (which can admittedly be difficult at times!).

-- 
Thanks,
Maxim



reply via email to

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