On 05/09/19 20:47, Michał Górny wrote: > On Thu, 2019-09-05 at 15:14 +0200, Thomas Deutschmann wrote: >> On 2019-09-05 06:02, Michał Górny 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). >>>> >>>> For this new eclass I would say it's a "per-package" eclass and would >>>> probably have skipped mailing list review, too. >>> Everyone can skip as many paragraphs as they want, and then apply what's >>> said later to something said way earlier. >> Could you please stop adding any bad interpretation? >> >> 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. >> >> >>>> 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. >>> Submit a part. This is a community effort. Nitpicking and complaining >>> doesn't make things better. Fixing them does. >> 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). >> >> Maybe I am still missing something after reading >> https://devmanual.gentoo.org/eclass-writing/ 3 times... >> >> 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. >> > 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. > Pot meet Kettle ..
signature.asc
Description: OpenPGP digital signature