From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 12 15:27:55 2022 Received: (at 59513) by debbugs.gnu.org; 12 Dec 2022 20:27:55 +0000 Received: from localhost ([127.0.0.1]:55162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4pP0-0003XI-RL for submit@debbugs.gnu.org; Mon, 12 Dec 2022 15:27:55 -0500 Received: from mail-ed1-f65.google.com ([209.85.208.65]:40881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4pOy-0003XA-HY for 59513@debbugs.gnu.org; Mon, 12 Dec 2022 15:27:53 -0500 Received: by mail-ed1-f65.google.com with SMTP id e13so14774822edj.7 for <59513@debbugs.gnu.org>; Mon, 12 Dec 2022 12:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=0lzWkjmKeR0q/ePpxjoVwMVSjQUb+UKvE4UHdZPiGwY=; b=fcyx8i7mZ4z8FwOIm8+E4350E8eL/FWb8LsApcD4FrtnYsEBja+mTyN9edZB6oUtIw JQ4tC9B7Euc9RGtM3Etf1wW+Yj2vwZkM3NzSD8JnlE+WljhBSEB58I/zT4Woctidj47V 6pD0/UAnevM30FF6cHv8FTT7dRGO4ufTUtpZn9l58vaozGR9323C8HPESbGC2EWXLF4N jPBcHxEU9avfrX8S9jwtlwWV2eCumzwLJHXpd6tceKrDIKwLxtVXLb2e2jlD0TulKMod 818Y2PYC8YdoJUQTsLal33Ye1GR2g2lpbUmqfu4go97+gdxMHlZqWDdCxM7JrnOuTof4 d0zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=0lzWkjmKeR0q/ePpxjoVwMVSjQUb+UKvE4UHdZPiGwY=; b=qBdkqv8eDA4H3jMQmxKZqw4l3wX2jj7ZVm8pMf8vK7cCOTCVrefSlbNMRBO2QUMtru wzVf6jhfo+tabyVHfx8crVgcJH4X/ggTzEVSmcIjnRzc99ykCsuWw9UmpArZDM72fP9X uy3m3rINftk1EkUWA1bMtLSUD748YLOqRLbW1rSMyu7LF63YjphFzJz94w4Vv+X7a+tX cqY/Lg7RlE1A9uNwoJ5NKSrbdiPKQqvXBabzaIb8Bha5A/X58jZwouNc682Xx8blIP2U nU30UnYJRajlKG4ywN80NwTW/wpRp1BkRJaPvqXJy1Fbt+sTEAHbLUNewRyA4P0MW3G5 O6+A== X-Gm-Message-State: ANoB5pkocsWouqC73BjrbIYY65FvOHVcMGkCgEtjs9nKqeFm74T+8YIK EiKuJBoI4HHYzWAebhBPX94= X-Google-Smtp-Source: AA0mqf6x1LzSa0pC/pCic4V2Ggcnu2Vgn5jkCda9ZDmlT4ZCMvqlDrdE3E65OXijIE3tX3kC6/PRHw== X-Received: by 2002:a05:6402:177b:b0:46d:5e5d:ad8c with SMTP id da27-20020a056402177b00b0046d5e5dad8cmr15820028edb.14.1670876866641; Mon, 12 Dec 2022 12:27:46 -0800 (PST) Received: from lumine.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id y15-20020a056402170f00b0045726e8a22bsm4107451edu.46.2022.12.12.12.27.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Dec 2022 12:27:46 -0800 (PST) Message-ID: Subject: Re: [PATCH v2] doc: contributing: Tweak the Commit Policy. From: Liliana Marie Prikler To: Christopher Baines Date: Mon, 12 Dec 2022 21:27:45 +0100 In-Reply-To: <87wn6wq4dl.fsf@cbaines.net> References: <20221123104946.29480-1-mail@cbaines.net> <20221208112051.5019-1-mail@cbaines.net> <87wn6wq4dl.fsf@cbaines.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.0 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59513 Cc: 59513@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Am Montag, dem 12.12.2022 um 10:49 +0000 schrieb Christopher Baines: >=20 > Liliana Marie Prikler writes: >=20 > > Am Donnerstag, dem 08.12.2022 um 11:20 +0000 schrieb Christopher > > Baines: > > > Add more examples of when it can be appropriate to push changes > > > without > > > review, as I think this can be appropriate in the case of trivial > > > changes (as > > > mentioned before), but also non-trivial fixes. > > >=20 > > > No longer suggest pushing simple new packages or package upgrades > > > (that don't cause lots of rebuilds) without sending to guix- > > > patches. > > > Now there's some automation for testing changes sent to guix- > > > patches, > > > sending changes there before pushing can mean that more rigerious > >=20 > > rigorous >=20 > Thanks, I've fixed that locally now. >=20 > > > testing takes place and help speed up substitutes becoming > > > available. > > > This is true, even if no human review takes place. > > >=20 > > > Only suggest waiting one week for review for simpler changes, > > > wait > > > two weeks > > > for more significant changes. > > >=20 > > > Also, reorder some of the information in this section so it's > > > grouped > > > together > > > better. > > >=20 > > > * doc/contributing.texi (Commit Policy): Tweak. > > > --- > > > =C2=A0doc/contributing.texi | 41 ++++++++++++++++++------------------= - > > > ---- > > > =C2=A01 file changed, 18 insertions(+), 23 deletions(-) > > >=20 > > > diff --git a/doc/contributing.texi b/doc/contributing.texi > > > index 6a8ffd6524..d2e7abba98 100644 > > > --- a/doc/contributing.texi > > > +++ b/doc/contributing.texi > > > @@ -1824,23 +1824,26 @@ It additionally calls @code{make check- > > > channel-news} to be sure > > >=20 > > > =C2=A0@subsection Commit Policy > > >=20 > > > -If you get commit access, please make sure to follow > > > -the policy below (discussions of the policy can take place on > > > +If you get commit access, please make sure to follow the policy > > > below > > > +(discussions of the policy can take place on > > > =C2=A0@email{guix-devel@@gnu.org}). > > >=20 > > > -Non-trivial patches should always be posted to > > > -@email{guix-patches@@gnu.org} (trivial patches include fixing > > > typos, > > > -etc.).=C2=A0 This mailing list fills the patch-tracking database > > > -(@pxref{Tracking Bugs and Patches}). > > > - > > > -For patches that just add a new package, and a simple one, it's > > > OK > > > to > > > -commit, if you're confident (which means you successfully built > > > it > > > in a > > > -chroot setup, and have done a reasonable copyright and license > > > -auditing).=C2=A0 Likewise for package upgrades, except upgrades that > > > trigger > > > -a lot of rebuilds (for example, upgrading GnuTLS or GLib).=C2=A0 We > > > have > > > a > > > -mailing list for commit notifications (@email{guix- > > > commits@@gnu.org}), > > > -so people can notice.=C2=A0 Before pushing your changes, make sure t= o > > > run > > > -@code{git pull --rebase}. > > > +Changes should be posted to @email{guix-patches@@gnu.org}.=C2=A0 Thi= s > > > mailing > > > +list fills the patch-tracking database (@pxref{Tracking Bugs and > > > +Patches}).=C2=A0 It also allows patches to be picked up and tested b= y > > > the > > > +quality assurance tooling; the result of that testing eventually > > > shows > > > +up on the dashboard at > > > +@indicateurl{https://qa.guix.gnu.org/issue/@var{number}}, where > > > +@var{number} is the number assigned by the issue tracker.=C2=A0 Leav= e > > > time > > > +for a review, without committing anything (@pxref{Submitting > > > Patches}). > > > +If you didn=E2=80=99t receive any reply after one week (two weeks fo= r > > > more > > > +significant changes), and if you're confident, it's OK to > > > commit. > >=20 > > I would reword that so > > =C2=A0 (not significant =E2=88=A7 confident =E2=88=A7 qa_green) =E2=86= =92 good after 1 week > > whereas > > =C2=A0 (not significant =E2=88=A7 confident =E2=88=A7 qa_unknown) =E2= =86=92 good after 2 weeks > > and significant changes should anyway take 2 weeks. >=20 > While I like the intent here, for the moment I prefer a simpler > policy. Maybe we can move in this direction when the QA tooling is > more usable and reliable. I wrote this partly with the intent of resolving an ambiguity, but I agree on the principle of having a simple policy. I take it that QA status is not that important at the moment =E2=80=93 more that QA knows abo= ut the patch and has already started building packages? Cheers