1 |
On Mon, Jul 05, 2021 at 11:42:36PM +0200, Ulrich Mueller wrote: |
2 |
> >>>>> On Mon, 05 Jul 2021, Aaron Bauman wrote: |
3 |
> |
4 |
> > On Mon, Jul 05, 2021 at 12:17:35PM +0200, Ulrich Mueller wrote: |
5 |
> >> In the past, the council had also banned EAPIs. However, that didn't |
6 |
> >> make much of a practical difference because an EAPI cannot be added |
7 |
> >> to eapis-banned in layout.conf unless all ebuilds are gone. Maybe we |
8 |
> >> should have a rule like the following instead: |
9 |
> >> "A deprecated EAPI is considered banned when the Gentoo repository |
10 |
> >> no longer contains any ebuilds using it." |
11 |
> |
12 |
> > Having the council vote to officially ban an EAPI does have |
13 |
> > practicality. The work done by those porting ebuilds, removing old |
14 |
> > packages, etc is hindered when other begin committing ebuilds |
15 |
> > deprecated but not banned. |
16 |
> |
17 |
> > I would ask that the council continue the official motions and votes |
18 |
> > to ban EAPI's prior to being "enforced" by tooling. This assists those |
19 |
> > doing the work and the QA team to stop people from committing. |
20 |
> |
21 |
> The point is that banning an EAPI doesn't have any noticeable effect. |
22 |
> For example, if you look at EAPI 0 (banned on 2016-01-10) and EAPI 4 |
23 |
> (banned on 2018-04-08), there's neither a cusp nor any change of slope |
24 |
> visible for the curves plotted here: |
25 |
> https://www.akhuettel.de/~huettel/plots/eapi.php |
26 |
> |
27 |
> Ulrich |
28 |
|
29 |
We have had the issue in the past. Taking 1 minute to vote on a ban of |
30 |
an EAPI in a council meeting is a minute task and enforces the goals of |
31 |
the project. |
32 |
|
33 |
Doesn't really matter to me either way. |
34 |
|
35 |
Cool data. |
36 |
|
37 |
-Aaron |