1 |
On Sun, Jul 25, 2010 at 01:42:08AM +0000, Jorge Manuel B. S. Vicetto wrote: |
2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
3 |
> Hash: SHA1 |
4 |
> |
5 |
> On 24-07-2010 23:55, Alex Alexander wrote: |
6 |
> > Hi, |
7 |
> > |
8 |
> > following is the Council Agenda proposal for the upcoming meeting on |
9 |
> > Monday, July 26th. |
10 |
> |
11 |
> Alex, |
12 |
> |
13 |
> thanks for sending the agenda email. Just to speed up a few things in |
14 |
> the meeting, let me present my position in the issues to be discussed. |
15 |
|
16 |
Good idea. |
17 |
|
18 |
> > * allow all members to show up (5 min) |
19 |
> > ** vote ** |
20 |
> > add --as-needed to default profile's LDFLAGS |
21 |
> |
22 |
> I'm ready to vote in favor of this proposal. |
23 |
|
24 |
Likewise. |
25 |
|
26 |
> > ** discuss / vote ** |
27 |
> > - required-use: http://dev.gentoo.org/~ferringb/required-use.html |
28 |
> |
29 |
> I'm also ready to vote in favor of this proposal. I don't like the var |
30 |
> name, but I won't delay the vote because of the name. |
31 |
|
32 |
Likewise. |
33 |
|
34 |
We haven't managed to find any decent alternatives for the name, |
35 |
so lets stick to that :) |
36 |
|
37 |
> > - review eclass removal policy |
38 |
> > should it be 2 years since portage 2.1.4.4 went stable? |
39 |
> |
40 |
> I've raised this issue before and I maintain my position that there is |
41 |
> no need to wait 2 years. |
42 |
|
43 |
Agreed. |
44 |
|
45 |
> If we drop the requirement and start dropping old and deprecated |
46 |
> eclasses, and seeing as Portage has been saving eclasses on vdb and |
47 |
> using them when uninstalling old packages for more than 2 years, we |
48 |
> should have no issues. But if we do, as I've suggested before, we can |
49 |
> just point users to the lastest version before removal on |
50 |
> sources.gentoo.org so they can get it back and put it on their portage |
51 |
> eclass dir. We can even add some official docs about this. |
52 |
> So to me we can just drop the eclasses when they stop being useful. |
53 |
> Having a policy requesting a warning email with some advance notice, |
54 |
> does sound a safe approach, though. |
55 |
|
56 |
I think we need a lastrite email at least 30 days prior to removal, |
57 |
to allow anyone using the eclass outside the tree to take action. |
58 |
|
59 |
> > - should there a policy about eclass API changes? |
60 |
> |
61 |
> I don't think we should limit developers and teams from updating |
62 |
> eclasses. As some changes might have a larger impact than expected, in |
63 |
> particular because of overlays, I think we should require a warning |
64 |
> email with advanced notice. I'd say something like 15 days should be |
65 |
> enough for larger changes. |
66 |
|
67 |
Agreed. As long as the developers/teams ensure that nothing breaks on |
68 |
the main tree after the changes, they should be free to do whatever they |
69 |
want. |
70 |
|
71 |
> > - use of invalid DEPEND atom "EAPI_TOO_OLD" instead of calling die in |
72 |
> > global scope on eclasses |
73 |
> > http://archives.gentoo.org/gentoo-dev/msg_dee3aab5e8c840ed3fa4add9c7d74b97.xml |
74 |
> > and replies |
75 |
> |
76 |
> As I recall from the discussion at that time, there was an argument |
77 |
> about PMS not allowing die to be called in eclasses (in global scope?). |
78 |
> I can live with both options, so I'm open to what the PM people have to |
79 |
> say about it. |
80 |
|
81 |
If it comes down to us, "die"ing looks better to me, EAPI_TOO_OLD seems |
82 |
too hackish. |
83 |
|
84 |
> > - mailing lists |
85 |
> > should we post council agenda to -council? -dev? -project? |
86 |
> |
87 |
> I haven't set my mind on this one yet, but sending to council would |
88 |
> allow easier retrieval at later dates. |
89 |
|
90 |
I think the proper place is -council. In my opinion each ML has its |
91 |
place and usage. That said, I don't really mind cross-posting to -dev to |
92 |
get greater visibility. |
93 |
|
94 |
> > some devs suggest we should cross-post to -dev and -council |
95 |
> > but not everyone likes cross-posting as it can lead to fragmentation |
96 |
> |
97 |
> As I've replied in the project thread, I don't have anything against |
98 |
> cross-posting for this. |
99 |
> |
100 |
> > Petteri suggested punting -council and using -project instead |
101 |
|
102 |
I like having a dedicated ML for council matters. |
103 |
|
104 |
> > * go through bugs assigned to council@g.o |
105 |
> > * open floor: listen to developers |
106 |
> > |
107 |
> > --- |
108 |
> > |
109 |
> > If you have something urgent not included above, please reply to this |
110 |
> > thread. |
111 |
> > |
112 |
> > --- |
113 |
> > |
114 |
> > Note that I haven't added a duration to anything but the rollcall. |
115 |
> > |
116 |
> > Instead, I recommend we follow a 10 minutes per topic rule. |
117 |
> |
118 |
> Let's try it. |
119 |
> |
120 |
> > If a topic's discussion passes the 10 minute mark without reaching a |
121 |
> > decision, we move further discussion to the mailing lists. |
122 |
> > |
123 |
> > If we need to vote for that topic, we move it to the next agenda |
124 |
> > with a *vote* flag. |
125 |
> |
126 |
> Sounds good.0 |
127 |
> |
128 |
> > Items with a *vote* flag cannot be moved a second time (unless there's |
129 |
> > new data to consider), so they must be settled at that agenda's meeting, |
130 |
> > in an attempt to avoid endless discussions. |
131 |
> |
132 |
> We should aim to ensure that votes do happen when an item is marked to |
133 |
> be voted in a meeting. However it depends on council members being ready |
134 |
> to vote at the meeting and on no new objection being raised during a |
135 |
> meeting. |
136 |
> If that fails, it might not be possible or desirable to have a vote when |
137 |
> people don't know what they're voting on or have some doubts about a new |
138 |
> objection. |
139 |
|
140 |
Indeed, my recommendation's goal is not to force random outcomes. I think |
141 |
of it as motivation for us to do our homework prior to meetings :) |
142 |
|
143 |
*new* objections or data could invalidate the *vote* flag, pushing the |
144 |
item to the next agenda (if no decision can be reached). |
145 |
|
146 |
> > What do you think? |
147 |
> > |
148 |
> |
149 |
> - -- |
150 |
> Regards, |
151 |
> |
152 |
> Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
153 |
> Gentoo- forums / Userrel / Devrel / KDE / Elections |
154 |
|
155 |
-- |
156 |
Alex Alexander -=- wired |
157 |
Gentoo Linux Developer -=- Council / Qt / KDE / more |
158 |
www.linuxized.com |