Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Tobias Scherbaum]

Tiziano Müller wrote:
> EAPI 3: Short discussion of the progress
> ----------------------------------------
>
> zmedico will provide an update on the progress of the implementation. Short
> discussion of problems and implementation decisions if needed.

Guess that's a rather short topic. Nothing to discuss for us.

> Default ACCEPT_LICENSE
> ----------------------
> Goal: A possible default value for ACCEPT_LICENSE has been proposed. Decide
> whether that's ok. What happens to the X11 license files (one for each app)?

The proposed default looks good to me. Besides that the X11 license
stuff needs to get sorted out finally (if it hasn't been already -
MIT?).

> Bash-4 in EAPI-3
> ----------------
> Goal: A request has been made to allow bash-4.0 features in EAPI-3. Decide
> first whether or not to open the EAPI-3 feature list at all.

I'm against re-opening the feature list for EAPI-3, let's get EAPI-3
finally implemented and put this on the agenda for EAPI-4. I don't see
the pressure to allow bash-4.0 stuff now.

> Define EAPI development/deployment cycles
> -----------------------------------------
>
> Goal: Start discussion about EAPI development/deployment. For example:
> Collect problems of eapi introductions in the past, like reverting
> ebuilds to former eapis to get them stable, not waiting for the pm
> support a certain eapi before requesting stable keywords for ebuilds
> using the new eapi, .... Collect problems of EAPI development like
> feature-freeze, late feature removals (due to implementation problems).
> Eventually develop a lightweight EAPI development model.

The main "problem" is that there is no deployment process for newer
EAPIs specified right now. In the past we had something like "there must
be two releases (stage sets) including a Portage version supporting new
features" before people were allowed to use new features in tree. We had
a timeframe of something about a half year between introduction of new
features and usage of them. At least in theory.

While having such a longer timeframe would make the deployment of new
EAPIs somewhat easier (especially the special cases when newer versions
of a package were migrated to a shiny new EAPI which isn't supported by
a stable Portage yet and there's a need for quick versions bump due to
security bugs) I think something inbetween that old process and the
currently used one would be useful. For example something like: New
EAPIs can be used in tree once a Portage version supporting that
specific EPAI has been marked as stable plus a transition period of -
say - 4 weeks after the Portage version has been made stable on the
first architecture.

And for EAPI development: I did dislike the google spreadsheet which has
been used for EAPI-3 and don't think this has proved to be useful. If we
do opt for any public collaboration development process (instead of say
some file in $SCM) we should use a simple Wiki and be done. Tracking
changes made to that document is a requirement from my pov. Using bugs
for each feature and an EAPI tracker bug would be another possible way
to organize this.

  Tobias