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
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
\summary{2010}{12}{18}
Agenda call: ---
Agenda announcement: \agoref{gentoo-project}{30e33692f20e77c86977cc52e14ab9b5}
\agendaitem{slacking arches}
\index{arches!slacking}\index{arches!hardware}\index{foundation}
This had been proposed by \dev{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.
\dev{neddyseagoon} asked what hardware is needed and whether there should be a
funding application to the Foundation. \dev{chainsaw} mentioned some hardware
that could be used by the ppc64 team, and \dev{jmbsvicetto} noted that
mainstream arches such as amd64 and x86 may also want to make a funding 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 mailing list for further
debate.
\agendaitem{la files removal status / progress}
\index{.la files}\index{package!sys-devel/libtool}
\index{package!sys-apps/portage}
\dev{jmbsvicetto} mentioned that portage-2.1.9* is now marked stable, but that
hadn't taken care of the documentation and or submitting a news item proposal
based on the previous proposal made by \dev{flameeyes} so far. He suggested to
the other council members that the council could either set a deadline to get a
news item submitted for review on the gentoo-devel mailing list after which the
.la files removal "embargo" would be dropped or that the "embargo" could just be
dropped immediately, dealing with the consequences afterwards.
\vote{The council will drop the "embargo" on .la file removal if no one submits
to the gentoo-devel mailing list a news item proposal about this issue before
23:59 UTC next Wednesday.}{Passed with 3 yes votes and 2 no votes.}
\agendaitem{Arfrever's suggestions for EAPI 4}
\index{EAPI!4}\index{GLEP!55}
Reference: \agoref{gentoo-dev}{bec5db8373fca0271fcadf0cd55724e8}
After some confusion caused by \dev{jmbsvicetto} introducing the
pkg_required_use topic (see next section below) here, the council members agreed
to go over each of the points in \dev{arfrever}'s email. \dev{ferringb} took the
occasion to go over each of the points to finally get the discussion about them
on record.
\index{use flags!dot character}
Problem \#1: USE flags cannot contain "." characters.
\dev{ferringb} 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, as tracked in
\bug{311795}, 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.\footnote{Does anyone remember what ``use groups'' were supposed to be?}
\dev{betelgeuse} opened \bug{349021} for this.
The council voted against the proposed solution for this problem with 5 no
votes.
Problem \#2: Files in profiles cannot use features from newer EAPIs.
\index{EAPI suffix}\index{EAPI!usage in profiles}
\dev{ferringb} argued that \dev{arfrever}'s proposal for "-\$\{EAPI\}" extension
files in the profiles is a nightmare and that it relied on developers to get
things right across multiple EAPI versions. \dev{jmbsvicetto} and \dev{wired}
argued that this proposal is another variation of \glep{55} and that they have
expressed their dislike for it before.
The council voted against "-\$\{EAPI\}" extension files in the profiles with 5
no votes.
The proposal to create new profiles using EAPI="4", remove all older profiles
from profiles.desc so that repoman doesn't check them anymore, and deprecate the
older profiles was also defeated with 4 no votes and 1 vote to defer to the
mailing list.
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. \dev{wired} talked
about an automated incremental process with switches of rsync sources over time
and \dev{ferringb} mentioned the use of repository format markers. This
discussion was pushed back to the mailing list.
Problem \#3: repoman does not allow stable packages to have optional
dependencies on unstable packages (usually until these packages are stabilized).
\index{use.unsatisfiable}\index{package.use.unsatisfiable}
\index{profiles!per stable status}
\dev{ferringb} argued that both proposed solutions for this problem would cause a
maintenance "hell" and would have a noticeable repoman run-time impact.
\dev{betelgeuse} noted he saw a problem needing a solution in here, and
\dev{jmbsvicetto} argued that the solutions presented need a debate but that
they are not tied to the presented problem of python versions.
\index{use flags!unstable}\index{optional dependencies}
During the discussion \dev{betelgeuse} asked about a third option, unstable use
flags, and \dev{jmbsvicetto} argued that 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}\index{REQUIRED_USE}
Reference: \agoref{gentoo-project}{3463900fd31abf9894c4c07e1a4a9978}
After a first attempt to discuss this during the previous point, the council
addressed this issue after \dev{ulm} recalled he requested it to be added to the
agenda, which \dev{jmbsvicetto} forgot to do.
Following some debate about this issue, including requested feedback from both
\dev{zmedico} and \dev{ferringb}, 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. \dev{betelgeuse} 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
\dev{betelgeuse} had to leave, the review of the open bugs was pushed to the
next meeting.
\agendaitem{Open floor}
No items were brought to the attention of the council at this meeting.
|
GitWeb