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


  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


  79. jonas’

    me too

  80. Ge0rG ,o/

  81. dwd

    Assuming Ge0rG and Link Mauve are still here, full house.

  82. Link Mauve


  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


  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


  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


  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


  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.


  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


  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.


  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’


  359. jonas’

    or pushing?

  360. Zash

    worry about your downlink

  361. pep.


  362. jonas’


  363. jonas’

    is it on master already?

  364. pep.

    yeah it's master

  365. jonas’

    I’m building it

  366. pep.


  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


  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