Gentoo Archives: gentoo-project

From: Sam James <sam@g.o>
To: Ulrich Mueller <ulm@g.o>
Cc: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Call for agenda items - Council meeting on 2022-02-13
Date: Wed, 09 Feb 2022 07:30:26
Message-Id: 20220209073011.5d2b7f77@zen
In Reply to: Re: [gentoo-project] Call for agenda items - Council meeting on 2022-02-13 by Ulrich Mueller
1 On Wed, 09 Feb 2022 08:18:07 +0100
2 Ulrich Mueller <ulm@g.o> wrote:
3
4 > >>>>> On Wed, 09 Feb 2022, Sam James wrote:
5 >
6 > > On Sat, 05 Feb 2022 08:37:17 +0100
7 > > Ulrich Mueller <ulm@g.o> wrote:
8 >
9 > >> As I had announced in the January meeting, I'd ask the Council to
10 > >> pre-approve the list of features for EAPI 9, as listed here:
11 >
12 > > Please post a statement of intent / RFC to the gentoo-dev ML to
13 > > solicit feedback and give others time to make proposals too.
14 >
15 > There is no special time period for making such proposals; future EAPI
16 > bugs can be filed at any time. Preferably, they should be filed early,
17 > because we've had very bad experience with including last-minute
18 > features.
19
20 Agreed on the latter point, but this doesn't mean a simple courtesy
21 notice would be problematic.
22
23 Not everyone will be aware EAPI 9 is in the works; in particular, it's
24 useful for our downstreams to know and possibly suggest any improvements
25 given they're not likely to be as aware of day-to-day developments in
26 Gentoo, and it's useful as a final poke to notify people that if indeed
27 they feel something should be in the next EAPI (or "soon"), they should
28 file a bug and so on.
29
30 I am not saying any such requests must be accepted for EAPI 9. But
31 engaging with the community with a notice isn't a bad thing?
32
33 Someone could easily think the next EAPI is years away and therefore
34 feel no urgency to flesh out their (possibly very simple) idea or
35 improvement.
36
37 >
38 > > If I've missed such an email, my apologies (as I'm currently on
39 > > another machine than usual for mail), but I didn't see one when I
40 > > looked.
41 >
42 > > I do applaud this moving-a-bit-quicker / agile approach, but
43 > > it's important we give a chance for people to raise features
44 > > they've been looking to land, and so on.
45 >
46 > That is not how it works. The workflow is documented here:
47 > https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification/Future_EAPI_process
48 >
49
50 I don't see anything on that page which precludes giving the gentoo-dev
51 mailing list (so our developers & the general community) a heads up
52 on an upcoming process.
53
54 best,
55 sam

Replies