From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 28 07:03:49 2022 Received: (at 59513) by debbugs.gnu.org; 28 Nov 2022 12:03:49 +0000 Received: from localhost ([127.0.0.1]:48157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozcrU-0001E7-JD for submit@debbugs.gnu.org; Mon, 28 Nov 2022 07:03:49 -0500 Received: from mira.cbaines.net ([212.71.252.8]:41998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ozcrS-0001Dz-W7 for 59513@debbugs.gnu.org; Mon, 28 Nov 2022 07:03:47 -0500 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:3a91:a0a4:ecee:f157]) by mira.cbaines.net (Postfix) with ESMTPSA id D158527BBE9; Mon, 28 Nov 2022 12:03:45 +0000 (GMT) Received: from felis (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 69a0a79d; Mon, 28 Nov 2022 12:03:45 +0000 (UTC) References: <20221123104946.29480-1-mail@cbaines.net> <86tu2pfmbv.fsf@gmail.com> <871qps20fa.fsf@cbaines.net> <86wn7kd0m9.fsf@gmail.com> User-agent: mu4e 1.8.11; emacs 28.2 From: Christopher Baines To: zimoun Subject: Re: [bug#59513] [PATCH] doc: contributing: Tweak the Commit Policy. Date: Mon, 28 Nov 2022 11:46:47 +0000 In-reply-to: <86wn7kd0m9.fsf@gmail.com> Message-ID: <87tu2jxp41.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" 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 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable zimoun writes: > On Thu, 24 Nov 2022 at 08:40, Christopher Baines wrote: > >>> On Wed, 23 Nov 2022 at 10:49, Christopher Baines wro= te: >>> >>>> +For a minority of changes, it can be appropriate to push them directly >>>> +without sending them for review. This includes both trivial changes >>>> +(e.g. fixing typos) but also reverting problomatic changes and >>> -^ >>>> +addressing regressions. > > To be sure you have not missed the typo here. :-) > > s/problomatic/problematic Thanks, I've fixed that locally now. >> Also, this guidance is very general, and I think it should be applicable >> to all changes. We already trust people with commit access to know what >> needs doing, I see this documentation as more about how, so I'd prefer >> not to try and put a list here. > > Yes, we trust people. But a public and explicit policy reinforces the > trust, IMHO. It also documents what commit access means. It is not > because people with commit access already know what they need doing that > all people know, I guess. I don't disagree that we should make the expectations about functionality and testing explicit, but I want to see that separate from the commit policy. >>> and I would keep the =C2=ABtwo weeks=C2=BB instead of the =C2=ABone wee= k except=C2=BB. >> >> My reason for changing this is that I think waiting two weeks after >> sending a simple patch is unreasonable. The value from the automated >> testing will come after one to two days, I just put a week to avoid >> changing it too much, but maybe the lower bound should be two days. > > Who is verifying the impact of a change? :-) Just a recent example to > fix the ideas. The same situation is happening more than often but not > that often neither. :-) ... > My point is: Considering leaf packages, yeah once submitted, the review > can be fast (couple of days) especially with the new QA. Considering > all the other packages, who is checking the impact of a change? > > Otherwise, we have again and again some broken packages. For sure, the > QA is helping *a lot* for improving! Well, on one hand, I understand > the willing to merge faster and, even I am not convinced that from two > weeks to one week would be detrimental. On the other hand, using Guix, > I replaced the pressure when running =E2=80=9Capt-get upgrade=E2=80=9D by= an eternal > annoyance of broken packages popping here or there. This is going a bit off topic I think. In general, the direction I'm trying to move the policy in here is one where more changes get sent to guix-patches rather than getting pushed straight to the repository. Checking the impact of changes is important, but you can't do that with a policy on committing. If however people send changes to guix-patches prior to pushing, then there's at least a chance that some automatic "verifying/checking" can take place. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmOEo55fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9Xfj5g//ULovB0IDUoGjRmaa5YOr8CUyBee6RUSz o+A7fty6G866uHSji0RufVgasnpAkw2BFvL3/4m3Zk7Ys0bnkAMOMz7O/6DiRDy/ QpI5oAXxzD3m7vWOhBX67Tep74PAdzv5tcBOG7CXuylY91+6IC67ps7F4czGDou8 MKyGuBvZPqq6nng/enet8hTLgZAw9Rg28RlT3iAT7WIDw9Qvq+TMU6PLJSWfNh8D CwwNlrood81ZAAGDXqgqLr435i53+bZRF8xKRnNMxWn1+Ie7hib75w6v/osoDJcW m03JOLKbTRuTWS+ui5ZNjCLR1Bot6j0i4SLM5o6QWQCkWJJLLp5G519yjUlNQVc8 Gbx57oNQinULg50BtsicETEq3oBPnSyQU6qXRZqZ/2kzWTziC+PnaBfBEN6y98u3 V+fG7bIj/0H2ke503u8a960lD008ff6UZbjrndU+rA6y1JBgI3SiulNXnWjG64u+ +Wl4ivcvoCVfFesdQi03muasSC9xv1nULM1uFtblOP3sRJtB92u0x7busbhGyYsl Sl8d6+qT4Ye4l04SnSSh7wSW2hxo/EZB/UasB7ktEOo1hKeCVmssZKjhRqnomCCx fisSF0fLjHHpxFUjyxnkEKrTfYv080VuXr06UYcthI64/pLzdKF5OOGhOEEYYY7A REUeF6q73yQ= =OUtZ -----END PGP SIGNATURE----- --=-=-=--