XSF Discussion - 2017-02-22


  1. mancho has left
  2. tim@boese-ban.de has joined
  3. Zash has left
  4. daurnimator has left
  5. suzyo has left
  6. Kev has left
  7. vurpo has left
  8. vurpo has joined
  9. mancho has left
  10. Lance has left
  11. Kev has left
  12. blipp has left
  13. blipp has joined
  14. waqas has left
  15. vurpo has left
  16. Lance has joined
  17. daurnimator has left
  18. efrit has joined
  19. Lance has left
  20. Alex has joined
  21. Tobias has joined
  22. Tobias has joined
  23. xnyhps has left
  24. xnyhps has joined
  25. vurpo has left
  26. Kev has left
  27. SamWhited has joined
  28. waqas has joined
  29. Alex has left
  30. daurnimator waves goodbye
  31. daurnimator has left
  32. Steve Kille has joined
  33. daurnimator has left
  34. jere has joined
  35. efrit has joined
  36. efrit has joined
  37. efrit has left
  38. efrit has joined
  39. SamWhited has joined
  40. kalkin has left
  41. daniel has left
  42. kalkin has joined
  43. daniel has joined
  44. Kev has left
  45. efrit has left
  46. efrit has joined
  47. kaboom has left
  48. vurpo has left
  49. vurpo has joined
  50. efrit has joined
  51. Kev has left
  52. mancho has joined
  53. Kev has left
  54. Kev has left
  55. Zash has joined
  56. Guus has left
  57. Guus has left
  58. peter has left
  59. vurpo has left
  60. vurpo has joined
  61. Guus has left
  62. Steve Kille has left
  63. Flow has joined
  64. Guus has left
  65. Guus has left
  66. goffi has joined
  67. Guus has joined
  68. Flow has left
  69. goffi has left
  70. goffi has joined
  71. Guus has left
  72. Guus has joined
  73. Steve Kille has left
  74. Kev has left
  75. xyz has joined
  76. waqas has left
  77. vurpo has left
  78. vurpo has joined
  79. suzyo has left
  80. winfried has left
  81. winfried has joined
  82. xnyhps has left
  83. suzyo has joined
  84. SamWhited has left
  85. Ge0rG looks like today is the last day of the 0280 LC. Time to open some more PRs
  86. vurpo has left
  87. vurpo has joined
  88. uc has left
  89. vurpo has left
  90. vurpo has joined
  91. uc has joined
  92. Guus has left
  93. xnyhps has left
  94. Guus has joined
  95. Kev has left
  96. uc has left
  97. uc has joined
  98. xnyhps has left
  99. kalkin has left
  100. kalkin has joined
  101. vurpo has left
  102. vurpo has joined
  103. Kev has left
  104. xnyhps has left
  105. devnull has joined
  106. sezuan has left
  107. Ge0rG Could somebody have a quick view if https://github.com/ge0rg/xeps/commit/0ff5f4f30baca8a1cf5cc9fe5af55bbffb7d879c provides a clearer language? Original: https://xmpp.org/extensions/xep-0280.html#which-messages New: https://op-co.de/tmp/xep-0280.html#which-messages
  108. Ge0rG please :)
  109. Piotr Nosek has joined
  110. xnyhps has left
  111. devnull has left
  112. Yagiza has joined
  113. Valerian has joined
  114. vurpo has left
  115. vurpo has joined
  116. jcbrand has joined
  117. devnull has joined
  118. Kev has left
  119. jubalh has joined
  120. kalkin has left
  121. xnyhps has left
  122. Yagiza has left
  123. Yagiza has joined
  124. Martin has joined
  125. moparisthebest has joined
  126. kalkin has joined
  127. Ge0rG Any native speakers, please?
  128. blipp has left
  129. ralphm has left
  130. devnull Ge0rG: overall, I'd say I like the new wording better. It's clearer, and the specific meaning of the RFC-CAPITAL words is better IMO.
  131. devnull Only thing I'm thinking of is the third sentence. The original says (correct me if I'm wrong) a message of type="error" that is in reply to a message that itself was eligible for carbons, should be carbon-copied as well. To me it implies that other messages of type "error" that /aren't necessarily/ in reply to a message that was eligible for carbons don't have to be carbon-copied.
  132. devnull But in the revised form, it says that messages in reply to another message eligible for carbons are the __only__ messages of type "error" that may be carbon-copied.
  133. devnull I know it's a little bit nit-picky, but in my eyes the two sentences don't mean quite the same thing.
  134. Ge0rG devnull: you are right. I have implied the last rule here
  135. devnull That being said I don't really know the spec itself, so it might not matter anyway. I'm not sure.
  136. Ge0rG devnull: CCing an error only makes sense if the error-causing message was CCed as well
  137. Ge0rG devnull: from original: "A <message/> is not eligible for carbons delivery if it does not meet any of these criteria." - if this rule is applied, I can make the 'if' an 'iff'
  138. devnull Right. It's a little stronger of a statement.
  139. Ge0rG I'm all in favor of bold statements.
  140. kalkin has left
  141. xnyhps has left
  142. Kev has left
  143. suzyo has left
  144. suzyo has joined
  145. winfried has left
  146. suzyo has left
  147. suzyo has joined
  148. kalkin has joined
  149. nicolas.verite has joined
  150. nicolas.verite has left
  151. vurpo has left
  152. vurpo has joined
  153. Flow has joined
  154. mimi89999 has left
  155. dwd SHOULD is really MUST except for odd cases. I thought the consensus was that Carbons' choice of what to archive was deliberately loosely defined. This is a major change.
  156. dwd s/archive/carbon-copy/
  157. dwd I'm still asleep.
  158. Kev has left
  159. uc has left
  160. uc has joined
  161. Kev Carbon's choice to let implementations choose what's copied was a deliberate change to get through the previous LC, yes.
  162. Kev I think the proposed change makes things less clear, rather than more clear.
  163. devnull But I thought that was the exact time to use SHOULD/MAY--when there's a degree of choice between implementations.
  164. Kev SHOULD doesn't mean there's a choice.
  165. Kev It means there may be rare times where it's appropriate not to, but you can expect things to break unless you do it.
  166. Sonny has left
  167. Sonny has left
  168. Sonny has joined
  169. Sonny has left
  170. kalkin has left
  171. Ge0rG Kev: my gripe is with the "A <message/> is eligible for carbons delivery if it is of type X and condition Z" wording. Do you happen to have a more concise suggestion?
  172. Ge0rG I'm really not a fan of all the MAY or MAY NOT in that spec.
  173. devnull "a <message /> SHOULD be delivered with carbon copies if it is..." ?
  174. Kev There shouldn't be any MAY NOT, because that's not 2119ish.
  175. Ge0rG I can downcase the SHOULD/SHOULD NOT in the diff to make it less formally required, then the MAY/SHOULD from above should apply
  176. uc has left
  177. uc has joined
  178. Kev Ge0rG: You could extract the 'is eligible if' out to the top of the list with something like 'If following these rules, a message is eligible for carbons delivery if any of the following are true:' or such, I guess.
  179. Ge0rG devnull: that would achieve the exact opposite of my goal ;)
  180. Ge0rG Kev: thanks, I like that.
  181. Ge0rG Now I've started a rewrite of the MUC rules based on the SHOULD/NOT wording, but I might be able to manage that.
  182. Ge0rG Kev: should I make it an 'iff' while I'm at it?
  183. Kev I'm not sure it adds much, given they're optional rules anyway.
  184. Ge0rG I really need to read up on why they have been made optional.
  185. Kev Short version: We couldn't agree on MUST rules.
  186. Ge0rG isn't that exactly what a standards committee is for?
  187. Kev If we make them mandatory, I want them done 'properly' for future use in a mamsync-ish world, while (at least) Dave is firmly opposed to any changes that would make current implementations of the spec not compliant.
  188. jere has joined
  189. jere has left
  190. jere has joined
  191. jonasw Kev: your stance sounds very reasonable
  192. Guus has left
  193. jonasw it’s experimental, there should be nothing wrong with implementations suddenly being incompliant.
  194. Ge0rG Kev: mamsync and MIX
  195. Kev The counter argument is that it's de-facto Draft just by the number and state of implementations.
  196. dwd Ge0rG, A standards committee can either agree on a set of rules, or note that there isn't a single set of rules.
  197. Kev I don't agree with the argument, but it has legs.
  198. Ge0rG Kev: the <private/> -> <no-copy/> change mandates for a version bump
  199. jonasw Kev: the discussion(s) during the LC of 280 show that it’s not a draft yet for reasons.
  200. Ge0rG if we are bumping anyway, we can as well do it properly this time.
  201. dwd Ge0rG, I actually wouldn't complain about that. What I didn't want to see was a bump for some small case.
  202. dwd Ge0rG, While versioning does mean we're stable against incompatible changes in XEPs, we do have a problem in allowing the old (and often well-deployed) versions of XEPs to be easily found, though. I can think of a few XEPs where the old version has similar deployment to the current.
  203. dwd Ge0rG, And as an SDO, part of our job is to reflect reality as well as dictate what that reality ought to be.
  204. Ge0rG dwd: how is it bad to have an old version be easy to find (as long as it is explicitly marked as old)?
  205. kalkin has joined
  206. jonasw (I think dwd means the problem is the other way round – it’s hard to find versions of XEPs which are old but well deployed)
  207. Ge0rG dwd, Kev: do I have your blessing to move forward with defining 'SHOULD' rules based on current practice and what I have gathered so far for a new version-bumped 0280?
  208. efrit has joined
  209. dwd Ge0rG, No. You need consensus from standards@, not permission from an Editor and a Council member.
  210. Ge0rG dwd: I'm approaching you as two of the Elders Of XMPP, not in any formal function
  211. jonasw preparing a PR may help to have a focused discussion on standards@ though, imo
  212. Kev Ge0rG: I think it would be interesting to see what such a spec would look like, at least. Other than getting me to stop yelling about not liking stuff, my opinion's not worth much though.
  213. Kev That is, I don't think you need anyone's blessing to write the patch. (Getting it merged is another matter...)
  214. Ge0rG Kev: incorporated your wording idea, https://github.com/ge0rg/xeps/commit/f0e432c15ee3b811a4065abc4baa158ba5fae0c9 / https://op-co.de/tmp/xep-0280.html#which-messages
  215. dwd Ge0rG, If you can build a case to break compatibility, and the majority of those implementing or planning to find it compelling, then please do so.
  216. Guus has left
  217. Ge0rG the MUC and the is-not sentence are removed as the same meaning is covered by the "if and only if". A separate diff will be presented for MUC cases
  218. Guus -xep workgroup queues
  219. Bunneh Guus: XEP-0142: Workgroup Queues is (Deferred, 2005-05-09) See: https://xmpp.org/extensions/xep-0142.html
  220. Ge0rG dwd: "break compatibility" would mean "require implementations to run two versions for some time"
  221. Ge0rG The previous debates about 0280 on standards@ have shown that consensus is impossible to reach. I'm attempting the "MIX mode" here, by trying to write down what is the most elegant solution in my eyes.
  222. nicolas.verite has joined
  223. dwd Ge0rG, You're welcome to suggest a specific solution, of course. But you do need to obtain consensus.
  224. kalkin has left
  225. Ge0rG dwd: if I fail to obtain consensus, 0280 will return to 'Experimental' and do yet another round?
  226. dwd Ge0rG, I think we *had* consensus over the current loose case.
  227. Ge0rG dwd: last year's LC failed due to lacking consensus in the private/no-copy debate, IIRC
  228. vurpo has left
  229. vurpo has joined
  230. nicolas.verite has left
  231. kalkin has joined
  232. Ge0rG How would consensus be achieved? No opposing voices on standards@? A majority vote in members / board / council?
  233. dwd Ge0rG, Same as the IETF, I've always assumed. In practise, that's a majority of the Council believing there is consensus.
  234. MattJ Council
  235. MattJ Ge0rG, for reference: https://www.zash.se/carbons.html
  236. MattJ (and don't think that's a complete list)
  237. mancho has left
  238. Ge0rG I can't imagine that an experimental xep becomes carved in stone because it is widely implemented. At least the server implementors could provide both versions in parallel to make the upgrade path easier without breaking anything
  239. Ge0rG I've added more controversy to https://op-co.de/tmp/xep-0280.html#which-messages in the form of new MUC rules.
  240. Tobias Ge0rG, indeed...i mean that's what we have namespace versions for
  241. dwd has left
  242. dwd has joined
  243. Tobias if we wouldn't want to change anything becase *implementations*, then we might as well disregard any namespace versioning
  244. Tobias if we wouldn't want to change anything because *implementations*, then we might as well disregard any namespace versioning
  245. jonasw ^
  246. dwd Tobias, Sure, but if a spec has lots of implementations and yet is in Experimental, one has to wonder if our standards process has failed.
  247. Kev Or just it's something that needs solving sufficiently badly that people want to implement regardless. That doesn't mean it's the *right* solution.
  248. jonasw Kev: +1
  249. Tobias dwd, sure...nevertheless it shouldn't stop changes to carbons under an incremented namespace
  250. dwd So you're saying the process has failed, but we don't yet know why?
  251. Kev No, it means the process is working.
  252. Kev The point of experimental XEPs is to get implementation experience, no?
  253. Kev The process is only failing if we then say "Oh, people have taken part in this experiment, so we can't make changes".
  254. Tobias jingle file transfer is at its 5th namespace i think...swift doesn't work with all of them, it could with some work with more versions than it currently does
  255. Ge0rG And to improve based on that experience
  256. suzyo has left
  257. Tobias *namespace version
  258. dwd Kev, Either Carbons works well enough for widespread deployment (which it clearly does), and its status doesn't reflect that because our process is broken, or else we haven't managed to produce anything better, in which case our process is broken.
  259. suzyo has joined
  260. Kev Right. But the reason we haven't accepted (rather than produced, as there were solid suggestions IIRC) that 'anything better' is people clinging to "there are implementations, so we can't change things".
  261. Kev Which *is* a failure of our process, as I said above.
  262. Tobias dwd, what's the issue with allowing changes to carbons under an incremented namespace version?
  263. nicolas.verite has joined
  264. nicolas.verite has left
  265. Kev Incidentally, I *do* think that the wooly wording makes it 'good enough' (although I don't remember the nocopy implications and whether that should block it).
  266. goffi has left
  267. Ge0rG Kev: no-copy was suggested as a reusable replacement for the <private/> element that is only defined and used in 0280.
  268. Ge0rG then there was a long debate about the merits of MUST-NOT-when-private and SHOULD-NOT-when-nocopy
  269. dwd Kev, As for implementation experience, that's not what Experimental is for. It's for discussion. Draft on the other hand means "appropriate for further field experience", and one can argue the market has decided on that.
  270. Ge0rG and now it looks like at least the author and some other people agree to remove <private> and to use <no-copy> instead. And IMO this is a privacy-affecting and breaking change, so it requires a bump
  271. dwd Ge0rG, Please do work on building consensus. And note Zash's list of implementors; I'll be especially interested in seeing if those people want to update.
  272. Kev dwd: I am confident that was not the original point of Experimental. Maybe we've changed over the years so it's now what we say it's for.
  273. dwd Kev, I look forward to your proposed changes to XEP-0001. :-)
  274. Ge0rG dwd: I'm pretty sure I will fail to gain consensus in the sense that all implementors agree to follow the bump.
  275. dwd Ge0rG, Consensus, not unanimity.
  276. Kev dwd: That'd be the xep1 that says it wants people to implement Experimental XEPs?
  277. Tobias Ge0rG, doesn't have to be all, the majority of the actively maintained would be enough
  278. Kev has left
  279. dwd Kev, "While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product" ?
  280. Ge0rG dwd: I had the pleasure to coordinate a CVE with a dozen of client-only implementors in the context of Carbons, recently. It was a multi-week process which involved just a single-line change in the code.
  281. Tobias it's probably also the one that says Experimental XEPs can be expected to receive major changes
  282. Kev dwd: Sounds like it's encouraging implementation to me.
  283. Holger Ge0rG: So you have contact data of most relevant people! :-)
  284. Kev Certainly not saying what you originally said, which was that Experimental XEPs weren't for implementation.
  285. Ge0rG Holger: would you implement a bumped carbons that fixes MUC-PMs in ejabberd?
  286. dwd Kev, Sure. But not in the way Draft does: "the specification will be basis for widespread implementation and for deployment in production environments. As a result of such implementation and deployment experience, the protocol may be subject to modification, including changes that are backwards-incompatible."
  287. Kev Indeed.
  288. Ge0rG So from 0001, it is legitimate and expected to make breaking changes in both 'experimental' and 'draft'. Thus I would not consider "gaining consensus from implementors" a requirement for moving an XEP forward.
  289. Kev I don't think "There are different stages of implementation" is the same as "Experimental XEPs are for discussion not implementing", which was with what I took issue.
  290. Steve Kille has joined
  291. dwd Kev, OK, I'll accept that.
  292. Yagiza has left
  293. Tobias Ge0rG, also Experimental changes don't have to go though council, while Draft changes have to go though council
  294. Ge0rG BTW, while we are at "breaking changes". My Carbons improvments depend on an addition of an element into XEP-0045, which is "Draft", but has no namespace version.
  295. dwd Kev, Nevertheless, I'd still argue that Carbons is de-facto Draft given the state of implementation.
  296. kalkin has left
  297. Ge0rG / s/depend on/would be even better with/
  298. Holger Ge0rG: I think ejabberd's 0280 code complies to your new text, and if it doesn't it will be fixed, yes.
  299. Kev Kev 9:59 ? :)
  300. Kev Oh, nice copy/paste.
  301. Ge0rG Holger: what about private/no-copy?
  302. Kev Kev 9:59 The counter argument is that it's de-facto Draft just by the number and state of implementations. :)
  303. Holger Ge0rG: I'd continue to honor both. Or does it help anyone to ignore <private/>?
  304. Tobias the state of the implementations was nicely reflected by the CVE, not?
  305. Kev Heh.
  306. Ge0rG Holger: honoring both is perfectly fine, my point is rather: you should indicate that you honor no-copy by advertising the new namespace
  307. Holger Ge0rG: I mean I understand why you'd want to remove if from the spec for cosmetic reasons.
  308. dwd Tobias, In as much as there were a lot of them, in production software, then yes.
  309. Holger Ge0rG: Sure.
  310. Holger Ge0rG: ejabberd already advertises support for :1 and :2, we can easily add :3 to the list :-)
  311. Ge0rG Holger: could you kindly review https://github.com/ge0rg/xeps/commit/5881e42fe7e56adb13ab29c46e1d88b903fdf07b and https://op-co.de/tmp/xep-0280.html#which-messages for readability and potential logic issues.
  312. dwd Ge0rG, BTW, I have no clue why you'd equate breaking changes with no need for consensus.
  313. Ge0rG dwd: I'm not sure how you draw the conclusion that I do that
  314. dwd [11:04:21] ‎Ge0rG‎: So from 0001, it is legitimate and expected to make breaking changes in both 'experimental' and 'draft'. Thus I would not consider "gaining consensus from implementors" a requirement for moving an XEP forward.
  315. Kev I also think that's outright wrong, and that it's not expected to make changes to a Draft XEP, but that the option is there if needed.
  316. Kev *breaking changes
  317. dwd Kev, The following sentence in XEP-0001 agrees with you: "Although such backwards-incompatible modifications shall be avoided if at all possible, deployment of a Draft protocol in mission-critical application may not be advisable."
  318. Holger Ge0rG: "Clients SHOULD ignore carbon-copies of MUC-PMs related to a MUC they are not joined to." Are outgoing clients expected to add <x/> tags to PMs as well, or how would other clients detect outgoing PMs?
  319. Ge0rG dwd: 0001 allows to make breaking changes in 'experimental' and 'draft'. Therefore I do not consider the statement "client implementors can block breaking changes to such an XEP by denying consensus" as a valid excuse.
  320. Ge0rG Holger: yes, that would require changing 0045.
  321. kaboom has joined
  322. Ge0rG Holger: a client could also disco#info the bare-JID of course.
  323. Ge0rG Holger: and a carbons-enabled server that knows about the MUCciness of the MUC could inject an <x/> into the carbon
  324. Ge0rG Holger: maybe I should put all of these into a separate section?
  325. Holger I wouldn't like the idea of requiring clients to do a disco#info.
  326. Ge0rG Holger: me neither
  327. Holger Ge0rG: Aren't those details a bit out of scope?
  328. Ge0rG Holger: they are in-scope for both 0045 and 0280.
  329. Ge0rG Holger: unless we want a new XEP that only covers MUC-Carbons
  330. Holger I'd add the <x/> tagging to 0045 so that we can avoid cluttering 0280 with a list of possible strategies.
  331. Guus has left
  332. Ge0rG Holger: that is exactly what I plan to do. But it will be even harder to get consensus for that.
  333. Ge0rG Holger: so "add <x/> tagging everywhere" --> 0045. "use <x/> tag for carbon-filtering" --> 0280
  334. uc has left
  335. Holger That would be my solution, yes. The downside is that the filtering then depends on modern 0045 implementations, but in my book that outweighs the ugliness of disco#info / MUC presence tracking.
  336. Ge0rG Holger: and a server still could inject <x/> tags into messages it knows are from/to a MUC.
  337. Holger Right.
  338. Ge0rG I'm not going to propose _that_ into the XEP ;)
  339. Holger Yes that's unnecessary.
  340. winfried has left
  341. winfried has joined
  342. kaboom has left
  343. Ge0rG Are there other corner cases with carbons? Transports? MIX? anything I forgot about?
  344. kalkin has joined
  345. goffi has left
  346. Holger I think direct MUC invitations (XEP-0249) are not carbon-copied although that might be desirable?
  347. Steve Kille has left
  348. Ge0rG Holger: which rule do they fail at?
  349. Holger Ge0rG: type=normal messages are only copied if they have a body.
  350. Holger 0249 explicitly forbids a body, IIRC.
  351. Yagiza has left
  352. Flow do we need a <copy/> xep334 hint?
  353. Flow do we want one?
  354. xnyhps has left
  355. Holger I think we do (and I suggested that before).
  356. vurpo has left
  357. Holger Ge0rG: Then again, if the receiving client bookmarks the room on invitation, the other clients will follow. As everyone (*cough*) is using PEP bookmarks these days, this will be instantaneous ...
  358. Ge0rG Holger: yes. Right. But even then, what if you are not on your primary client right now?
  359. Ge0rG Holger: I'll change the invitation wording to include both directed and mediated
  360. Yagiza has joined
  361. xnyhps has left
  362. vurpo has joined
  363. Holger So servers will have to search for <x xmlns='jabber:x:conference'/> ...
  364. Guus has left
  365. nicolas.verite has joined
  366. nicolas.verite has left
  367. nicolas.verite has joined
  368. nyco has left
  369. edhelas has joined
  370. Ge0rG Holger: some MUCs also send a captcha request per normal message from bare JID prior to allowing you to join.
  371. Ge0rG But I'm sure it's fine to deliver that to any subset of the user's client, as long as it includes the one joining
  372. Holger I mean generally there's two options, either we teach 0280 about each such special case, or we teach the XEPs that define the stanzas in question to mark them appropriately (using 0334 hints or whatever).
  373. Ge0rG *clients
  374. Ge0rG Holger: MUC-PM should only be reflected to MSN sharing clients. How can you teach that?
  375. Ge0rG 'sent' ones, that is
  376. nicolas.verite has left
  377. Holger MUC PMs should die, but it seems they don't, no matter how often I repeat it!
  378. Holger They're special and I think it makes a lot of sense to mark them as such, regardless of 0280.
  379. Holger But apart from those, I'd try to avoid adding all sorts of weird rules to 0280 and rather have the sending entity mark stanzas appropriately.
  380. Ge0rG Holger: you can't just kill them, they are useful
  381. Tobias Holger, indeed...need to add some code to Swift that it will uses the real JID if it's known
  382. Holger I mean this is really about addressing an account vs. addressing an individual client. If I did XMPP from scratch I'd carbon-copy everything sent to the bare JID and nothing sent to a full JID.
  383. nicolas.verite has joined
  384. Ge0rG Currently, I'm getting something between zero and two copies to my clients, and sometimes I even can't respond.
  385. Holger We're not doing if from scratch so I'd go for hints instead, whereever it makes sense.
  386. Valerian has left
  387. Holger Ge0rG: My usual rant is that MUC PMs are only useful to the very small circle of active XMPP community members, i.e. to us. Nobody else uses anonymous rooms. But I figure we are not a negligible part of our target audience :-)
  388. nicolas.verite has left
  389. nicolas.verite has joined
  390. Ge0rG Holger: no, MUC-PMs are useful to people who use clients that don't auto-fallback to the participant's real JIDs
  391. Holger All clients would do that if they weren't all written for geeks.
  392. Steve Kille has joined
  393. Ge0rG Holger: 0045 is a pretty horrible specification. You can't argue that implementations of it are broken because they are geek-focused
  394. Holger I'm only arguing against "MUC PMs are useful".
  395. MattJ has left
  396. nicolas.verite has left
  397. Holger We're reimplementing them in MIX because we're still geek-focused.
  398. Ge0rG Holger: IMHO, proxy-JIDs in MIX are another, much more severe, side-effect of the geek-focusedness
  399. Valerian has joined
  400. dwd has left
  401. Ge0rG Holger: it doesn't take very much to fix MUC-PMs though.
  402. Holger Well same thing in my book. Anonymous rooms.
  403. Holger Anyway I'm aware that I'm quite lonely with my view, and I don't want to spam this room by repeating myself.
  404. Ge0rG Holger: and there is MUC-light for non-anon easy chatrooms
  405. Holger Yes, and MUC/Sub. Everyone does his thing because there's a strong demand and we don't get done with MIX.
  406. nicolas.verite has joined
  407. Holger > it doesn't take very much to fix MUC-PMs though. I'm all for your 0280 updates.
  408. Holger + PM tagging.
  409. Ge0rG Yay! \o/
  410. Ge0rG Why is &xep0249; creating both a note and a hyperlink?
  411. edhelas has left
  412. Tobias so if you print the document you got still all the useful information
  413. dwd has left
  414. MattJ has joined
  415. nicolas.verite has left
  416. Ge0rG updated https://op-co.de/tmp/xep-0280.html#which-messages - must return to work now
  417. nicolas.verite has joined
  418. Kev has left
  419. Steve Kille has left
  420. xnyhps has left
  421. xnyhps has left
  422. MattJ has left
  423. xnyhps has left
  424. tim@boese-ban.de has joined
  425. MattJ has joined
  426. uc has joined
  427. kaboom has joined
  428. mancho has left
  429. suzyo has left
  430. suzyo has joined
  431. jere has left
  432. jere has joined
  433. mancho has left
  434. Kev has left
  435. nicolas.verite has left
  436. Zash has left
  437. tim@boese-ban.de has joined
  438. vurpo has left
  439. vurpo has joined
  440. waqas has joined
  441. suzyo has left
  442. suzyo has joined
  443. Valerian has left
  444. Valerian has joined
  445. Piotr Nosek has left
  446. Valerian has left
  447. Valerian has joined
  448. Valerian has left
  449. Valerian has joined
  450. Kev has left
  451. Kev has left
  452. daniel has left
  453. daniel has joined
  454. jubalh has left
  455. Sonny has left
  456. jere has joined
  457. Tobias has left
  458. mancho has joined
  459. mancho has left
  460. mancho has joined
  461. Mancho has joined
  462. Mancho has left
  463. mancho has joined
  464. mancho has left
  465. mancho has joined
  466. efrit has joined
  467. mancho has left
  468. Mancho has joined
  469. Mancho has left
  470. Mancho has joined
  471. jere has joined
  472. Yagiza has left
  473. mancho has joined
  474. Yagiza has joined
  475. Flow has joined
  476. winfried has left
  477. jonasw has left
  478. mancho has left
  479. nicolas.verite has joined
  480. vurpo has left
  481. Steve Kille has joined
  482. vurpo has joined
  483. Mancho has left
  484. Mancho has left
  485. ralphm has joined
  486. Valerian has left
  487. Valerian has joined
  488. Mancho has left
  489. jcbrand has left
  490. Mancho has left
  491. nicolas.verite has left
  492. Kev has left
  493. Ge0rG Phew, just made it with #434 before the LC ends.
  494. Bunneh Ge0rG: XEP-0280: Rewrite of the 'Messages Eligible for Carbons Delivery' section #434 https://github.com/xsf/xeps/pull/434
  495. vurpo has left
  496. vurpo has joined
  497. sezuan has left
  498. lloydwatkin has joined
  499. dwd Ge0rG, Raise it on the mailing list, please.
  500. Ge0rG dwd: sure thing
  501. Valerian has left
  502. Ge0rG dwd: raised.
  503. Steve Kille has left
  504. Guus has left
  505. ralphm has left
  506. jubalh has left
  507. jere has left
  508. jere has joined
  509. Guus has left
  510. Guus has joined
  511. vurpo has left
  512. vurpo has joined
  513. pep. has left
  514. xnyhps has left
  515. ralphm Hey all, I won't be able to attend today's Board meeting.
  516. Ge0rG ralphm: you won't miss anything, last week's board meeting is still ongoing :D
  517. Mancho has left
  518. jcbrand has joined
  519. jubalh has left
  520. ralphm has left
  521. vurpo has left
  522. vurpo has joined
  523. Valerian has joined
  524. nyco Ge0rG, :-p
  525. nyco the longest one ever
  526. Zash I've noticed that many topics consists of an |-separated list.
  527. Zash Some of the items are often key-values
  528. dwd Zash, I did argue that Subject ought to be dropped in MIX because it's never used as a subject; just as a set of URLs and a description.
  529. Zash dwd: So it could be derived from name, description, other named fields in disco
  530. jubalh has left
  531. Zash And you could supposedly generate a legacy topic for MUC compat (if you have that) from that as well
  532. Zash Maybe the actual topic should go back into each message?
  533. Zash Sane real time threaded UI would be .. interesting
  534. bra has left
  535. kaboom has left
  536. jonasw yes.
  537. Lance has joined
  538. Martin Who's here for the board, then, excusing ralphm?
  539. nyco _o/
  540. Sonny has joined
  541. Sonny has joined
  542. Steve Kille has joined
  543. Martin Think that might be a bit *too* quiet…
  544. nyco meh
  545. Martin MattJ: Are you around?
  546. dwd 3/5 for quorum, BTW.
  547. kalkin has left
  548. Martin Thought as much
  549. Sonny has joined
  550. nyco so... :'(
  551. MattJ Here
  552. Martin Yeah…not looking like much of a goer really :(
  553. nyco oh
  554. Martin Oh! Signs of life.
  555. MattJ Sorry, another meeting overran
  556. Martin np
  557. Sonny has left
  558. Martin Right, the Trello board looks a bit out of date. Going by the last minutes, they seem a little out of sync too, anyone got an insight into where the most current items for discussion are?
  559. vurpo has left
  560. vurpo has joined
  561. kalkin has joined
  562. Martin …or shall we scrub down the Trello board and start with whatever's most pressing?
  563. MattJ wfm
  564. nyco there was the Summit, then GSoC, now we have space
  565. nyco yep
  566. Martin So, GSoC, still an open card on Trello
  567. nyco we have submitted, well Kevin has
  568. Martin Do we know when we're likely to hear back?
  569. Kev 27th, IIRC
  570. MattJ (thanks Kev)
  571. Martin Thanks Kev
  572. Zash has joined
  573. nyco https://developers.google.com/open-source/gsoc/timeline
  574. Martin OK, I've added the 27th to the Trello card
  575. Martin In the spirit of continuing the spring clean of the Trello board: D&0 quote, still in play?
  576. Martin (Board is here: https://trello.com/b/Dn6IQOu0/board-meetings )
  577. MattJ I guess that's a question for Peter?
  578. Martin Yup, his name's against it, so I'll leave it where it is for this week
  579. Sonny has joined
  580. Martin Moving on…Marketing project, has Arc's name against it, assuming we should leave that where it is too…?
  581. MattJ Guess so
  582. Martin Righto
  583. nyco isn't it related to FOSDEM? in which case can be closed?
  584. Martin Maybe. Could also be related to the SCAM team from last week - continuing support for the marketing activity
  585. Martin But I guess we could archive it and create a new one for SCAM support
  586. MattJ According to Trello it was moved into "Commitments for the week ahead" Oct 19, 2016
  587. Martin That's quite a long week...
  588. Martin OK, I'll archive it
  589. MattJ So I guess we're missing, or I am at least, background on this
  590. Martin Yeah, me too, I'll add something to the items for discussion for next week's meeting
  591. Steve Kille has left
  592. Kev has left
  593. Martin OK, so, what's next...
  594. goffi has left
  595. Martin Recruitment of editor team members…I vaguely recall us trying to address this right at the start of the year
  596. Martin OK, leaving that parked for now, and we're running low on time. Board priorities for 2017. An impressive entry from nyco
  597. Kev has left
  598. MattJ I think new members need to come from the pool of folk already active in the community. Given the work that Sam and others have put into improving the editor team process, there is hopefully a lower barrier to entry now
  599. Kev The quote was for indemnity insurance for directors, so we can have a treasurer again, wasn't it?
  600. nyco since the board has been elected, indeed we have no goal
  601. nyco to me that is the most important item
  602. bra has joined
  603. nyco moar promotion? moar surveys? moar software? moar... what?
  604. MattJ nyco, your list is great. As a wishlist...
  605. nyco but it's partial
  606. MattJ It's already long :)
  607. nyco it is just me listening to a fraction of the community
  608. MattJ The main thing that needs to happen is converting it to action items
  609. nyco partial, in the sense that it is not neutral
  610. MattJ Ideally small things we can tackle, prioritized
  611. nyco MattJ, before actions, agreeing
  612. nyco yeah, and spit, get people to commit
  613. nyco no, no, not spit, but split!
  614. nyco ooooops
  615. MattJ We perhaps don't need/want to spend usual board meeting time on that, but we could find some separate time to brainstorm
  616. nyco agree, more interactive, and must deliver something, not just meet for the sake of meeting
  617. nyco it makes you think?
  618. MattJ I agree that everything listed would be great to have
  619. Sonny has left
  620. MattJ But what are the things the board can do about it?
  621. nyco prioritise
  622. nyco get people to commit
  623. nyco check on the delivery?
  624. nyco in other words: do something
  625. MattJ That's my point... what is 'something'? :)
  626. nyco what we will prioritise, like in priorities
  627. MattJ Ok, first item on that list: "Make clients look and behave like the most modern and popular chat/voice clients on the market"
  628. nyco let's agree on what's most important, in one, two, or three items
  629. MattJ How are we going to do that?
  630. jonasw UX sections in the XEPs? :)
  631. nyco one action
  632. nyco remove old ones from our lists
  633. nyco maybe through financing?
  634. nyco like crowfunding?
  635. MattJ Crowdfunding for what exactly? Where would we spend the money?
  636. nyco like bounties?
  637. MattJ Assume we already have money (because we do)
  638. MattJ Money isn't the issue. What do we do with it?
  639. nyco I'm returning all the questions to you MattJ: what is your view?
  640. MattJ :)
  641. nyco Money is one issue, it was raised at Summit
  642. nyco but that's only one example
  643. MattJ I wasn't at the summit, but I fail to see it as an issue
  644. MattJ Either in the amount we have, or our ability to raise more if we need (whether that's crowdfunding, sponsorship or whatever)
  645. nyco make clients... modern... my contrib is my market analysis, for which the outcome is "the three generations of IM"
  646. nyco if we want to follow that logic, then we have to deliver on full text search in archive, chatbots and chatapps, integrations, etc.
  647. nyco that may that the shape of XEPs, of software
  648. nyco MattJ, some have money issue, it is an information
  649. nyco so let's put money aside?
  650. MattJ I'm saying "we" as the XSF, to be clear
  651. nyco how would you "make clients modern"?
  652. nyco "we" can spend some, call for donations, whatever
  653. bjc has joined
  654. nyco but make client modern is only one of the so many items
  655. nyco there is more
  656. nyco so what are this board's priorities for this term?
  657. MattJ I'm personally not a client developer. However my opinion is that client developers need more UX guidelines.
  658. nyco sure, I agree
  659. MattJ But someone has to make those guidelines
  660. uc has left
  661. Kev I am a client developer. I'm not sure I agree.
  662. MattJ Great :)
  663. uc has joined
  664. nyco correct, that's why I say set the prios and get people to commit
  665. Kev But I'm certainly I don't want the same people responsible for protocol specs giving UX advice :)
  666. nyco Kev, you're oooold!
  667. MattJ Kev, as a client developer, do you agree with the overall goal/priority of "modernizing clients"?
  668. Kev nyco: Maybe, but that's not to say I don't think clients need better UX. I'm just not sold on them all needing the same advice.
  669. nyco sure
  670. daniel I'm a client developer. I dont need guidelines. I mean having some would be kinda nice I guess. But it's far from being a top priority
  671. ralphm has left
  672. nyco taht's your opinion
  673. Kev MattJ: I think 'modernising XMPP' is a very high priority of mine at the moment, through my software and the spec work we do.
  674. jubalh has joined
  675. nyco a lot of client devs are... just... dev... without any UX knowledge
  676. MattJ Given that daniel and Kev both produced some very nice clients, I think their opinions have weight
  677. Ge0rG daniel: you are a client developer who should WRITE the guidelines. Things like "DND presence from one of the user's clients overrides all other clients' presence"
  678. nyco so some need guidelines, maybe not advices
  679. Kev I think responsibility for that is shared between implementors, spec writers, Council and Board, so I'd be happy to see anyone doing sensible things.
  680. Steve Kille has joined
  681. xnyhps has left
  682. Kev But my idea of 'sensible things' might not be the same as others.
  683. jonasw daniel: +1 to Ge0rG
  684. Kev I'd be very keen to hear Board ideas on what they think they can do to modernise XMPP.
  685. nyco MattJ, I have done pretty modern clients as well, many of them, so I have weight, as experience with working with iOS/Android/web devs AND UX designers
  686. Ge0rG maybe we can have an Easy XMPP WG? or less-formal-group
  687. nyco Ge0rG, +1
  688. nyco so, board prios
  689. daniel If someone wants to take action how about supporting JC in creating inverse. That's a single page (slack like if you will) version of converse
  690. daniel Jc agreed to do it if he gets the funding
  691. nyco it is not only "modern clients", there are plenty more stuff that needs discussion
  692. nyco what can the board do?
  693. daniel The xsf could support a funding campaign
  694. Kev daniel: Well, sure, but if people are paying JC for work on inverse, I'd like people to pay us for work on Swift please ;)
  695. nyco neutrality
  696. Martin Quite, that begins to impinge on neutrality
  697. MattJ daniel, now that's the kind of sensible action item I'd like to see more of :)
  698. Ge0rG I'd like to put a shameless plug of https://wiki.xmpp.org/web/Usability/Glossary - we need to get our terminology straight before we can fix usability
  699. nyco Ge0rG, +1
  700. MattJ I'm an advocate of XSF neutrality, but the line has to be drawn somewhere
  701. daniel It even has like an actual price tag
  702. nyco promotion is certainly a huge prio
  703. nyco not sure if highest
  704. Kev If the XSF had so much money that they could pay a UX person to look at whatever clients people wanted looked at, and give advice, I'd be all for that, FWIW.
  705. nyco Kev, +1
  706. MattJ If we can't promote or sponsor good XMPP projects, I think that's somewhat sad
  707. vurpo has left
  708. vurpo has joined
  709. Martin MattJ: I agree, and it keeps coming up. Perhaps a board action should be to revisit what the position is on neutrality
  710. daniel I think we can generally agree on that a good web client is missing in the xmpp world
  711. MattJ Indeed
  712. nyco Martin, we had that discussion at Summit
  713. Kev daniel: I think so, but which of the people working on such things should get funding? :)
  714. daniel I mean I'm not saying it's the xsfs job to do that
  715. nyco so, we are still the BOARD PRIORITIES, right? ;-)
  716. Kev Maybe the XSF could directly pay for some liberally licensed generally useful things?
  717. daniel But someone wanted an actual action item. There is one
  718. Martin nyco: Discussions are discussions, not a decision. There's clearly still a grey area here around neutrality.
  719. nyco yes
  720. Kev Make toolboxes of things that are useful for projects. Rather than supporting a particular one directly, help them all.
  721. MattJ Kev, I think that would be an obvious requirement, yes (re. licensing)
  722. nyco but as a board, we haven't set our term's priorities
  723. Kev MattJ: My point was 'generally useful' vs. 'funding a particular codebase'.
  724. MattJ nyco, if you ask most people at the moment, we should be tackling spam instead of UX :)
  725. nyco MattJ, that.
  726. SamWhited I also would argue that spam is a higher priority. I've started getting 3 or 4 messages a day the last few days.
  727. SamWhited No matter how good the UX is otherwise, that would probably rather kill it.
  728. vurpo has left
  729. vurpo has joined
  730. nyco so, we should have a dedicated meeting on board priorities? or a big consultation? or a survey?
  731. nyco then we select our top thre prios, for example
  732. Kev Board has done a survey in some past years.
  733. Martin So, board-wise, we've run over, and we need to figure out how best to collate and then rank everything that's just been discussed, and others that haven't been. Polling the membership could be useful...?
  734. nyco and then we set goals and expectations, we put actions, and commit
  735. Kev I'm not sure it's directly led to action the membership wanted, but it might be a start.
  736. nyco some tasks can be paid...
  737. Martin Feels more transparent to poll the membership, and derive goals from there, rather than just super-charging anecdote
  738. xyz has left
  739. Zash has joined
  740. MattJ I'm fine with surveying the membership, but I don't think there will be prizes for guessing the results
  741. nyco at least we will have numbers
  742. Kev The non-client devs all say "UX", while the client devs say "resources are the problem, not UX advice"? :)
  743. nyco my delivery is some kind of ad-hoc survey... without weight at all: how can you trust me?
  744. MattJ I think let's call the official meeting over for today, but the discussion is good :)
  745. nyco Kev, that's a major problem to understand
  746. daniel Kev: that's what the poll at the summit said I think
  747. nyco daniel, poll? what poll?
  748. Kev I think if Board can find a way to fund some research into combating spim (not just coming up with specs for reporting it, but proactively detecting it), that would be probably the Board's biggest contribution in recent years.
  749. nicolas.verite has joined
  750. Kev FWIW.
  751. Martin Yeah, board meeting is over I think, +1w for the next
  752. nicolas.verite has left
  753. daniel nyco: what do client developers want
  754. MattJ Martin, wfm
  755. Kev (And doesn't touch on neutrality :))
  756. Kev In fact (yes, I know meeting's over), I would really like Board to find something they can do in this space to advance the state of spim detection.
  757. Kev I know some research does exist on this.
  758. Ge0rG daniel: I want the XSF to buy me a yacht.
  759. Kev I think I have some very very smart contacts at Uni who might find this an interesting area, with funding, in fact.
  760. daniel I somehow can't imagine the pidgin developer sitting at home thinking 'I would really love to implement carbon copies right now. If I only had some ux guidelines'
  761. kaboom has joined
  762. nicolas.verite has joined
  763. nyco hehehe
  764. nyco well, not exactly, you put it like UX = UI
  765. Ge0rG the UX of Carbons is a tough beast.
  766. nyco UX can explain the "why"
  767. nicolas.verite has left
  768. Martin has left
  769. nyco Ge0rG, right
  770. Alex has joined
  771. nyco https://code.google.com/archive/p/psi-dev/issues/592
  772. Arc has joined
  773. nyco perfect example
  774. nyco autotraslate
  775. nyco Why do it? It cancels the fuss with the priorities for the same login on multiple devices. I keep very helpful. May assist in the development of assistance would be read chudnenko :) visit us in the conference will discuss all =)
  776. jubalh has left
  777. daniel nyco: a perfect example for what?
  778. nyco of misunderstanding
  779. nyco something that explain the value of an evolved user experience
  780. nyco clearly the guys of Psi+ want to stay in the ICQ era
  781. Steve Kille has left
  782. vurpo has left
  783. nyco all the priorities usage have changed, the world has changed, and continues to change, faster and faster
  784. Ge0rG nyco: we don't need to make _all_ XMPP clients _modern_. But we should give candy to the ones that are.
  785. nyco we talk
  786. MattJ nyco, I use a console client, and you won't take it away from me
  787. nyco about multi-device now, same stuff in real time in all devices (Carbons, MAM)
  788. daniel nyco: I don't see where the psi+ developer said that they want to be more like icq?
  789. Arc I love you guys. Seriously.. it puts a smile on my face whenever I open this chat
  790. vurpo has joined
  791. Arc </not-sarcastic>
  792. nyco oh a board member who is veeery late! ;-)
  793. Arc yea my phone died, im not getting alerts
  794. Arc im hoping the new battery arriving today fixes it.
  795. Yagiza has left
  796. Arc beautifully, it shit the bed while helping me navigate through London to have open source beer at a bar basically located in an alley with some gnome developers. that was fun.
  797. MattJ Ok, my considered proposal is this: that we (the XSF) provide a process through which XMPP software developers can submit proposals for funding projects
  798. Kev MattJ: Please consider my comment on spim, too, that was very very serious.
  799. Kev But I think what you say sounds sensible too.
  800. MattJ Details can be hashed out, we could even put proposals to a full membership vote if we feel that's the fairest option
  801. MattJ Sure, but any pointers on that?
  802. Ge0rG does the XSF have sufficient money to establish such a funding process?
  803. MattJ I'm not aware of any research into combatting spim, but it sounds like you might be?
  804. Zash what sayeth?
  805. Ge0rG MattJ: 1. solve spim. 2. profit!
  806. Arc MattJ: I think before we do that, we should get involved in something like Outreachy
  807. nyco I suggest not only one prio
  808. Guus has left
  809. Guus has joined
  810. Kev MattJ: I'm sure I came across some before, ages ago, but if there's serious interest in the XSF funding such a thing, I think I might have some contacts I could at least ping and discuss.
  811. Kev If Board wanted me to.
  812. vurpo has left
  813. vurpo has joined
  814. Arc https://en.wikipedia.org/wiki/Outreachy
  815. MattJ nyco, this would become a vehicle through which to turn your wishlist from that card into reality. We can use the priorities when deciding what to fund/not fund, and we can encourage software developers to apply, etc.
  816. nyco not only funding, maybe it is not only a prio
  817. nyco apparently spim is
  818. nyco "make clients more modern" may not even go through funding
  819. Zash Make things more better!
  820. MattJ nyco, "make clients more modern" is not a fundable project
  821. Ge0rG we could pay the spim senders to stop spimming.
  822. nyco MattJ, it could be
  823. nyco MattJ, fund inverse, swift, conversations...
  824. MattJ Well I'm not going to advocate funding it :)
  825. Kev has left
  826. Kev has left
  827. Zash Ge0rG: I'll send you an invoice for not sending you spim then.
  828. MattJ nyco, you're missing the *actionable* part
  829. Kev has joined
  830. MattJ There seems to be a disconnect between "make the clients more modern" and someone actually having to write code
  831. Ge0rG Zash: to the XSF
  832. nyco MattJ, it's not only about code
  833. MattJ If you want to put together a proposal for someone professional to review the UX of one or more clients, that would be great
  834. Ge0rG MattJ: that void must be filled with: a) help the developers understand UX problems b) provide UX guidelines c) do the coding
  835. Ge0rG professional UX review should be somewhere between b and c
  836. nyco Ge0rG, oh no, no, no, UX is much wider than that
  837. MattJ Kev, ok, I'll kick it into the next board meeting's topics
  838. Kev Thanks.
  839. Kev Board may have other ideas on how to help with Spim, but this seems like a discussion point.
  840. nyco Kev, agree with anti-spim initiative being one of the top prios... not the only one though!
  841. Kev Sure :)
  842. Ge0rG nyco: we can't solve all UX problems. we need to learn crawling before we can grow wings.
  843. nyco Ge0rG, there are lots of shortcuts
  844. MattJ Arc, is Outreachy similar to GSoC? or would individual projects apply?
  845. Ge0rG nyco: like jumping from a skyscraper?
  846. MattJ Arc, I think programs like that are worth it in their own right, and not a substitute for funding developers who are already intimately familiar with XMPP
  847. MattJ i.e. these would be on parallel tracks
  848. suzyo has left
  849. Arc MattJ: I agree that developers should be funded, but I don't think its the XSF's role to do that. Outreachy, perhaps.
  850. Arc I'm concerned by the XSF's lack of diversity
  851. Kev has left
  852. MattJ Then likewise, come up with some action items
  853. nicolas.verite has joined
  854. Arc MattJ: I'm not 100% certain how projects get into Outreachy, but I know who to talk to about that. Its more formal than GSoC in some ways (they're actually considered employees/interns), but more human in others
  855. MattJ employees/interns of Outreachy?
  856. Arc well Outreachy is one way to address it. Its only available to minorities; women, LGBT, and in the USA racial minorities (black, hispanic, etc). That allows it to get grants
  857. Arc MattJ: yes. because they really want to help those minorities not only get work experience but also a formal work history
  858. Arc a vast majority of Outreachy interns are women.
  859. MattJ That works better, because most projects (possibly including the XSF) would not be set up for handling employees
  860. Arc well, yes. we could of course. we have an EIN. but yea i dont think we're prepared to do the rest
  861. Arc I'm currently establishing an employer an the process is pretty deep
  862. Zash has left
  863. MattJ SamWhited, any insight into what happened with the PR I submitted? git was acting weird (which IMHO is fairly normal for git)
  864. MattJ I'm just curious what went wrong
  865. Alex has left
  866. SamWhited Git was fine, you just included commits from the previous 0.6 version that weren't actually used in master (eg. You based your branch on an old branch)
  867. Arc btw what do we have these days IRT modern XMPP client C libraries?
  868. MattJ Oh, you squashed the commits when you merged my previous PR?
  869. Mancho has left
  870. SamWhited Yah
  871. nicolas.verite has left
  872. nicolas.verite has joined
  873. MattJ Sigh
  874. MattJ goes to the corner
  875. SamWhited Master is always canonical in our repo
  876. SamWhited Or the source of truth, or whatever
  877. SamWhited It's not a big deal, I just rebased your new branch too
  878. MattJ In any repo I have say over, the whole repo is a source of truth, but I know that's not the way many git users, or github, feel
  879. Ge0rG MattJ: your DVCS is inferior! stop arguing! :D
  880. MattJ I'll be more careful next time
  881. nicolas.verite has left
  882. SamWhited Actually, even if the while repo was the source of truth, you must have based it on an old commit
  883. nicolas.verite has joined
  884. SamWhited Because the conflict was the two <initials>
  885. MattJ Before I pushed git was acting weird, asking me to merge stuff that didn't make sense
  886. Ge0rG hg does that to me all the time. And then there is this crazy text editor with three different window-things
  887. nicolas.verite has left
  888. winfried has left
  889. goffi has left
  890. MattJ I'm convinced that some people just have a mental model suited to git, and some hg, and that's that
  891. goffi has left
  892. Arc you like hg too?
  893. waqas Some people like emacs. Some like vim. Then there is the rest of the planet.
  894. Lance has left
  895. Tobias who doesn't like hg, it just has superior usability
  896. Arc :-D
  897. SamWhited I disagree; I know how to use both, and I think HG is much less usable.
  898. Ge0rG Tobias: hg has horrible usability. It is mockig me every time I try to use it.
  899. Ge0rG *mocking
  900. Zash HOLY WAR!
  901. Tobias i mostly use git through a GUI so I don't things up, which was quite easy to do a couple years ago
  902. waqas Yeah, CLIs have terrible usability for git
  903. waqas Or hg
  904. Zash MattJ: So they rewrote/rebased commits you published?
  905. MattJ Zash, yes. It's a checkbox in the Github UI iirc
  906. SamWhited I don't recall if I did or not, but I probably did
  907. Tobias waqas, sure..but even at CLI level i find hg more usable than git, but hey...either can interoperate with both repos, so hey
  908. Zash The data model is basically the same too
  909. Ge0rG my pet peeve with hg is "hg pull" which tells me it knows what I want but it won't do it and go RTFM
  910. Zash Ge0rG: Didn't you say fetch?
  911. Ge0rG Zash: ah, yes. it was 'fetch'
  912. Ge0rG It's been a long day, and my train is arriving in 10 minutes. Good night everyone :)
  913. vurpo has left
  914. vurpo has joined
  915. Zash `hg fetch` is some deprecated plugin that sounds like it does what `git pull` does.
  916. Arc again, anyone know of a modern XMPP client library for C?
  917. Zash But there's `hg pull --{update,merge,rebase}`
  918. Tobias libstrophe, but it's probably not modern
  919. Ge0rG C is not modern.
  920. Zash Define modern
  921. Alex has joined
  922. Arc it has a maintainer, work has been done on it in the last 12 months, supports session management and MAM
  923. Arc the list on xmpp.org includes mostly dead projects
  924. Ge0rG Didn't we define a process to kill dead projects from the list?
  925. Arc i didnt make it to this week's meeting, but last i knew we asked Council for 2017 guidelines
  926. Arc hmm, maybe I'll go for Rust this time. I'm starting a new commercial project, has to be portable.
  927. dwd has left
  928. Ge0rG But the 2017 guidelines are not going to solve the dead projects problem
  929. dwd has left
  930. jubalh has joined
  931. Arc Ge0rG: my proposal was to have projects re-apply, and ask them for modern compliance information
  932. Arc so we need the 2017 guidelines to start that process
  933. Tobias wasn't the consensus to just have them reapply yearly, but accept any XMPP, regardless of compliance?
  934. Arc Tobias: yes, but compliance information is important to ask and report still.
  935. Ge0rG Arc: can't we just have the projects reapply?
  936. Arc nobody said they wouldn't be listed if they didn't comply.
  937. Zash inactive projects could be sorted lower and lower down
  938. Ge0rG Arc: but now the process is blocked until a new set of guidelines is defined
  939. kaboom has left
  940. Arc Ge0rG: it can't be that hard for council...
  941. Arc 2016 guidelines, whats new?
  942. SamWhited I love Rust, but beware: I think it's still 3 years out or so from having enough library/community/infrastructure support to be usable for complex commercial products. YMMV
  943. kalkin has left
  944. Ge0rG Arc: 2016 guidelines are neither finished nor implementable
  945. kalkin has joined
  946. Ge0rG Can we please just start a dead projects grace period now?
  947. Arc im not opposed to that
  948. Ge0rG Somebody needs to post to jdev then.
  949. vurpo has left
  950. Alex has left
  951. Ge0rG We are still in the eternal board meeting btw
  952. sezuan has left
  953. MattJ How many?
  954. Tobias MattJ, how many what?
  955. MattJ Open meetings
  956. Arc did the board meeting not happen this week?
  957. Arc I saw some trello cards got managed
  958. Arc SamWhited: well, its portable now. I understand what you're saying
  959. nicolas.verite has joined
  960. kalkin has left
  961. Arc LoudMouth is dead. My fork of it needs to pivot, it was going more glib/gobject but that lacks portability, and the asm.js for gobject stuff is effectively dead
  962. nicolas.verite has left
  963. SamWhited I thought gobject/glib was supposed to be super portable these days? (I'm curious, because I don't actually know, someone just told me this recently)
  964. Arc i could ease back into coding for the next week by refactoring into Rust
  965. Arc SamWhited: its not portable to asm.js/webasm nor to mobile. i wish it was. it was suppose to be.
  966. Mancho has left
  967. jonasw has left
  968. SamWhited ah, right
  969. Arc I've invested a lot of energy into Vala, but the Gnome foundation at this point is pivoting away from that and to Rust.
  970. Arc that's why I grabbed a beer with the gnome guys in London
  971. SamWhited I never did understand the point of Vala
  972. Arc back when I started Maja looked very promising
  973. nicolas.verite has joined
  974. Arc Vala was intended to be a GObject-native language. and it is, it works great. But its tied to GObject/Gnome.
  975. SamWhited yah, having such a domain specific language felt pointless to me; no matter how nice it was.
  976. Arc like much of Gnome it lacks the developer interest to really shine. even basic things like llvm support are still years off
  977. Arc i just browsed around, Rust seems to lack a decent xmpp client library.
  978. Arc I could spend about a week to refactor all of lightmelody into rust
  979. SamWhited Link Mauve sent me one recently; I haven't looked at it to see if it's "decent" or not yet though.
  980. SamWhited Can't remember where it is right now
  981. Link Mauve https://gitlab.com/lumi/xmpp-rs
  982. nicolas.verite has left
  983. Arc Can I use it yet? No, there's still a lot of work that needs to be done before this could be used for anything.
  984. Arc :-/
  985. Link Mauve It’s very much wip, you may want to talk to lumi in jdev@ about it.
  986. Arc so, yea I'll be spending the next week refactoring lightmelody.
  987. jcbrand has left
  988. Link Mauve He started it right after FOSDEM.
  989. Arc no its ok. this kinda needs to happen anyway
  990. nicolas.verite has joined
  991. Link Mauve Arc, your website seems down.
  992. Arc doing a rust refactoring is more about me than anything. i need something to keep from being bored right now, and im still on doctor ordered break until the end of the month. refactoring and learning rust should be low impact
  993. Arc Link Mauve: what website
  994. xyz has joined
  995. Link Mauve lightmelody.org.
  996. Arc oh there's no website there, just a landing page
  997. Arc also it looks like the old server is down. i should actually do the migration today instead
  998. Arc as soon as the new battery arrives from amazon this afternoon i'll call in and get it rebooted
  999. Arc Link Mauve: lightmelody vs loudmouth.. goal is to be 100% api compatible with loudmouth 1.4, but shedding all the old dependencies. so eg it uses gio instead of gnet. it also adds OAuth2 auth (gsoc student project last year) and a few other key features
  1000. Arc loudmouth is usable, just bitrotten. too many outdated dependencies.
  1001. Arc there's a lot of software that still uses loudmouth, including some surprising ones like random games on Steam
  1002. Link Mauve That sounds useful!
  1003. nicolas.verite has left
  1004. Arc there's an up-side; if i port it to Rust, we can solve the one API variance to loudmouth 1.4 which is the LM_Message_Type which overlaps with gobject's builtin "type" method of lm.message
  1005. Arc it can still expose the same C API.
  1006. Arc that way it could ALSO offer a Rust API.
  1007. Steve Kille has joined
  1008. Kev has joined
  1009. winfried has left
  1010. nicolas.verite has joined
  1011. suzyo has joined
  1012. Kev has left
  1013. kalkin has joined
  1014. jere has joined
  1015. uc has left
  1016. kaboom has joined
  1017. jubalh has left
  1018. Zash has joined
  1019. dwd has left
  1020. Tobias somebody with pelican knowledge here?
  1021. dwd has left
  1022. goffi has joined
  1023. xyz has left
  1024. Steve Kille has left
  1025. Tobias has left
  1026. kalkin has left
  1027. dwd has left
  1028. kalkin has joined
  1029. dwd has left
  1030. mathieui I use it
  1031. Valerian has left
  1032. Valerian has joined
  1033. mathieui not sure if that counts as knowledge
  1034. Guus in the land of the blind, the one-eyed man is king.
  1035. Tobias regarding our client/library/server lists, I wonder how you'd handle data tables in dedicated files and filter them at build time
  1036. Tobias has joined
  1037. jcbrand has joined
  1038. Zash has joined
  1039. mathieui Tobias, probably a special anchor that gets replaced through sed… I don’t think rST supports inclusion of other file
  1040. mathieui there’s a PR to add some markdown syntax for this
  1041. Tobias yeah..we already use SED to insert the XEP list
  1042. Tobias makes you wonder why use pelican at all :)
  1043. Zash pandoc all the things
  1044. peter has joined
  1045. Lance has joined
  1046. Steve Kille has joined
  1047. Kev has joined
  1048. mathieui better use xslt for everything
  1049. Zash pandoc -t json | jq . | pandoc -t whateveryouwant
  1050. vurpo has left
  1051. Tobias yeah..back to the beginning with XSLT + Server side includes
  1052. Tobias :D
  1053. Tobias the happy world
  1054. Valerian has left
  1055. suzyo has left
  1056. Valerian has joined
  1057. suzyo has joined
  1058. kaboom has left
  1059. Kev has left
  1060. Kev has joined
  1061. nicolas.verite has left
  1062. jcbrand has left
  1063. Valerian has left
  1064. Steve Kille has left
  1065. Valerian has joined
  1066. Lance has left
  1067. uc has joined
  1068. goffi has left
  1069. Vinilox has left
  1070. uc has left
  1071. Lance has left
  1072. Kev has left
  1073. Valerian has left
  1074. Steve Kille has joined
  1075. uc has joined
  1076. uc has left
  1077. moparisthebest has joined
  1078. Valerian has joined
  1079. Alex has joined
  1080. Lance has left
  1081. kaboom has joined
  1082. Steve Kille has left
  1083. Lance has left
  1084. Melvin has joined
  1085. uc has joined
  1086. sezuan has left
  1087. Valerian has left
  1088. Alex has left
  1089. uc has left
  1090. Alex has joined
  1091. peter has left
  1092. nicolas.verite has joined
  1093. Kev has joined
  1094. uc has joined
  1095. Guus has left
  1096. Valerian has joined
  1097. Valerian has left
  1098. uc has left
  1099. Piotr Nosek has joined
  1100. Alex has left
  1101. Zash has joined
  1102. Kev has left
  1103. suzyo has left
  1104. suzyo has joined
  1105. blipp has joined
  1106. Melvin has left
  1107. blipp has joined
  1108. daniel has left
  1109. Steve Kille has joined
  1110. uc has joined
  1111. vurpo has left
  1112. vurpo has left
  1113. uc has left
  1114. vurpo has joined
  1115. suzyo has left
  1116. suzyo has joined
  1117. uc has joined
  1118. mimi89999 has left
  1119. Kev has left
  1120. mimi89999 has joined
  1121. bjc has left
  1122. bjc has joined
  1123. uc has left
  1124. tim@boese-ban.de has joined
  1125. uc has joined
  1126. suzyo has left
  1127. efrit has left
  1128. efrit has joined
  1129. daniel has left
  1130. efrit has joined
  1131. efrit has joined