From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 1D7FA138334 for ; Thu, 5 Sep 2019 19:47:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7B6DEE0784; Thu, 5 Sep 2019 19:47:18 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 28D08E077A for ; Thu, 5 Sep 2019 19:47:17 +0000 (UTC) Received: from pomiot (c134-66.icpnet.pl [85.221.134.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id E662734ACFF; Thu, 5 Sep 2019 19:47:15 +0000 (UTC) Message-ID: <2f49bf393b04f1b514817317c2ea12f8e8e586df.camel@gentoo.org> Subject: Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/ From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Thu, 05 Sep 2019 21:47:11 +0200 In-Reply-To: <7dd9f947-b3b1-a685-29df-0a59a19ebcbe@gentoo.org> References: <1567619929.63486fef43c2e0dee3b4128db18fd1a6b4bf9381.tupone@gentoo> <6221fceb9ac4f3451a3a43e39141102f489a830d.camel@gentoo.org> <1860939b-1751-061d-c593-59deb20f05e7@gentoo.org> <7dd9f947-b3b1-a685-29df-0a59a19ebcbe@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-apfIorRlYiwZT5gHPNxw" User-Agent: Evolution 3.30.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: 725ad177-aad9-4760-bb04-dcfb9a7dca85 X-Archives-Hash: 01fef54b6dcde023cc609cecf04ce581 --=-apfIorRlYiwZT5gHPNxw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2019-09-05 at 15:14 +0200, Thomas Deutschmann wrote: > On 2019-09-05 06:02, Micha=C5=82 G=C3=B3rny wrote: > > > In my case I am working on a new mysql eclass to outsource pkg_config > > > function which is shared at least between dev-db/mysql and > > > dev-db/percona-server (and maybe dev-db/mariadb). > > >=20 > > > For this new eclass I would say it's a "per-package" eclass and would > > > probably have skipped mailing list review, too. > >=20 > > Everyone can skip as many paragraphs as they want, and then apply what'= s > > said later to something said way earlier. >=20 > Could you please stop adding any bad interpretation? >=20 > That was a serious question. For you, it's pretty clear. I am showing > you, that for me, it isn't pretty clear. When you believe I skipped > important lines in my quote please outline what I have missed and I will > take the blame. >=20 >=20 > > > If you want to make it clear, change "should" to "must" and maybe > > > clarify per-package exception and limit to update case if you believe > > > that really *all* *new* eclasses must be send to mailing list. > >=20 > > Submit a part. This is a community effort. Nitpicking and complaining > > doesn't make things better. Fixing them does. >=20 > Sure, but at the moment *you* are the one who are saying it's a MUST. I > don't understand it that way and I am fine with my understanding that > per-package eclasses *should* but *must not* get reviewed through > mailing list. In other words I am asking you to show us where it's > written that *all* *new* eclasses *must* get reviewed through mailing > list. I cannot find something like that in current devmanual (the link > you showed). >=20 > Maybe I am still missing something after reading > https://devmanual.gentoo.org/eclass-writing/ 3 times... >=20 > In case I am not missing anything I suggested to improve devmanual in > case you believe this should be a hard requirement. Because at the > moment I don't believe it should be a hard requirement, *I* will not > propose any changes. >=20 So to summarize, instead of working together in order to follow a well- established policy, you prefer to do whatever you find convenient at the moment, as long as you justify it by finding some document whose wording does not perfectly prevent you from bending the policy? Yes, that sounds like a very good attitude for a Council member. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-apfIorRlYiwZT5gHPNxw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl1xZj9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA7rnwf/RbqeECkvgJit8ArZ+GDbLLfcM/3FHM4jZ7jMA6gzEcsSw7GTU5uMDYAf E/Now8WiuMSZmsNclPSfugymvGb+jH/g7GvDbiJdBzW/kn7PnzbOMf0jhHh6PsI7 gU9r5TtcP9/fJXzgpzpsDuwBpqIXw+KgfbYZiGINVRjoVH/WGRaNZrJAF5OW50Rg ergDNNQ5MjtDI/un4w2pvarr1/RGPpIumMcNMBU0C4V/TLnAco+YdguvXZ93JX/E 7LCZljGkERLrcfWpfVKaY9wNDUMY2GurShMUQPBMThea74k8MQ8XNC31IJU/zRRq /kOn/+SjFxOIRyv0Z+jwD1/Gh1+oGA== =FKXc -----END PGP SIGNATURE----- --=-apfIorRlYiwZT5gHPNxw--