1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
\summary{2010}{12}{18}
\agendaitem{slacking arches}
\index{arches!slacking}
This subject was proposed by scarabeus. As he wasn't around, the remaining
council
members shifted the focus to making sure there is enough relevant hardware available
to developers to allow arch team work and questioned whether emulation could help
on this, at least for non core parts on a trial basis.
Roy (NeddySeagoon) asked what hardware is needed and whether there should be a
funding application to the Foundation. Tony mentioned some hardware that could
be used by the ppc64 team and Jorge noted that mainstream arches such as amd64
and x86 may also want to make a request.
Finally, there was a mention that if council cared about this issue, one member
could talk to arch teams to determine the hardware requirements and that we could
take this opportunity to consider automated test boxes and rethink the boxes for
the weekly builds. This issue was sent back to the ml for further debate.
\agendaitem{la files removal status / progress}
\index{.la files}\index{package!sys-devel/libtool}
Jorge mentioned that portage-2.1.9* is now marked stable, but that he failed to
take care of the documentation and or submitting a news item proposal based on
the previous proposal made by Diego (flameeyes). He suggested the other council
members that the council could either set a deadline to get a news item submitted
for review in the dev ml after which the la files removal "embargo" would be
dropped or just drop the "embargo" immediately and deal with the consequences.
After some discussion there was a vote on "the council will drop the "embargo" on
la file removal if no one submits to the dev ml a news item proposal about this
issue before 2359 UTC next Wednesday". There were 3 yes votes and 2 no votes on
this proposal.
\agendaitem{Arfrever's suggestions for EAPI 4}
\index{EAPI!4}\index{pkg_required_use}\index{GLEP!55}
Reference: \agoref{gentoo-dev}{bec5db8373fca0271fcadf0cd55724e8}
After some confusion caused by Jorge introducing the pkg_required_use topic
during the discussion of this topic, the council members agreed to go over each
of the points in Arfrever's email. Brian took the occasion to go over
each of
the points to finally get the discussion about them on record.
Problem \#1: USE flags cannot contain "." characters.
Brian argued that having "." on use flags is simply an aesthetic issue. Furthermore,
use flags are used all over the tree and this could cause backward compatibility
issues. Thus this would provide a minor gain, but would require much pain.
Even though the council members agree that it would be possible to find ways to allow
for the use of "." in use flags and that the change itself would be welcome, they
agreed that this should only be addressed as part of a major restructuring of use
flags, like the introduction of use groups. Petteri opened
\bug{349021} for this.
The council voted against the proposed solution for this problem with 5 votes no.
Problem \#2: Files in profiles cannot use features from newer EAPIs.
Brian argued that Arfrever's proposal for "-\$\{EAPI\}"
extension files is a nightmare
and that it relied on developers to get things right across multiple eapi versions.
Jorge and Alex argued that this proposal is another variation of GLEP55 and that
they have expressed their dislike for it before.
The council voted against both proposed solutions for this problem with 5 votes no
for the 1st solution and 4 votes no and 1 defer to ml for the 2nd solution.
During this discussion there was a "detour" into the issue of migrating the EAPI of
the base profiles, moving trouble files like package.mask to real profiles and how
to ensure a clean upgrade path for old installs. Alex talked about an automated
incremental process with switches of rsync sources over time and Brian mentioned the
use of repository format markers. This discussion was pushed back to the ml.
Problem \#3: repoman doesn't allow stable packages to have optional
dependencies on unstable
packages (usually until these packages are stabilized).
Brian argued that both proposed solutions for this problem would cause a maintenance
"hell" and would have a noticeable repoman run-time impact. Petteri noted he saw a
problem needing a solution in here and Jorge argued that the solutions presented need
a debate but that they are not tied to the presented problem.
During the discussion Petteri asked about a 3rd option, unstable use flags, and Jorge
argued that the separate profiles for stable / unstable tree could make sense if we got
back to the idea of moving KEYWORDS out of ebuilds.
In the end the council voted with 5 no votes for both solutions presented in point 3
to be part of the EAPI-4 specification.
\agendaitem{pkg_required_use}
\index{pkg_required_use}
After a first attempt to discuss this during the previous point, the council addressed this
issue after Ulrich (ulm) recalled he requested it to be added to the topic, which Jorge forgot
to do.
Following some debate about this issue, including requested feedback from both Zac (zmedico)
and Brian, the council voted on having EAPI-4 introduce a pkg_required_use function to be
called by the PM when it can't fulfill the required_use constraints with 4 no votes and 1
yes vote. The council members accepted having an EAPI-4.1 with pkg_required_use if / when
there is a need for it in the tree.
The council also expressed the desire to get a final vote on EAPI-4 before the end of the
year. Petteri will propose a schedule to get EAPI-4 voted through email.
\agendaitem{Open bugs}
As the meeting lasted over 2 hours, the productivity was becoming low and Petteri had to
leave, the review of the open bugs was pushed for next meeting.
\agendaitem{Open floor - listen to the community}
No issue was brought to the attention of the council at this meeting.
|
GitWeb