| 1 |
grobian 12/08/26 11:35:09 |
| 2 |
|
| 3 |
Added: 20120814-summary.txt |
| 4 |
Log: |
| 5 |
add 20120814 summary as acked by the council |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/proj/en/council/meeting-logs/20120814-summary.txt |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20120814-summary.txt?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20120814-summary.txt?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: 20120814-summary.txt |
| 14 |
=================================================================== |
| 15 |
Summary of Gentoo council meeting 14th August 2012 |
| 16 |
|
| 17 |
Roll call |
| 18 |
========= |
| 19 |
betelgeuse |
| 20 |
chainsaw |
| 21 |
grobian |
| 22 |
scarabeus |
| 23 |
ulm |
| 24 |
williamh |
| 25 |
|
| 26 |
absent |
| 27 |
------ |
| 28 |
dberkholz (receives slacker mark) |
| 29 |
|
| 30 |
|
| 31 |
EAPI5 features |
| 32 |
============== |
| 33 |
Due to holidays, the list of features for EAPI5 was announced only 2 |
| 34 |
days in advance of the meeting. This gave little time for Council |
| 35 |
members to prepare for votes. |
| 36 |
Therefore a vote was conducted if voting on EAPI5 features in this |
| 37 |
meeting was deemed suitable. |
| 38 |
|
| 39 |
The Council voted unanimously to postpone voting on EAPI5 features. |
| 40 |
|
| 41 |
The list of features for EAPI5 were outlined by ulm in |
| 42 |
http://thread.gmane.org/gmane.linux.gentoo.project/2101/focus=2115 |
| 43 |
Since many of these features appear not to be implemented in Portage, a |
| 44 |
discussion on their implementation is called for by the Council. The |
| 45 |
Council stressed that it prefers to vote on EAPI5 features that can and |
| 46 |
will be implemented within a short timeframe, say 1 month. |
| 47 |
|
| 48 |
|
| 49 |
Open bugs with Council involvement |
| 50 |
================================== |
| 51 |
There are currently no open bugs. |
| 52 |
|
| 53 |
|
| 54 |
Open floor |
| 55 |
========== |
| 56 |
scarabeus suggested the change "dev should use latest eapi when bumping" |
| 57 |
to "dev must use latest eapi when bumping if not forbidden by eclasses". |
| 58 |
He was asked to bring it up on the mailing lists, to get a better |
| 59 |
definition of when what EAPI should be used. |
| 60 |
|
| 61 |
ulm raised deprecation of EAPI 1 on request of patrick. Arfrever argued |
| 62 |
that backwards compatability is not an issue here, and that it can |
| 63 |
greatly reduce code size/maintenance of eclasses when EAPI0 and EAPI1 |
| 64 |
are removed. It was questioned whether removal of an EAPI really brings |
| 65 |
that much benefits. It seems eclasses can drop support for EAPIs, if |
| 66 |
all consumers don't use them, which does not require complete removal of |
| 67 |
the EAPI. It appears some packages use build-systems that require |
| 68 |
EAPI1. |
| 69 |
|
| 70 |
|
| 71 |
Next meeting date |
| 72 |
================= |
| 73 |
11 September 2012, 19:00 UTC |
Archives