[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michael Everitt]

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 ..