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
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
