1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 24-07-2010 23:55, Alex Alexander wrote: |
5 |
> Hi, |
6 |
> |
7 |
> following is the Council Agenda proposal for the upcoming meeting on |
8 |
> Monday, July 26th. |
9 |
|
10 |
Alex, |
11 |
|
12 |
thanks for sending the agenda email. Just to speed up a few things in |
13 |
the meeting, let me present my position in the issues to be discussed. |
14 |
|
15 |
|
16 |
> * allow all members to show up (5 min) |
17 |
> ** vote ** |
18 |
> add --as-needed to default profile's LDFLAGS |
19 |
|
20 |
I'm ready to vote in favor of this proposal. |
21 |
|
22 |
> ** discuss / vote ** |
23 |
> - required-use: http://dev.gentoo.org/~ferringb/required-use.html |
24 |
|
25 |
I'm also ready to vote in favor of this proposal. I don't like the var |
26 |
name, but I won't delay the vote because of the name. |
27 |
|
28 |
> - review eclass removal policy |
29 |
> should it be 2 years since portage 2.1.4.4 went stable? |
30 |
|
31 |
I've raised this issue before and I maintain my position that there is |
32 |
no need to wait 2 years. |
33 |
If we drop the requirement and start dropping old and deprecated |
34 |
eclasses, and seeing as Portage has been saving eclasses on vdb and |
35 |
using them when uninstalling old packages for more than 2 years, we |
36 |
should have no issues. But if we do, as I've suggested before, we can |
37 |
just point users to the lastest version before removal on |
38 |
sources.gentoo.org so they can get it back and put it on their portage |
39 |
eclass dir. We can even add some official docs about this. |
40 |
So to me we can just drop the eclasses when they stop being useful. |
41 |
Having a policy requesting a warning email with some advance notice, |
42 |
does sound a safe approach, though. |
43 |
|
44 |
> - should there a policy about eclass API changes? |
45 |
|
46 |
I don't think we should limit developers and teams from updating |
47 |
eclasses. As some changes might have a larger impact than expected, in |
48 |
particular because of overlays, I think we should require a warning |
49 |
email with advanced notice. I'd say something like 15 days should be |
50 |
enough for larger changes. |
51 |
|
52 |
> - use of invalid DEPEND atom "EAPI_TOO_OLD" instead of calling die in |
53 |
> global scope on eclasses |
54 |
> http://archives.gentoo.org/gentoo-dev/msg_dee3aab5e8c840ed3fa4add9c7d74b97.xml |
55 |
> and replies |
56 |
|
57 |
As I recall from the discussion at that time, there was an argument |
58 |
about PMS not allowing die to be called in eclasses (in global scope?). |
59 |
I can live with both options, so I'm open to what the PM people have to |
60 |
say about it. |
61 |
|
62 |
> - mailing lists |
63 |
> should we post council agenda to -council? -dev? -project? |
64 |
|
65 |
I haven't set my mind on this one yet, but sending to council would |
66 |
allow easier retrieval at later dates. |
67 |
|
68 |
> some devs suggest we should cross-post to -dev and -council |
69 |
> but not everyone likes cross-posting as it can lead to fragmentation |
70 |
|
71 |
As I've replied in the project thread, I don't have anything against |
72 |
cross-posting for this. |
73 |
|
74 |
> Petteri suggested punting -council and using -project instead |
75 |
> * go through bugs assigned to council@g.o |
76 |
> * open floor: listen to developers |
77 |
> |
78 |
> --- |
79 |
> |
80 |
> If you have something urgent not included above, please reply to this |
81 |
> thread. |
82 |
> |
83 |
> --- |
84 |
> |
85 |
> Note that I haven't added a duration to anything but the rollcall. |
86 |
> |
87 |
> Instead, I recommend we follow a 10 minutes per topic rule. |
88 |
|
89 |
Let's try it. |
90 |
|
91 |
> If a topic's discussion passes the 10 minute mark without reaching a |
92 |
> decision, we move further discussion to the mailing lists. |
93 |
> |
94 |
> If we need to vote for that topic, we move it to the next agenda |
95 |
> with a *vote* flag. |
96 |
|
97 |
Sounds good.0 |
98 |
|
99 |
> Items with a *vote* flag cannot be moved a second time (unless there's |
100 |
> new data to consider), so they must be settled at that agenda's meeting, |
101 |
> in an attempt to avoid endless discussions. |
102 |
|
103 |
We should aim to ensure that votes do happen when an item is marked to |
104 |
be voted in a meeting. However it depends on council members being ready |
105 |
to vote at the meeting and on no new objection being raised during a |
106 |
meeting. |
107 |
If that fails, it might not be possible or desirable to have a vote when |
108 |
people don't know what they're voting on or have some doubts about a new |
109 |
objection. |
110 |
|
111 |
> What do you think? |
112 |
> |
113 |
|
114 |
- -- |
115 |
Regards, |
116 |
|
117 |
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
118 |
Gentoo- forums / Userrel / Devrel / KDE / Elections |
119 |
-----BEGIN PGP SIGNATURE----- |
120 |
Version: GnuPG v2.0.16 (GNU/Linux) |
121 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
122 |
|
123 |
iQIcBAEBAgAGBQJMS5ZwAAoJEC8ZTXQF1qEPqEkP/0ffJgc7AeAQo2o7o//X+z+K |
124 |
f7CKlSXDx5oAZl498txXqx+wns/Z+cj+v7fSPX71lPcTSv0f3VyHQ0KH79rE5Eyy |
125 |
oa77yzed9fQMDU+BIckexihnhBo7VCZkXbSf8DTigyR8kGRRthB3i33ulFP2LUzB |
126 |
rI6lewXQzdfcRspMfLXVUFwCaPMKJoVe0b2zU6u0K/iqUyoi2zbCatxHi/Cg3ipV |
127 |
cMIiJNkN81iALkF2OGIT+j27OLWBAf+K8WngyXIYrq1NQMb1gWetpmL8Pinf+2ry |
128 |
sUJ/jVe8sf+mu/PILmzEnPoDE+Rcmr6w9LEYVYHPLs70RmmTeEBmETWcRHZxoAcN |
129 |
DY30bhxBYcX6fSR2sU2SORiK57L4yxYoBIDQQF4hY/gIhDpI+IoAvLa6jNv8+rea |
130 |
tOByFOleXWp/tCPY8g86hinRIgPchzQly6fqxfYvOnre1erjFaN0S3Nef0xx6yWk |
131 |
etZDdkYwbeBKjXmdvs1iMV29BAp4QFrniTWa+Ff8e2XMxHWqTU9EySzd97WExZ4m |
132 |
HHGo5HUhGk2BOgHewCknOO7Ywr0/6ezQfdNuJcZrTqu3O+q/55ZtDnG4BGuW9sKD |
133 |
qF8NhbD3w1UkkX3qaq5/kJpk3XZEqE0t756PmtMTnwu3K7mgiAoXotv6U+0h25Ot |
134 |
RpufPXmgWi2C7BPlWHvy |
135 |
=8PTe |
136 |
-----END PGP SIGNATURE----- |