1 |
Hi, |
2 |
|
3 |
On 2019-09-04 20:59, Michał Górny wrote: |
4 |
> Devmanual is pretty clear on the fact that *all* new eclasses require ml |
5 |
> ^^^^^^^^^^^^^^^^^^^^^^^ |
6 |
> review *before* committing: |
7 |
|
8 |
I am also working on a new eclass so I looked up details regarding |
9 |
what's needed to add a new eclass recently. |
10 |
|
11 |
I must say that I disagree that it's *pretty* clear. |
12 |
|
13 |
> Adding and Updating Eclasses |
14 |
> |
15 |
> Before committing a new eclass to the tree, it should be emailed |
16 |
> ^^^^^^ |
17 |
> to the gentoo-dev mailing list with a justification and a |
18 |
> proposed implementation. Do not skip this step — sometimes a |
19 |
> better implementation or an alternative which does not require a |
20 |
> new eclass will be suggested. |
21 |
> |
22 |
> Before updating [...] |
23 |
> |
24 |
> The exceptions to this rule are per-package eclasses. For |
25 |
> ^^^^^^^^^^^^^^^^^^^^ |
26 |
> example, the apache-2 eclass is only used by the www-servers/apache |
27 |
> package, and thus does not typically require changes to be emailed |
28 |
> for review. |
29 |
|
30 |
In my case I am working on a new mysql eclass to outsource pkg_config |
31 |
function which is shared at least between dev-db/mysql and |
32 |
dev-db/percona-server (and maybe dev-db/mariadb). |
33 |
|
34 |
For this new eclass I would say it's a "per-package" eclass and would |
35 |
probably have skipped mailing list review, too. |
36 |
|
37 |
If you want to make it clear, change "should" to "must" and maybe |
38 |
clarify per-package exception and limit to update case if you believe |
39 |
that really *all* *new* eclasses must be send to mailing list. |
40 |
|
41 |
|
42 |
-- |
43 |
Regards, |
44 |
Thomas Deutschmann / Gentoo Linux Developer |
45 |
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 |