1 |
jmbsvicetto 11/11/12 20:56:25 |
2 |
|
3 |
Added: 20111108.txt |
4 |
Log: |
5 |
Added log for the 20111108 meeting. |
6 |
|
7 |
Revision Changes Path |
8 |
1.1 xml/htdocs/proj/en/council/meeting-logs/20111108.txt |
9 |
|
10 |
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20111108.txt?rev=1.1&view=markup |
11 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20111108.txt?rev=1.1&content-type=text/plain |
12 |
|
13 |
Index: 20111108.txt |
14 |
=================================================================== |
15 |
20:00 <@ulm> O.K., let's start |
16 |
20:00 <@ulm> roll call |
17 |
20:01 * hwoarang here |
18 |
20:02 <@ulm> Betelgeuse, chainsaw, dberkholz, grobian, jmbsvicetto? |
19 |
20:02 <@grobian> here |
20 |
20:02 <@grobian> sorry |
21 |
20:02 <@grobian> connection is very flacky |
22 |
20:03 <+dberkholz> 18:59 < dberkholz+> Calchan is gonna proxy for me at tuesday's meeting |
23 |
20:03 <+dberkholz> i'm leaving for the airport in a few minutes |
24 |
20:03 <@ulm> k |
25 |
20:03 <+dberkholz> in case he doesn't pop his head up for any reason, i'll go for identical msgs and on the api issue, at least a 90-day wait before breakage, or no breakage at all |
26 |
20:03 <@jmbsvicetto> pong |
27 |
20:04 <@jmbsvicetto> here |
28 |
20:04 <@jmbsvicetto> ulm: Do you need me to call anyone? |
29 |
20:04 <@ulm> jmbsvicetto: betelgeuse, calchan, and chainsaw are still missing |
30 |
20:06 <@ulm> !seen chainsaw |
31 |
20:06 < willikins> ulm: Chainsaw was last seen 2 hours, 51 minutes and 55 seconds ago, quitting IRC (Quit: Leaving) and a moment before saying "idella4: I'm afraid we can't let users run the entire show though. See what Zorry thinks." in #gentoo-dev |
32 |
20:06 <@ulm> anyway, who's logging? |
33 |
20:06 <@jmbsvicetto> ulm: give me a minute and I'll call Petteri and Tony |
34 |
20:08 * Betelgeuse fails |
35 |
20:08 <@jmbsvicetto> Betelgeuse should be around in a minute |
36 |
20:10 <@jmbsvicetto> calling chainsaw |
37 |
20:11 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has joined #gentoo-council |
38 |
20:11 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ |
39 |
20:11 * Chainsaw salutes jmbsvicetto |
40 |
20:11 < Calchan> sorry, got delayed in a meeting |
41 |
20:11 <@jmbsvicetto> Heya Tony :) |
42 |
20:12 <@ulm> so Calchan (dberkholz's proxy) still missing, but let's start |
43 |
20:12 <+dberkholz> ulm: look up 2 lines =P |
44 |
20:12 <+dberkholz> Calchan: ok, i'll tag off with you then. |
45 |
20:12 <@ulm> oops, sorry |
46 |
20:12 <@ulm> all there |
47 |
20:12 <@ulm> who's logging? |
48 |
20:12 <@jmbsvicetto> ulm: I have logs |
49 |
20:13 <@ulm> First topic: ChangeLog and commit messages |
50 |
20:13 <@ulm> Do we require identical ChangeLog entries and commit messages? |
51 |
20:13 <@grobian> no |
52 |
20:14 <@jmbsvicetto> no |
53 |
20:14 <@ulm> no |
54 |
20:15 <@hwoarang> makes no sense so no |
55 |
20:15 < Calchan> it would be a yes from here |
56 |
20:15 <@Chainsaw> No |
57 |
20:15 <@jmbsvicetto> but it's up to the developer using different messages to ensure the messages are appropriate. So using the ability to have different messages to write "stupid messages" on ChangeLogs is not ok |
58 |
20:15 <@grobian> obviously |
59 |
20:15 <@Chainsaw> If I correct a spelling error in a Changelog, the commit message should be "fixing typo balh -> blah". |
60 |
20:15 <@Chainsaw> Not the whole message again. |
61 |
20:15 <@ulm> Betelgeuse? |
62 |
20:16 <@Betelgeuse> ulm: I agree with Chainsaw that it shouldn't be a strict rule. Preferred whenever it makes sense. |
63 |
20:16 <@ulm> jmbsvicetto: I think everybody agrees on that |
64 |
20:17 <@jmbsvicetto> ulm: It seems it's best we make it clear |
65 |
20:18 <@ulm> hm, how about "it's recommended to use the same message for changelog and as commit message"? |
66 |
20:18 <@grobian> recommended fine with me, basically what repoman commit now does |
67 |
20:18 <@jmbsvicetto> ulm: sorry, what I meant was that it was best we made a comment like I did above so there's no doubt about our goal |
68 |
20:19 <@ulm> anyone can come up with a good wording? |
69 |
20:19 <@jmbsvicetto> ulm: I'm fine with stating as recommended or just adding a note that developers are still responsible for the messages used and that we still expect changelogs to have appropriate messages |
70 |
20:19 <@grobian> usual rules on writing useful changelog and commit messages apply? |
71 |
20:19 <@jmbsvicetto> grobian: seems good to me |
72 |
20:20 <@grobian> s/useful/appropriate/ |
73 |
20:20 <@ulm> grobian: yes, I think that's fine |
74 |
20:20 <@grobian> I like that more |
75 |
20:20 < Calchan> ulm, "Please use the same commit and Changelog message whenever you do not have a strong reason of doing otherwise" how's that? |
76 |
20:20 <@ulm> and short ;) |
77 |
20:20 <@grobian> Calchan: that's a different message, IMO |
78 |
20:21 <@grobian> I have no problem with people doing ugly [myebuild] version bump commit messages, while having "Version bump." as changelog message |
79 |
20:21 < Calchan> grobian, I was just suggesting at ulm's request, anything else is good with me if it's good with you |
80 |
20:21 <@jmbsvicetto> Calchan: one could argue that would still allow to use the "ignore this" messages for changelog. |
81 |
20:22 <@grobian> Calchan: of course, was just explaining my opposal ;) |
82 |
20:22 <@ulm> So, "Usual rules on writing appropriate ChangeLog and commit messages apply."? |
83 |
20:22 <@grobian> it's off-topic, but basically we want to repeat that we want to see appropriate messages being used |
84 |
20:22 <@grobian> ulm: +1 |
85 |
20:22 <@ulm> Can everyone live with this? |
86 |
20:23 < Calchan> ulm, wfm |
87 |
20:23 <@Betelgeuse> I would rather spell out what "Usual rules" mean |
88 |
20:23 <@ulm> Betelgeuse: Then suggest a wording. ;) |
89 |
20:24 < Calchan> or point/link to them |
90 |
20:24 <@grobian> Betelgeuse: as long as we avoid "common sense", since that seems not to be a shared thing |
91 |
20:24 <@jmbsvicetto> what about: "developers are free to use different messages for ChangeLog and commit, but they're responsible for the messages used and the council still expects appropriate messages to be used" ? |
92 |
20:25 <@grobian> + for both |
93 |
20:25 <@grobian> ? |
94 |
20:25 <@Betelgeuse> http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html |
95 |
20:25 <@Betelgeuse> and jmbsvicetto's wording is fine |
96 |
20:25 <@grobian> ohw, nice page |
97 |
20:26 <@ulm> +1 for jmbsvicetto's wording |
98 |
20:26 < Calchan> jmbsvicetto, I like the fact that this rules out the fact that devrel may be involved in such situations, not entirely sure it's a good thing though |
99 |
20:26 <@grobian> Can we add Betelgeuse's link to that blub too? |
100 |
20:26 <@ulm> grobian: yep |
101 |
20:27 <@jmbsvicetto> +1 on adding the link |
102 |
20:27 <@grobian> ok, jmbsvicetto's + Betelgeuse's link for me then |
103 |
20:27 <@grobian> :) |
104 |
20:28 <@ulm> o.k., that's 4 out of 7 at least |
105 |
20:28 <@ulm> next topic? |
106 |
20:28 <@grobian> ok |
107 |
20:29 <@jmbsvicetto> sure |
108 |
20:29 <@ulm> Eclasses policy |
109 |
20:29 <@ulm> Are developers allowed to remove functions from eclasses, or change the API in general? |
110 |
20:29 <@ulm> http://archives.gentoo.org/gentoo-project/msg_87aecc20ce7030e321ab2db6c90f36cc.xml |
111 |
20:30 <@grobian> I tend to think the gx86 tree should be fine with it, we cannot really take all existing overlays into account |
112 |
20:30 < Calchan> not without reasonable warning time, eg 90 days |
113 |
20:30 <@Betelgeuse> I don't know if you noticed but vapier has been doing it with less than a days notice |
114 |
20:30 <@grobian> I'd suggest normal 30 days warning |
115 |
20:31 <@hwoarang> if nobody uses them what is the problem? |
116 |
20:31 <@grobian> sure, but if there are no consumers, why not remove some thing? |
117 |
20:31 < Calchan> hwoarang, overlays may still be using them |
118 |
20:31 <@ulm> grobian: Plus posting the diff to -dev ML |
119 |
20:31 <@grobian> ulm: agreed |
120 |
20:31 <@jmbsvicetto> I think we shouldn't make things harder than needed, so we should be able to change API. A reasonable advanced notice is desirable, though. I'd say 30 or 60 days |
121 |
20:31 <@hwoarang> Calchan: i thought we do not support overlays |
122 |
20:31 <@grobian> ulm: for removal, I guess a diff isn't strictly useful |
123 |
20:31 <@hwoarang> as in, we only have control over the gx86 |
124 |
20:31 <@Betelgeuse> There is no reason to break overalys for no benefit |
125 |
20:32 < Calchan> grobian, you're not talking about a single package here, but about an eclas which may be used by multiple packages, and 30 days may not be enough to fix thm all |
126 |
20:32 <@ulm> grobian: I was thinking about API changes in general |
127 |
20:32 <@ulm> what's the waiting period for eclass removal? |
128 |
20:32 < Calchan> hwoarang, whether we support them or not they do exist and we may not want to anger our community more than reasonnable |
129 |
20:32 <@grobian> ulm: ok, might make sense, but that's close to -dev review of all changes to eclasses |
130 |
20:32 <@ulm> can someone remind me please? |
131 |
20:32 <@jmbsvicetto> hwoarang: we should give overlay mantainers a chance to react to changes in eclasses |
132 |
20:32 <@grobian> Calchan: grep is your friend |
133 |
20:33 <@Betelgeuse> ulm: http://devmanual.gentoo.org/eclass-writing/index.html |
134 |
20:33 <@Betelgeuse> ulm: 30 days |
135 |
20:33 < Calchan> grobian, tools don't matter in this discussion |
136 |
20:33 <@grobian> copy the eclass to your overlay |
137 |
20:33 <@grobian> I think a notice, 30 days makes sense |
138 |
20:33 <@grobian> ebuilds disappear to |
139 |
20:33 <@grobian> sometimes entire ranges (KDE) |
140 |
20:34 <@jmbsvicetto> Calchan: when dealing with substantial changes to eclasses, it's probably a better idea to "bump" the eclass. |
141 |
20:34 <@Betelgeuse> grobian: shadowing eclasses are a bad thing |
142 |
20:34 <@ulm> 30 days for API change should be sufficient, if it's sufficient for eclass removal |
143 |
20:34 <@grobian> Betelgeuse: tell me… but well, if you don't want to fix your ebuilds... |
144 |
20:34 <@Betelgeuse> grobian: they tend to get oudated and users won't get bug fixes etc |
145 |
20:34 < Calchan> jmbsvicetto, then it's a different eclass, what we are talking about right now is changing the API of a given one |
146 |
20:34 <@jmbsvicetto> Betelgeuse: but it might be simpler to copy an eclass to an overlay while updating the ebuilds to the new eclass |
147 |
20:35 <@grobian> So, who is concerned about overlays here? |
148 |
20:35 <@jmbsvicetto> Calchan: sure |
149 |
20:35 <@hwoarang> i am not |
150 |
20:35 <@grobian> me neither |
151 |
20:35 <@jmbsvicetto> grobian: me, in the sense we should give sufficient advanced notice to overlay maintainers |
152 |
20:35 <@Betelgeuse> grobian: to a degree |
153 |
20:35 < Calchan> I think a warning period and adding an ewarn in the changed function so that users/devs notice the change is the right thing to do |
154 |
20:36 <@grobian> I do agree with a notice |
155 |
20:36 <@grobian> Calchan: can agre with that |
156 |
20:36 < Calchan> and 30 days is too short for an eclass imo |
157 |
20:36 <@jmbsvicetto> Calchan: the problem with that are the QA notices (the python eclass used that for a while) |
158 |
20:36 <@grobian> prefer even |
159 |
20:36 < Calchan> jmbsvicetto, can you expand a bit? |
160 |
20:36 <@grobian> it's horror on rsync0 |
161 |
20:37 < Calchan> jmbsvicetto, oh yes I know what you mean |
162 |
20:37 <@jmbsvicetto> Calchan: we want eclass maintainers to provide a warning to ebuild / overlay maintainers, but we might not like for them to have eclasses throw tons of QA warnings on every minor change |
163 |
20:37 < Calchan> jmbsvicetto, but that's an entirely different issue, of an incompetent/non-cooperative dev |
164 |
20:37 <@jmbsvicetto> Calchan: I know. I just wanted to be "clear" |
165 |
20:37 < Calchan> you don't have to be stupid about it |
166 |
20:38 <@jmbsvicetto> that's the problem with "common sense" not being enough - we sometimes have to say "too much" |
167 |
20:38 <@grobian> :( |
168 |
20:38 < Calchan> talking helps a lot in these case, you just have to be willing to do it |
169 |
20:39 <@hwoarang> somehow developement has been evolved in a strict set of rules for the past 2 years |
170 |
20:39 < Calchan> because we are socially lazy |
171 |
20:39 <@hwoarang> not sure if we follow the right path |
172 |
20:39 <@jmbsvicetto> so, I think we all agreed about requiring notification, we haven't agreed about how long it should be, though |
173 |
20:39 <@hwoarang> you take away all the fun with so many ruls |
174 |
20:39 <@hwoarang> *rules |
175 |
20:39 <@ulm> hwoarang: blame the ones that stretch common sense |
176 |
20:39 <@hwoarang> and you will keep devrel buzy in the near future |
177 |
20:40 <@Betelgeuse> hwoarang: the standing practise btw is that you shouldn't do it |
178 |
20:40 <@Betelgeuse> people just started doing it and no-one complained |
179 |
20:40 <@Chainsaw> 30 days is definitely too short. Let's triple it. 90 days? |
180 |
20:40 <@Betelgeuse> besides me any way |
181 |
20:40 <@hwoarang> so you add more rules |
182 |
20:40 < Calchan> Chainsaw, yes |
183 |
20:40 <@hwoarang> because you can't control these people? |
184 |
20:40 <@Chainsaw> I agree that overlays can't hold you back forever. |
185 |
20:40 <@hwoarang> smart :) |
186 |
20:40 <@Chainsaw> But some notice seems a fair thing to do. |
187 |
20:40 <@Betelgeuse> hwoarang: so throw them out then? |
188 |
20:40 <@grobian> eclass function drop == last rite ebuild == 30 days |
189 |
20:40 <@Betelgeuse> hwoarang: or accept that people can do whatever they want? |
190 |
20:41 <@jmbsvicetto> I believe 90 days is too long. I'd argue for 30 or 60 days |
191 |
20:41 <@hwoarang> what is the point make 98% of devs "suffer" because of your rules |
192 |
20:41 <@hwoarang> instead of kick problematic devs out? |
193 |
20:41 < Calchan> Chainsaw, let's word it as "whenever possible" |
194 |
20:41 <@hwoarang> *making |
195 |
20:41 <@Chainsaw> jmbsvicetto: In that case I would prefer 60 over 30, yes. |
196 |
20:41 <@ulm> if 30 days are sufficient for removing an eclasss, it should be sufficient for removal of a function |
197 |
20:41 <@grobian> hwoarang: that 2% need those rules to act "common" instead of kicking them out? |
198 |
20:41 <@Betelgeuse> ulm: 30 days from the point when nothing uses it any more |
199 |
20:41 <@ulm> otherwise people will remove and re-add the eclass :p |
200 |
20:41 <@Betelgeuse> ulm: so it has taken a while to get there |
201 |
20:42 <@grobian> Betelgeuse: how can you know? You shouldn't drop a function that's in use in gx86, obviously |
202 |
20:42 <@jmbsvicetto> I'm sorry for my comment about "common sense". May I suggest we continue with this discussion and return to the "common sense" / "rules" discussion later (if needed)? |
203 |
20:42 <@hwoarang> it seems to me that we keep voting +2 rules on every meeting |
204 |
20:42 <@hwoarang> anyway |
205 |
20:42 <@Betelgeuse> hwoarang: My general point was that we are changing a rule to more closely match what peole are doing |
206 |
20:42 < Calchan> jmbsvicetto, what's the cost of keeping a function in an eclass for 90 days? |
207 |
20:42 <@Betelgeuse> hwoarang: Feel free to suggest no rules about it. |
208 |
20:43 <@Betelgeuse> grobian: It's more likely faster to adjust things in this case. |
209 |
20:43 <@grobian> eclass removal time should be equal at least to eclass function removal |
210 |
20:43 <@hwoarang> i did not say no rules. I say trust the devs and spank those you fail to behave |
211 |
20:43 <@hwoarang> *who |
212 |
20:43 <@Chainsaw> grobian: That is correct. In that case 30 everywhere. If it is felt that this is too short, I'm sure it will be tabled again. |
213 |
20:43 <@jmbsvicetto> Calchan: we're talking about API changes, so it's not just about keeping a function. What about changing a function spec? Or requiring calling pkg_setup where it wasn't needed before |
214 |
20:43 <@grobian> if 30 is too short, we need to up the limit for all of them |
215 |
20:44 <@Chainsaw> grobian: (Shame though, I do think eclass work should be double or triple what ebuild work requires) |
216 |
20:44 <@Chainsaw> grobian: And in the interest of reaching consensus, double. |
217 |
20:44 <@grobian> Chainsaw: I'm willing to go there, but not if you can remove an eclass in 30 days |
218 |
20:45 <@jmbsvicetto> as I said, I'm fine with both 30 or 60 days |
219 |
20:45 <@Chainsaw> grobian: Yes, I see your point that eclass removal/API change should both require the same delay. |
220 |
20:45 <@Betelgeuse> it should be noted that with eclass removal you can't install the thing |
221 |
20:45 <@jmbsvicetto> ulm: should we start counting votes? |
222 |
20:45 <@Betelgeuse> with minor api changes you could install a thing but wrongly |
223 |
20:45 <@ulm> jmbsvicetto: yes |
224 |
20:45 <@grobian> dropping the eclass vs a function is as bad to overlays (the only ones it should hurt) |
225 |
20:45 <@Chainsaw> That is the failure scenario I dread the most, Betelgeuse. |
226 |
20:45 < Calchan> ulm, yes, let's start voting but state exactly what we're voting on |
227 |
20:45 <@ulm> Let's first vote if we need an additional rule at all. |
228 |
20:46 <@Betelgeuse> ulm: it's not really additional as I said |
229 |
20:46 <@ulm> And if this is accepted, let's vote on a wording. |
230 |
20:46 <@jmbsvicetto> ulm: I'd call an update to eclass policy |
231 |
20:46 <@jmbsvicetto> +it |
232 |
20:46 <@jmbsvicetto> and I think we should update it to cover API changes |
233 |
20:46 <@Betelgeuse> ulm: So you want to first vote on if the current policy should be removed altogether? |
234 |
20:46 <@ulm> Betelgeuse: Then let me suggest a wording "When removing a function or changing the API of a widely used eclass, make sure that it doesn't break any ebuilds in the tree, and post a notice to gentoo-dev at least 30 days in advance." |
235 |
20:47 <@Chainsaw> ulm: That sounds good, yes. |
236 |
20:47 <@grobian> jmbsvicetto: that's too vague. Feels like we should push that back for discussion |
237 |
20:47 <@grobian> the agenda topic was just whether or not you can remove functions from an eclass |
238 |
20:47 < Calchan> grobian++ |
239 |
20:47 <@jmbsvicetto> grobian: I didn't meant it to be vague. I'm just arguing that what we're talking about fits inside the already existing eclass policy (or policies if you prefer) |
240 |
20:47 <@jmbsvicetto> ulm: +1 |
241 |
20:48 <@Betelgeuse> ulm: +1 preferably with a patch incldued |
242 |
20:48 <@grobian> jmbsvicetto: yeah, so in that case, I say, no vote, because it's a non-issue at the current state, as Betelgeuse already replied iirc |
243 |
20:48 <@ulm> Betelgeuse: You volunteer to provide a patch? ;) |
244 |
20:48 <@jmbsvicetto> grobian: so you would prefer we create / set a single eclass policy listing all rules about eclasses? |
245 |
20:48 <@Betelgeuse> ulm: in the email to gentoo-dev :) |
246 |
20:49 <@grobian> I would love to see a discussion on APIs in general on eclasses, and how to deal with them |
247 |
20:49 < Calchan> ulm, s/widely// and s/30/90/ and it's a yes |
248 |
20:49 <@Betelgeuse> ulm: but yes I can patch devmanual |
249 |
20:49 <@grobian> if we should use versioning, strict API rules + versioning like libtool does |
250 |
20:49 <@ulm> Calchan: I'm against the 90 days |
251 |
20:50 <@Betelgeuse> grobian: My idea was to vote something to replace the current policy. The finer details could evolve in later meetings. |
252 |
20:50 <@jmbsvicetto> grobian: if so, then I'm fine with pushing this back to the mls. If not, I think what ulm suggested, with Betelgeuse's note about adding a patch to the eclass, seems reasonable to add to the current rules |
253 |
20:50 <@Betelgeuse> So does the current rule stand until we reach a decision? |
254 |
20:50 <@grobian> Betelgeuse: makes no sense to me to vote for something that's not yet there |
255 |
20:50 <@Betelgeuse> As such QA should start encorcing things? |
256 |
20:50 <@Betelgeuse> or anyone else |
257 |
20:51 <@ulm> In principle we have 4 votes in favour for the proposed wording... |
258 |
20:51 < Calchan> ulm, between no rule and 30 days I'll take 30 days |
259 |
20:51 <@Chainsaw> ulm: Which does sound like a majority. |
260 |
20:51 <@jmbsvicetto> ulm: if you didn't, count me as +1 on the proposed wording |
261 |
20:51 <@grobian> Can we then please open the discussion on the MLs too? |
262 |
20:51 <@jmbsvicetto> grobian: seems a good idea to me |
263 |
20:51 <@Chainsaw> Calchan: Exactly. We should propose a change of the duration later. An easy yes/no vote that should have no problems making it onto the agenda. |
264 |
20:51 <@grobian> ulm: and, can you remove "widely-used"? |
265 |
20:52 <@jmbsvicetto> grobian: we can even present it as a reform of eclass policy (policies) |
266 |
20:52 <@grobian> you should NEVER break any ebuild in gx86 |
267 |
20:52 <@grobian> regardless how insignificant |
268 |
20:52 < Calchan> ulm, I'm with grobian, "widely" opens a nasty door |
269 |
20:52 <@grobian> "common sense" |
270 |
20:52 <@ulm> generally used? |
271 |
20:52 <@grobian> ulm: all eclasses, period |
272 |
20:52 <@Betelgeuse> ulm: all eclasses |
273 |
20:52 < Calchan> ulm, we only have one class of eclasses |
274 |
20:52 <@Chainsaw> ulm: Don't give people a chance to argue terminology. Eclass. You can't discuss your way out of that. |
275 |
20:52 <@ulm> ok, s/widely // |
276 |
20:53 <@grobian> a used eclass, erm, so an unused one you can drop all functions from? |
277 |
20:53 <@Chainsaw> ulm: No further objections your honour. |
278 |
20:53 <@ulm> grobian: that's covered bu "removing eclasses" I guess |
279 |
20:53 <@ulm> *by |
280 |
20:53 <@grobian> When removing a function or changing the API of an eclass, make sure that it doesn't break any ebuilds in the tree, and post a notice to gentoo-dev at least 30 days in advance. |
281 |
20:54 < Calchan> ulm, grobian is right, just say eclass, make it simple |
282 |
20:54 <@jmbsvicetto> grobian: + with a patch of the proposed change |
283 |
20:54 <@ulm> grobian: yep |
284 |
20:54 <@grobian> jmbsvicetto: patch: 30 lines of - |
285 |
20:55 <@grobian> jmbsvicetto: but if you prefer, I could live with that |
286 |
20:55 <@ulm> Who will start the discussion about 30/90 days in -dev? |
287 |
20:55 <@jmbsvicetto> grobian: until you can check the patch you won't know whether it's 30 lines of -, 100 of +, or a complete rewrite of the eclass ;) |
288 |
20:55 <@grobian> jmbsvicetto: ok, you convinced me… sigh, python anyone? |
289 |
20:55 <@jmbsvicetto> ulm: the discussion is not about 30/90 days, but about general rules for an eclass policy |
290 |
20:56 <@grobian> eclass ABI policy |
291 |
20:56 <@jmbsvicetto> ulm: what can be changed in an eclass without requiring using a new version, what type of API consistency is required, etc |
292 |
20:56 <@grobian> what changes need review on -dev ML |
293 |
20:56 <@ulm> k |
294 |
20:56 < Calchan> ulm, so are we done voting, or can we start, and on what? |
295 |
20:57 <@ulm> yes, I think we're done with that topic |
296 |
20:57 <@ulm> next: open bugs |
297 |
20:57 <@grobian> I think I can try to start a discussion on the eclass API thing |
298 |
20:57 <@grobian> if noone else wants |
299 |
20:57 <@ulm> grobian: good |
300 |
20:57 <@jmbsvicetto> grobian: be my guest |
301 |
20:57 <@ulm> bug 331987 |
302 |
20:57 < willikins> ulm: https://bugs.gentoo.org/331987 "Merge -council and -project mailing lists"; Gentoo Infrastructure, Mailing Lists; UNCO; scarabeus:infra-bugs |
303 |
20:58 <@ulm> any progress there? |
304 |
20:59 <@jmbsvicetto> I think infra is waiting for our reply to antarus numbers |
305 |
20:59 <@ulm> "The council decided to move these subscribers to gentoo-project and send them a message informing them how to remove themselves from the new gentoo-project mailing list." says the October summary |
306 |
20:59 <@grobian> 54 people, move, send them a notification they're now subscribed to -project |
307 |
20:59 <@jmbsvicetto> given the prior discussion, I think we all agree to have infra move the 54 people subscribed to council, but not project to the latter ml |
308 |
21:00 <@ulm> So, who will take care of it? |
309 |
21:01 <@grobian> can we just cut and paste that sentence in the bug? |
310 |
21:01 <@jmbsvicetto> ulm: I'll bug infra and leave a comment in that bug later |
311 |
21:01 <@ulm> jmbsvicetto: o.k. |
312 |
21:01 <@ulm> bug 341959 |
313 |
21:01 < willikins> ulm: https://bugs.gentoo.org/341959 "council changed the waiting period in "eclass removal policy""; Doc Other, Devmanual; IN_P; tove:qa |
314 |
21:02 <@ulm> "hwoarang agreed to talk to tove about that and sort it out." |
315 |
21:02 <@ulm> hwoarang: any progress? |
316 |
21:02 <@hwoarang> sorry i didn't. i will try again |
317 |
21:02 <@ulm> k |
318 |
21:02 <@jmbsvicetto> ulm: bug 383467 |
319 |
21:02 < willikins> https://bugs.gentoo.org/383467 "Council webpage lacks results for 2010 and 2011 elections"; Website www.gentoo.org, Projects; CONF; hwoarang:jmbsvicetto |
320 |
21:03 <@ulm> jmbsvicetto: right, that's the last one |
321 |
21:03 < Calchan> some would say that reflects reality :op |
322 |
21:03 <@ulm> jmbsvicetto: "jmbsvicetto will take care of that on behalf of the elections team." |
323 |
21:03 <@jmbsvicetto> I wasn't able to get to this before, but I've already copied the old elections results to the elections space and I'll be fixing the links there from the council page later today |
324 |
21:04 <@ulm> good |
325 |
21:04 <@jmbsvicetto> so I should be able to close this bug today or up till the end of the week |
326 |
21:04 <@ulm> any bug that I've missed? |
327 |
21:05 <@ulm> if not, open floor |
328 |
21:05 <@grobian> ok, open floor |
329 |
21:06 <@grobian> anyone? |
330 |
21:07 <@ulm> seems not to be the case |
331 |
21:07 <@ulm> let's close the meeting then |
332 |
21:07 <@grobian> cool, then my connection survived |
333 |
21:07 <@ulm> thanks everybody |
334 |
21:08 <@grobian> ok, thank you mister chairman |
335 |
21:08 <@ulm> I haven't done an online summary, but I hope I can do it tomorrow |
336 |
21:09 <@ulm> grobian: you'll be next chair, btw |
337 |
21:09 <@jmbsvicetto> ulm: thanks for chairing |
338 |
21:09 <@jmbsvicetto> ulm: do you need me to send you the log or want me to commmit it? |
339 |
21:09 * Chainsaw bows to all and disappears |
340 |
21:09 <@ulm> jmbsvicetto: would be nice if you'd just commit it |
341 |
21:10 <@jmbsvicetto> ulm: will do |
342 |
21:10 <@ulm> thanks |