Gentoo Archives: gentoo-commits

From: "Jorge Manuel B. S. Vicetto (jmbsvicetto)" <jmbsvicetto@g.o>
To: gentoo-commits@l.g.o
Subject: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/council/meeting-logs: 20111108.txt
Date: Sat, 12 Nov 2011 21:11:39
Message-Id: 20111112205625.A60052004B@flycatcher.gentoo.org
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