Hi,

TL;DR: If a QA check is enforced by Portage for a reasonably long time,
does it constitute policy?  Or can it be changed unilaterally by Portage
team?


William Hubbs has recently attempted to remove one of Portage's QA
checks [1].  Not only we disagree on the change in question, we also
disagree on whether the original behavior constitutes policy.  I'd like
to bring the latter to wider discussion, without focusing on this
particular example.

FWIU, William's argument is that the QA team has not formally approved
such a policy (did QA even exist back then?), therefore it is not a
binding policy and can be changed through internal Portage patch review.

I disagree with this assessment.  This check that has been present
in Portage since at least 2005, and has reliably enforced specific way
of writing ebuilds (influencing e.g. gen_usr_ldscript() function). 
After 14 years, I believe this certainly counts as de-facto policy
and is not something to be changed lightly.  Such change needs to be
discussed on gentoo-dev@, and preferably supported by the research
of the original rationale.

This is not the only QA check in Portage that reliably affects how we
are writing ebuilds today, yet were never formally approved or written
down in developer documentation.  I think that this is partially simply
because there were never major disagreement about them, and since
Portage has reliably enforced them there were never any real need to
take them elsewhere.  I think they should be considered equally to well-
defined policies.

Hence, my question: should the policies implied by historical Portage
checks be considered official, and be changed with due diligence?  Or
should they be merely considered implementation details, and should
Portage developers make unilateral decisions on changing or removing
them?


[1] https://archives.gentoo.org/gentoo-portage-dev/message/6e4cfbb0ef9c36dc6511d4f2003cc458

-- 
Best regards,
Michał Górny