XMPP Council - 2019-11-06

  1. sonny has left
  2. stpeter has left
  3. Kev_ has left
  4. debacle has left
  5. Kev_ has joined
  6. Remko has joined
  7. Remko has left
  8. daniel has left
  9. daniel has joined
  10. stpeter has joined
  11. Zash has left
  12. daniel has left
  13. daniel has joined
  14. daniel has left
  15. daniel has joined
  16. ralphm has left
  17. Remko has joined
  18. daniel has left
  19. Remko has left
  20. stpeter has left
  21. Remko has joined
  22. stpeter has joined
  23. Remko has left
  24. stpeter has left
  25. stpeter has joined
  26. stpeter has left
  27. daniel has joined
  28. Remko has joined
  29. Remko has left
  30. daniel has left
  31. daniel has joined
  32. Remko has joined
  33. stpeter has joined
  34. daniel has left
  35. daniel has joined
  36. daniel has left
  37. Remko has left
  38. stpeter has left
  39. daniel has joined
  40. Tobias has joined
  41. Remko has joined
  42. stpeter has joined
  43. stpeter has left
  44. Kev Ge0rG: Given your mail earlier, is it no longer your intention to try to get CS2020 through this Council?
  45. Ge0rG Kev: answering that question with either yes or no would end up ambiguous.
  46. Ge0rG Kev: I don't have my mail in front of me, but my intention was to vote on Draft today, and have Social added during Draft
  47. Kev Ah, I see.
  48. Ge0rG Not sure what kind of wording mishap happened to make you think I changed my plan
  49. Kev Your words were right, I just didn't understand them (because the thought of pushing it to Draft while there were pending changes didn't process)
  50. Ge0rG Sorry for stalling your pipeline
  51. debacle has joined
  52. Zash has joined
  53. stpeter has joined
  54. stpeter has left
  55. debacle has left
  56. debacle has joined
  57. lnj has joined
  58. stpeter has joined
  59. stpeter has left
  60. stpeter has joined
  61. daniel has left
  62. daniel has joined
  63. stpeter has left
  64. stpeter has joined
  65. stpeter has left
  66. daniel has left
  67. jonas’ .
  68. Ge0rG Is it one of those days?
  69. Kev Always.
  70. Ge0rG no, only with a probability of roughly 14%
  71. Ge0rG Do we have a Dave?
  72. Link Mauve It is one of those days.
  73. dwd has joined
  74. dwd We have a Dave.
  75. Kev I think Dave's too busy in xsf@ trying to find Boris-inspired ways to avoid democracy :)
  76. Kev Ah, there we go.
  77. dwd 1) Roll Call
  78. Kev Present.
  79. jonas’ me too
  80. Ge0rG ,o/
  81. dwd Assuming Ge0rG and Link Mauve are still here, full house.
  82. Link Mauve Yes.
  83. dwd 2) Agenda Bashing
  84. dwd XEP-0243 to Draft, and that's it, right?
  85. Ge0rG I have two points for the Agenda, related to CS-2020
  86. dwd AOB or voting things?
  87. Ge0rG a) shall XEP-0392 Consistent Color Generation be demoted from "Advanced IM Client" into "Future Development"? b) Can we advance XEP-0423 to Draft, given the changes that I promise to have pushed some time tomorrow.
  88. dwd OK, given these, let's discuss these first and *then* vote if we're to do so.
  89. dwd 3) Georg's Things.
  90. Kev 3a) Yes.
  91. jonas’ I have no strong opinion on (a)
  92. dwd a) shall XEP-0392 Consistent Color Generation be demoted from "Advanced IM Client" into "Future Development"?
  93. jonas’ do whatever works
  94. Ge0rG Yes please.
  95. Ge0rG I was heavily criticized for adding it to the mandatory list of the Compliance Suite, because Council is not competent at guiding UX, and because it's not ready yet and for other reasons.
  96. jonas’ so just remove it since that seems to be what the (loud part of the) community wants?
  97. dwd I don't think I have an opinion here. But given the Wailing and Gnashing Of Teeth, I'm thinking punting it out of the compliance per-se would be the path of least contention.
  98. Link Mauve I’d say remove it, it can always get integrated back later once it’s clear it works properly for everyone.
  99. Ge0rG indeed, but I have no fear of contention.
  100. Kev My opinion isn't /that/ strong, but I don't think it belongs there, at the moment.
  101. Ge0rG XEP-245 is also clearly guiding the UI design, and nobody objected _that_ (except for its ugly wire format)
  102. daniel has joined
  103. dwd Personally I think there are UX issues in much if not all of what we do, but I would rather than CS matched some kind of community concensus anyway.
  104. Kev I think that's vague agreement on 3a, then?
  105. jonas’ (ftr, I need to leave at 16:30Z sharp)
  106. dwd jonas’, Ack.
  107. dwd I think we have rough consensus on 3a), yes.
  108. Ge0rG well, then. https://github.com/xsf/xeps/pull/851/commits/8182e2e38b25bda0a1febe7dc1019c9b0bf2a630
  109. dwd b) Can we advance XEP-0423 to Draft, given the changes that I promise to have pushed some time tomorrow.
  110. Kev I'd be happy to advance to Draft once my feedback's addressed.
  111. Ge0rG The promised changes are in #851, except for an update to the "Changes since 2019", which I'll fix after consensus is reached
  112. dwd This one is more problematc for me. My gut feeling is "no", modulo some very persuasive arguments I've not thought of.
  113. Kev I've not had a chance to check the rendered copy for differences from what I reviewed yet.
  114. Ge0rG Kev: your feedback was adressed on-list as well as in #851
  115. pep. > Ge0rG> XEP-245 is also clearly guiding the UI design, and nobody objected _that_ (except for its ugly wire format) I wanted to.. :-°
  116. Ge0rG dwd: if we make it a formal vote starting today, we can manage to make a decision right before Council falls apart
  117. pep. But it's so much used everywhere..
  118. Ge0rG can imagine
  119. dwd When does Council cease to exist?
  120. jonas’ I have a bad gut feeling about the pre-vote process-wise too
  121. jonas’ dwd, the election meeting is on nov 21st
  122. jonas’ so the last council meeting will be on nov 20th
  123. Kev #851 also adds 156 (probably ok), 520 in future (probably ok), and adds 77, which I don't think is ok, as well as the Push thing being weird (because at least Android nor iPhone guarantee long-lasting background connections, AFAIU).
  124. jonas’ i.e. 2 weeks from now
  125. dwd Ge0rG, Can you get everything merged by tomorrow?
  126. Ge0rG dwd: please ask Editor.
  127. jonas’ can we have an irregular council meeting tomorrow?
  128. jonas’ Ge0rG, if it’s finished by tonight, I can arrange that
  129. jonas’ (tonight ~= 18:00Z)
  130. Ge0rG dwd: I'll take all Council feedback that I can get and update the PR
  131. Ge0rG jonas’: ack
  132. dwd jonas’, That's what i was thinking. Nothig says our meetings have to be every week (indeed, they weren't until recently).
  133. Ge0rG Kev: does "I don't think is ok" translate into a -1?
  134. Kev Where 'recently' is probably longer than they weren't ;)
  135. jonas’ I can join any time tomorrow except 10:45Z -- 11:45Z (lunch \o/) if I know when
  136. dwd Kev, More than likely, these days.
  137. Kev Ge0rG: Including 77 feels wrong to me.
  138. Link Mauve I can join any time tomorrow.
  139. Ge0rG Kev: why?
  140. dwd AGM is at 1900Z?
  141. jonas’ I think IBR is very right to include
  142. Link Mauve Kev, 77 feels right to me, maybe excluding account registration.
  143. jonas’ dwd, yes
  144. Link Mauve But allowing users to change their password is a must imo.
  145. stpeter has joined
  146. Kev Because it pretty much presupposes that these things are Internet.
  147. pep. Ge0rG> dwd: please ask Editor. I can also help
  148. Link Mauve And supporting account registration (in a software) also seems like a must.
  149. Ge0rG Kev: this is about implementation support, not about having it enabled by default
  150. Kev Link Mauve: I think for just about all non-Internet (and a good chunk of Internet) cases this isn't true.
  151. Zash Mandating support for registration does not mean it has to be enabled on every deployment
  152. jonas’ Kev, note that software and deployment are separate things and disabling either registration and/or password change due to restrictions is valid
  153. jonas’ Kev, supporting account registration on the client side is very reasonable IMO, especially since there have been efforts of building onto the data forms flow of '77 for invitations and such
  154. dwd Guys, stop a sec - if we hold a meeting tomorrow at, say 1600Z, can we all make it and do we think we can have CS-2020 ready for a vote by then?
  155. Kev I understand the distinction between deployment and implementation, but I think requiring stuff that's only interesting for (some) Internet deployments isn't right here.
  156. jonas’ ("invitations" = links with tokens which allow registration to a deployment)
  157. Ge0rG Kev: do you actually have a server or client software that can't be configured to do IBR?
  158. Kev Ge0rG: Several :)
  159. Ge0rG Kev: do those care about being "Core IM"?
  160. Link Mauve dwd, I can be there at 17:00 CET tomorrow.
  161. jonas’ can we agree on having this only "Advanced"?
  162. Kev "Care" isn't the right word, probably, but I think the other stuff in the compliance suite that they don't do they reasonably could, wherease IBR just isn't appropriate.
  163. dwd Kev, Ge0rG, jonas’, Link Mauve - Can we agree a meeting tomorrow at 1600Z, and if so, can we have CS-2020 merged and published ready for a vote by then?
  164. Ge0rG jonas’: it doesn't make much sense to me, but yes
  165. jonas’ dwd, yes, works for me
  166. Ge0rG dwd: +1
  167. Link Mauve +1.
  168. Kev I *think* I can do 1600 tomorrow.
  169. jonas’ (dwd, sorry, I wasn’t ignoring you, I was polling my calendar)
  170. Kev But I think thrashing this out now is worthwhile.
  171. Kev Else we'll get to the meeting tomorrow and vote on something not ready to pass.
  172. dwd OK, in that case I move to adjourn the formal Council meeting until tomorrow. But feel free to use the remaining time now to thrash things out.
  173. Ge0rG yes, having it done by tomorrow's meeting implies that we make all the decisions now
  174. Kev That is, I think we should go into tomorrow with the approval being a formality.
  175. jonas’ dwd, I think that’s a very good move
  176. dwd Ge0rG, It does, and I agree with kev.
  177. Kev dwd: On the IBR point, or on the point that we should agree it now?
  178. Kev s/now/before the time of the meeting so it's a formality/
  179. dwd So, my view on '77 is that it's useful for password changing and IBR in various cases, but in a number of deployments it's undesirable if not impossible.
  180. jonas’ and deployments are free to disable features of the software
  181. dwd Kev, That we discuss things now so tomorrow is, as much as possible, a formality.
  182. jonas’ CS is for software, not deployments AFAIU
  183. Ge0rG What jonas’ said. But I've been thinking about a "deployment" category-thing somewhere in it.
  184. dwd jonas’, It's also for expectations. Could a client find itself reliant on '77 and unable to function without?
  185. Link Mauve Kev, which kind of software can’t change passwords (at all, not depending on e.g. having connected with specific SASL mechanisms), btw?
  186. Kev Link Mauve: Anything running against a corporate directory, probably.
  187. Ge0rG dwd: I don't see such a dependency in 0077
  188. jonas’ Link Mauve, my prosody can’t change passwords because it doesn’t have th enecessary permissions on the ldap database
  189. Ge0rG I also can't imagine a client that will only work if you use it to register a new account.
  190. jonas’ 16:18:27 dwd> OK, in that case I move to adjourn the formal Council meeting until tomorrow. But feel free to use the remaining time now to thrash things out.
  191. Link Mauve Right, but Prosody the software can, if it is configured against another type of database.
  192. jonas’ can we do this please?
  193. Ge0rG you are drifting into deployments again
  194. jonas’ if I can catch a bus earlier that would be very useful
  195. Kev dwd: Close the meeting, sure.
  196. Link Mauve jonas’, I thought it was already adjourned.
  197. jonas’ and I don’t think this discussion is helpful for me or vice versa
  198. dwd 99) Ite, Meeting Est
  199. Link Mauve And we were just continuing the discussion.
  200. jonas’ dwd, thanks :)
  201. dwd (But don't Ite)
  202. jonas’ date of next: 2019-11-07T16:00:00Z
  203. Link Mauve jonas’, see you tomorrow. \o_
  204. Ge0rG bye jonas’, I'll ping you and pep. with the finished PR
  205. jonas’ Ge0rG, thanks
  206. Ge0rG Kev, dwd: jonas’ suggested demoting IBR into "Advanced IM", to which I can agree.
  207. Ge0rG Now the question is: can you, too?
  208. Kev I think it's wrong there, too.
  209. dwd I think it's Basic with a note that says "Implem,entations cannot rely on XEP-0077 being deployed for either IBR or password changes as these may be undesirable or unavailable in a given deployment"
  210. Kev Because it's meaning "IM" is "public open registration chat service", basically, and I think you can legitimately have an "Advanced IM client/server" for all the other uses cases that aren't the "public open registration chat service"
  211. Link Mauve I guess the goal of CS is relevant here, do we want to have a document to point newcomers who want to write XMPP software to, or do we want to have a document for certifying our existing software, or something else?
  212. Kev BRB.
  213. Kev And back.
  214. dwd Kev, WHat do you think of my note suggestion?
  215. Kev I could do both Basic and Advanced with a note saying "Only when intended for public open registration chat services" or something, similar to the weasel words for Push (with which I don't agree, but can live).
  216. Kev dwd: I don't like it being required for implementations.
  217. Kev I think there's wiggle room here if people really want it in - but wiggling is needed.
  218. Kev Or something like "If in-band password change is provided, it must be provided with 77, if not an alternative out of band mechanism for password change must be possible". I think the registration part shouldn't be there for either, though.
  219. Ge0rG What would be the alternative place to put it in?
  220. daniel if the CS is mostly about discoveribility or steering people to the right xeps for problems that have multiple xep solutions; i don’t think that ibr is hard to discover
  221. daniel for those who need it
  222. Ge0rG Do we need a new category "Public IM" just for IBR and 0157?
  223. Kev Ge0rG: We could also just have a section ...
  224. Kev I was thinking "Account Management" just for 77.
  225. Ge0rG Kev: what's a section in CS terms?
  226. dwd Or a section of "Other specifications of note", like the Future Dev one?
  227. Kev dwd: Perfect.
  228. Link Mauve Account Management should include a lot more than just 77, but that’s all we have atm.
  229. Link Mauve Things like MAM messages lifetime configuration, cleaning uploaded files up, etc.
  230. Ge0rG Link Mauve: write the XEPs, and get them into CS-2021
  231. Zash Ad-hoc?
  232. Link Mauve Ge0rG, yes.
  233. Link Mauve Zash, yes.
  234. Link Mauve Ge0rG, current MAM already includes that, future MAM won’t anymore.
  235. Kev I would suggest either "Other specs of note" as Dave said, or a new suite just for 77.
  236. Ge0rG dwd: can we have a more formal name for it? "Further relevant specifications"?
  237. Zash Suggested Reading, eg for the Mobile power consumption one?
  238. Ge0rG I see a certain value in a new category "Public IM"
  239. Kev There are other things that might belong there, like spam handling.
  240. dwd Ge0rG, "If You Like These Suites, You'll Love:"
  241. Kev (Not this year)
  242. Link Mauve Another future category, but that’ll be 2021 at least, would be audio/video.
  243. Link Mauve “Jingle Category”
  244. Ge0rG dwd: I'm not sure I'll get _that_ through tomorrow's council
  245. Ge0rG I'd prefer a "Public IM" category over a section, because it's better structured that way. Also would include 0191
  246. dwd Ge0rG, "Further Specifications" section in each Suite. Good place to put '77, '286, and so on.
  247. Kev I note that you can do 'Public IM' fine without 77 too, but I'm much less militant about that.
  248. dwd Ge0rG, Would work for '392, as well. Stuff we can't or shouldn't mandate, but might be useful.
  249. Ge0rG dwd: I have a bit of a fear that it will end up in a huge list of meaningless and unweighted bullet points
  250. Kev I like the "Further Specifications" (or "Further Specifications Of Note") idea per suite best, but can go along with the new suite.
  251. Ge0rG In that case I need to weigh on which XEPs belong into "Further" and which ones belong into "Future"
  252. Ge0rG Okay, I will create new "Further Specifications of Note" bullet lists in the relevant Compliance Categories. Next?
  253. dwd I don't see anything else raised by Council folks.
  254. Kev 66 goes in there, I think, and that addresses my other bit of feedback.
  255. dwd Oh, there we go.
  256. Ge0rG 66 together with SIMS?
  257. Ge0rG 0333 as well, I suppose.
  258. Link Mauve SIMS is very much future atm.
  259. Kev I would avoid adding anything more than we've already been through.
  260. Kev It feels like we've got something we can live with. Further tweaking is inviting calamity.
  261. Link Mauve So it’s safe to ignore it for this year.
  262. Kev IMNRHO
  263. Ge0rG Kev: do you consider the current state of #851 as "we've been through it"?
  264. Ge0rG and I'll move IBR, 66, SIMS, 0392 into the "Further Specifications Of Note" sub-section and be done with it?
  265. Kev I mean, if the new stuff gets moved into the new 'Futher Specs' bit, it looks ok to me, I think.
  266. Kev Oh, yes, 392 in Further Specs is better than Future, good call.
  267. Kev I think there was one extra thing added with 77? Let me check.
  268. Kev Oh, 157. I think that's better in Futher Specs, but don't feel as strongly as 77.
  269. Ge0rG Kev: 157 hangs on 777
  270. Ge0rG Kev: 157 hangs on 77
  271. Link Mauve Does it?
  272. Kev Ah, it's in there only as 'recommended for public servers' anyway.
  273. Zash Is CS meant to be a deployment thing now, not just an implementation thing?
  274. pep. Kev, As a private entity it might still be good to know which part of another private entity I should reach directly, if the information is available
  275. Ge0rG Kev: https://op-co.de/tmp/xep-0423.html#im
  276. Ge0rG Zash: shush!
  277. pep. Zash, apparently..
  278. Kev Implementations are always intended for deployment. If your implementation isn't for deployment in a public server (in the sense here) the implementation doesn't need to support it.
  279. pep. What about what I just said?
  280. pep. It would still be a private deployment
  281. pep. federating
  282. Kev Ge0rG: I've just read the "Further Specifications of Note" thing under #im, and that looks good.
  283. Kev Thanks for sticking with this.
  284. Ge0rG Kev: I've renamed it to "Further specifications of note, which are not required for compliance:" for maximum explicity
  285. Kev pep.: I didn't say 157 needed to be public only, I just said that in the diff it was public only, which is at least as restrictive as I felt was needed.
  286. Kev Ge0rG: Thanks.
  287. pep. I'm still not sure why you'd want to get Core/Advanced IM compliance for a private deployment anyway, but oh well
  288. Kev FWIW, annoying as this probably is, I think having these sections makes the CS much better than trying to shoe-horn things into compliance, or be ignored completely, so it's a net win, even if at an unfortunate time.
  289. Kev pep.: People still have to write the implementations that people then select for private deployments.
  290. pep. Well they you define your specset and be done with it?
  291. pep. And you call it PrivateCompliance(tm)
  292. Kev If you can always just define the features you want, and check if implementations support them, and don't need guidance from the XSF, the Compliance Suites have no value.
  293. Ge0rG could you please stop that meta discussion? It's making my head spin
  294. Ge0rG Kev: also just moved 0286 into a similar space under https://op-co.de/tmp/xep-0423.html#mobile
  295. Kev Ge0rG: Unless I've missed something, we're good now, and we should stop this.
  296. Kev Ge0rG: I think that's an improvement too, thanks.
  297. Ge0rG Kev: thanks very much for the heated debate, I also consider this as an improvement over before, even for 77
  298. Kev pep.: I think that "The Internet is the only network we have to think about, or 'all services are public services'" are mindsets the XSF falls into quite often, and it's very harmful.
  299. Kev pep.: I think that "'The Internet is the only network we have to think about', or 'all services are public services'" are mindsets the XSF falls into quite often, and it's very harmful.
  300. pep. I think the question is pretty clear, who is the target of CSs, and why would a private company want to comply to it. If they deem they don't need avatars they just don't do avatars
  301. Kev It sounds like you're assuming that anyone with a private deployment wrote it themselves, or had it custom-produced for them.
  302. Ge0rG Kev: that sounds like a strong parallel to the CA/BF and other entities equalling "Internet" with "Web", and causing much more collateral damage than we ever could
  303. pep. Kev, sure. I'm not promoting free software dev slavery for profit-driven companies
  304. pep. And I think I'm done with this discussion.
  305. Kev Who said anything about free software, or profit-driven companies?
  306. Ge0rG but I still think that supporting IBR in an implementation is a net win for that implementation, even if it's targeted at Enterprisey Enterpises.
  307. daniel I think having a map for the jungle of xeps is very valuable to all kind of implementations. The map should just properly mark paths as such if they are only valuable for some demographics
  308. Kev daniel: I agree (and I think Ge0rG's changes just now make this much better).
  309. daniel It not just about getting the 'compliancy stamp'
  310. Kev Yes. I see the compliance suites as more useful for advice to implementors about what people choosing software might need, than about a sticker.
  311. Kev It's why, in a future year, I'd like to see them not called Compliance Suites, but something that better reflects they're Implementation Advice.
  312. pep. Then I don't understand why you fight so hard against IBR. These two last messages make me wonder
  313. pep. If you don't want the stamp anyway
  314. Kev Because I think it's bad advice to say it's needed in the general case (plus, as long as the compliance suites advertise themselves as compliance suites, they'll be treated as such).
  315. daniel > It's why, in a future year, I'd like to see them not called Compliance Suites, but something that better reflects they're Implementation Advice. I think I agree with that. The compliance suites have certainly evolved into what can be understood as implementation advice.
  316. pep. wherever there are green checks people will see green checks. Call it however you want ("Compliance Suites" or "Implementation Advice")
  317. daniel That being said. Stickers are also nice
  318. daniel Blindly chasing green check marks is probably not something we want to encourage
  319. daniel Says the person who developed the compliance tester
  320. Link Mauve Kev, I’m thinking about drafting a blog post emphasising “XMPP 2020”, with the compliance suite being its technical specification, but also to encourage implementations to get the stamp.
  321. Ge0rG My feeling with much of the 0392 backlash was that it came from people blindly following green checkmars.
  322. Link Mauve I don’t know if that aligns with your views.
  323. pep. Ge0rG, did it?
  324. Ge0rG I disagree with Kev regarding the value of a CS-2020 stamp, so feel free to put my name on that blog post ;)
  325. Ge0rG Link Mauve: ^
  326. Link Mauve :D
  327. Link Mauve A little bit of marketing won’t hurt us. ^^
  328. Link Mauve I’ll let you all review it of course.
  329. Ge0rG pep.: along the lines of "we can't implement 0392 while following the Whatever Usability Guides so now you make us lose Advanced IM!"
  330. Ge0rG pep., jonas’: https://github.com/xsf/xeps/pull/851 is ready to merge now
  331. pep. k
  332. Ge0rG pep.: good luck doing the version block!
  333. Ge0rG 🙈🙉🙊
  334. Ge0rG But I suppose you can derive it from https://github.com/xsf/xeps/pull/851/commits/b378edaa069b2d4df2fa5c0b88bf0c927dd585ff
  335. daniel But yeah I think we were successful in creating a compliance suite that nobody implements
  336. pep. Ge0rG, you know generally we just add the "Needs version block" label and let people do?
  337. pep. I'd prefer if you did it, you know best what goes in there :x
  338. pep. ok if it's "just" that I can have a look
  339. Ge0rG daniel: in light of that statement, I now see why you didn't follow up to our recent discussion re Compliance Checker vs Compliance Suite, and how the latter can learn from the former
  340. Ge0rG pep.: I always struggle with what version to put in there, and fear that Editor Tooling will mess around with it. Sorry
  341. pep. Update the minor, it's not an editorial change
  342. pep. editorial is patch, and major is process
  343. pep. (I mean.. experimental, draft, final)
  344. pep. I'm also very much new to that anyway :P
  345. Ge0rG pep.: see, you can train your editor skills now! ;)
  346. pep. How lucky am I!
  347. Ge0rG I'll try to do it next time, but I still haven't fully recovered and already spent more on 0423 today than my time budget permitted.
  348. pep. k, I started already
  349. pep. Ge0rG, you forgot to add 333 and 420 in the changelog since 2019
  350. Ge0rG pep.: you just made me shiver a little bit, but I intentionally left out "Future Development" from "Changes since 2019"
  351. pep. I see. I'm wondering if I should add that in the changelog. But I see now I've copied your block last time and it wasn't in it..
  352. daniel has left
  353. daniel has joined
  354. pep. Ge0rG, pushed. Let's wait for CI now..
  355. jonas’ pep., just build locally with docker
  356. pep. I don't have a good enough uplink
  357. pep. it takes ages
  358. jonas’ building?
  359. jonas’ or pushing?
  360. Zash worry about your downlink
  361. pep. pushing
  362. jonas’ right
  363. jonas’ is it on master already?
  364. pep. yeah it's master
  365. jonas’ I’m building it
  366. pep. thanks
  367. jonas’ this 1 MiB/s uplink must be good for something.
  368. ralphm has joined
  369. Ge0rG > Microsoft is at capacity with at least some of its Azure VMs in the East US2 region, users are reporting. Microsoft acknowledges it is placing restrictions on additional quota on some customers there: https://t.co/8cCaKvJJh1 Stop using the cloud already! It's overloaded! https://twitter.com/maryjofoley/status/1190015959140057089
  370. Zash The cloud isn't a big truck!
  371. Ge0rG Yes it is!
  372. Ge0rG https://upload.yax.im/upload/lfkVjwUG0FDz6k4b/awssnowmobile.0.jpeg
  373. Zash Oh snap
  374. jonas’ pep., push’d
  375. daniel has left
  376. daniel has joined
  377. pep. Thanks, I sent the email
  378. stpeter has left
  379. stpeter has joined
  380. stpeter has left
  381. stpeter has joined
  382. stpeter has left
  383. stpeter has joined
  384. stpeter has left
  385. sonny has joined
  386. debacle has left
  387. lnj has left
  388. sonny has left
  389. sonny has joined
  390. debacle has joined
  391. Remko has left
  392. Remko has joined
  393. daniel has left
  394. daniel has joined
  395. Remko has left
  396. Tobias has left
  397. moparisthebest has left