Following the recent events, I would like to request a vote upon an explicit policy disallowing splitting ebuild code between multiple non-standard files. I would suggest a wording alike: == The ebuild code must be wholly contained within the .ebuild and .eclass files, as defined by the PMS. It is explicitly forbidden to split the ebuild code into external files that are loaded via source, eval or any other possible method. == The rationale: a. We should aim for high maintainability of ebuilds, and therefore avoid needless complexity or surprise. Outsourcing ebuild code to non-standard locations is against the principle of least surprise, introduces unnecessary complexity and makes the ebuilds harder to maintain for others. This effectively discourages others from contributing and results in a high bus factor which is certainly undesirable for core system packages. b. The non-obvious code locations are usually not accounted for in various tools and developer practices. For example, the common attempts of grepping ebuilds and eclasses for function calls will not catch the calls occurring within external files. c. Some of the repoman checks are applied to .ebuild files only. By moving the code out of ebuilds to non-standard files, the checks do not catch issues correctly. While this is currently true of eclasses as well, this issue can be solved to some degree, whereas we can't reliably make repoman find and scan any ebuild code in FILESDIR and other locations. It should be noted that: a. This policy does not collide conceptually with a potential future EAPI extension providing per-ebuild eclasses. The point is, however, that such an extension should be well-defined in the PMS. b. The non-standard code locations are only used by a few packages (3, if I recall right) and provide no specific advantages over the standard locations (ebuilds and eclasses). Please discuss/vote.
Would this policy apply to new ebuilds only, or also to existing ones?
(In reply to Ulrich Müller from comment #1) > Would this policy apply to new ebuilds only, or also to existing ones? Either way works for me. I'd say applies immediately to new ebuilds, and we phase out the existing uses. However, we're doing the latter for other bugs anyway, so I don't think that to be a problem.
Vote: Yes Apply to: whole tree, not just new ebuilds
I vote yes.
Let's do this keywording-like. I've CC-ed all members who haven't voted yet. Please vote and remove yourself from CC once done ;-).
I'd prefer a rewording "The ebuild code must be wholly contained by files that are defined by the PMS, which is as of $date .ebuild and .eclass files." Saves us from rewording the policy just in case PMS changes and adopts eblits-ng or something else. Otherwise: Aye.
Aye, new ebuilds only.
Yes, New ebuilds.
Yes, for new ebuilds.
For completeness, my vote: yes, to all.
Yes, to all, or just moving forward
Yes.
I vote yes to all.
I hope Tommy doesn't mind if I call the time out after 10 days and summarize the results without his vote. We have a definitive majority, and his vote would not change the result. So to summarize: a. 11 out of 12 QA members voted, b. The 11 QA members unanimously approved the motion for new ebuilds, c. 7 out of 11 members approved the motion for existing ebuilds. This considered, the following policy is now in effect (wording by mrueg): === The ebuild code must be wholly contained in files that are defined by the PMS, which as of 2017-03-24 are .ebuild and .eclass files. It is explicitly forbidden to split the ebuild code into additional files that are loaded via source, eval or any other possible method. === The policy applies both to new and existing ebuilds. The two known violations are already being fixed today as part of #586422 and #586424.
Added to the wiki: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Ebuild_code_must_be_wholly_contained_in_PMS_files
...and announcement sent to gentoo-dev-announce@ with cross-post to gentoo-dev@.
