From owner-freebsd-ports@freebsd.org Tue Jun 28 21:16:11 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7969B856EB for ; Tue, 28 Jun 2016 21:16:11 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AAD52B1A for ; Tue, 28 Jun 2016 21:16:10 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mandree.no-ip.org ([77.181.5.243]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MRXVc-1ath9k20pU-00Sh8S for ; Tue, 28 Jun 2016 23:16:08 +0200 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id A4CC223D856 for ; Tue, 28 Jun 2016 23:16:07 +0200 (CEST) Subject: Re: blanket portmgr approval vs. non-fixing changes To: freebsd-ports@freebsd.org References: <201606272021.u5RKLVhQ057899@slippy.cwsent.com> <20160628091709.pbvq7lekss2ql2en@ivaldir.etoilebsd.net> From: Matthias Andree Message-ID: <5772E90C.6020908@gmx.de> Date: Tue, 28 Jun 2016 23:15:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160628091709.pbvq7lekss2ql2en@ivaldir.etoilebsd.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="whFBI4hllivU89RVQv0PdCjCSuUpQRqFE" X-Provags-ID: V03:K0:lYUmJJ6YC7erSFQjvUNSjmUscsUxKXoZqsmNXLSrtsU2wAdRy7A CMwWuX+thNJlUoV+Y9CXniT78+5hHAdYpHr8TkaczBF9kte2U2T3nih6PjSCFojRE3l6dGi /vcd5JdwTv8maSQNpsxu0voyEHpXWMRd6WkE98Gm1ImARcUeiGxqPA0MDLfpDR+VWXvnrTA l91EBtKOtEcbyorIa6u4g== X-UI-Out-Filterresults: notjunk:1;V01:K0:ek0/mbnFL7o=:B/lCauXdxPblzerMiv5J4j y3C2aBCFCg3yGo+rmZaCgv40kzh+E0xeslKJrbes5BBEywxO92UrNEtXunmkkka6RUCIfadsf w0k4rOhHVv94rs8L8rsBj8y9d2oqjVZunsNTAO5XG4vMAfkNkKou1mVVh7CiBK2hvWJvmoS0M JZWQnqSE9tdP0m0LDgIqe3xHi7Snhu2IUnOLwwP/YCfCw01GJwip0fE2lTnL6VKomfp8nf9dz YtvvdY22zV4HEkunWCw3Io5ArIYfxVDbP3EUie2RpC2w3Qj15GBoZkFKEkfzf2eVtLCPF9DSa sdQ9dXrzXUOvdfESItBBrlSBPVrOoywmH7tBLtEbuj2dB/VAN6Ah4nmXucGshF1Bn3v0+90ou D8/clomd3Ev53Y3vgRO1UIMH/DCfU7xcNIVhKpcfAOyWvZqAuFH+afc0WGbPcPaOvYjE8it4p jF3nWhtDB1YCtU0AvH6BRZEgjYwrqdvGoc6SiGpNuFVZsnH4trd8HBvQYNDEOeCDtuXlx2eMB QmNVIzJZfRFUSVKa0VSLPgFD12bPYNJBz6+L/ckYsUygyIdtGsk3whWMUl05wKsLC9nnez3DA t64JsmXHiCfIR7pWl8CQRZXWaMWlXH5O7QejqbSLc3lrDoVuGBtkqkhwHPd5YaE6XVfBDdMF2 Wb5ic3URnALADR73ZQbGgGYF/ZKLo2URPTkWcQl1gGswbDsHPKBu2mtvR5q7u9vXXqk6SPimB dh+FeqIWOyfkUsJ9RotX2F4QLHYsl2xIpFKnNv3Sn6HjL8/8YyGvwwiRPrI= X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 21:16:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --whFBI4hllivU89RVQv0PdCjCSuUpQRqFE Content-Type: multipart/mixed; boundary="7HfmuKT66Ri6JgaohPdCgU5Ehd1iUpaNM" From: Matthias Andree To: freebsd-ports@freebsd.org Message-ID: <5772E90C.6020908@gmx.de> Subject: Re: blanket portmgr approval vs. non-fixing changes References: <201606272021.u5RKLVhQ057899@slippy.cwsent.com> <20160628091709.pbvq7lekss2ql2en@ivaldir.etoilebsd.net> In-Reply-To: <20160628091709.pbvq7lekss2ql2en@ivaldir.etoilebsd.net> --7HfmuKT66Ri6JgaohPdCgU5Ehd1iUpaNM Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Am 28.06.2016 um 11:17 schrieb Baptiste Daroussin: > What you are asking is part of the blanket in particular when changing = things in > individual ports, we expect committers to have a look at pending PR (ye= s I know > I have been guilty of individual port change without sometime checking = about > pending PR which was wrong from my side) >=20 > For sweeping changes this is a bit different as when a change touches a= large > portion of the tree we can not expect the committer to have a look at e= ach > individual ports. Baptiste, to give you a provoking counter example: By that logic, I would not have been expected to notice that the bitcoin garbage insisted on db48, I could just have killed it off and moved the bitcoin ports onto db5. (That's stretching it a bit because there was Peter Wemm's objection to the DEPRECATED=3D tag on record alrea= dy.) Meaning that, in this thread: I beg to differ on sweeping changes. These do need a thorough review, and often a series of -exp runs, to keep the number of casualties low. If I had gone by this policy of sweeping changes, we'd nuked all DB2, DB3 and DB4 ports and had force moved all the bitcoin and openldap ports and whatnot onto db5 without consulting anyone, and I guess we'd heard a lot more screaming than with the approach I chose, meaning look at several dozen of ports before committing the breaking and sweeping changes. And I do think we should, opposite to what you are proposing, make the committer spend extra time for high-profile ports that entail sweeping changes to chase down the breaking change to, say, a library port. Cheers, Matthias --7HfmuKT66Ri6JgaohPdCgU5Ehd1iUpaNM-- --whFBI4hllivU89RVQv0PdCjCSuUpQRqFE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXcukXAAoJEOQSsVbv84VaKYEP/2noIt6iBu2fvaa+WJ5Uzouu P1P9Qny0MkAVQWIY0NJuNyuJWub00aKxK0eR8qmJnqM94N9GQFOP+WxJCSEJKlKC lrA/ODzSPpQhqQlqxlsjUdVRYVO6knyNbrYqiBby8Y7IY/ZaAXp7SqbAZTFym4PQ Lzbdx0wWeejO30dx5kPCLaaIs9CEdl5LTQQdU/D26xPCkI0caniknwISL+kAO2HO 1O/AiPHGLdMAf++j7/0G6DnR9ggHtMCL4Wovt6XhznitQT0U+0r+kNGbKZ2RsE2F qb1mx/Dv3eeucu/Nc9E4jcUgBKmvGD5xavu8/r3sMzdqHhjHy9NAW6u1A8sDegRS 9nwg59md5Y/Wf525zgTRoTYkDMlSsjFeEBEx+TBiEzVW5R+4I7tvce3EMRm3C+Ae ocaxw0Sbi5j/yqhxqyVQzXmmHq2I9P5EWtHDaacfldT72R9iMykrFZedpo+E19i8 8GvvT+O44q4q3jf/xrzgF77V4PjRYmlImcnokPHfcD452pTtcCBtoGJaRaYxY4Nq yjdi1jKi/7uOSfSe3KOYyR6C0dbrfSfC6BXphZ5gh9ild3R2bjEQxJPz4Ev8zVCD GjuDVI789qJvXS9Nk1c+oGFIXiUhamn98QswUgoDFMZA6OdBJ4G3cCIzo7BUn5sQ fECvc/CyPDYPamJtbGmJ =Qy22 -----END PGP SIGNATURE----- --whFBI4hllivU89RVQv0PdCjCSuUpQRqFE--