XSF Editor Team - 2017-03-20

  1. SamWhited has left
  2. winfried has left
  3. Holger has left
  4. winfried has left
  5. Flow has joined
  6. Flow SamWhited: Are you processing the ISR-SASL2 protoXEP or shall I?
  7. SamWhited Flow: Go ahead; you sent an update that was still broken. Please make sure CI passes before merging.
  8. Flow SamWhited: Does CI also run for inbox?
  9. SamWhited Flow: No, I couldn't get building things in the inbox to work
  10. Flow SamWhited: https://github.com/xsf/xeps/pull/454/commits/314b0207d109d8fbc13725d964f2d46a8d6d8784 If there are no objections, then I'm going to merge it
  11. SamWhited Flow: I think adding stuff to link is going to break things
  12. Flow turns out it was the dtd who is broken
  13. SamWhited I'm not sure that it is; I don't fully understand the consequences of that change, but I doubt stuff in link other than text was left out purely by mistake
  14. SamWhited Flow: In this particular case, why don't you just use &xep0198;?
  15. SamWhited (and not link directly to the section since it's in the text anyways)
  16. Flow sylistic reasons
  17. Flow It work for HTML, i.e. it does what you would expect
  18. SamWhited Does it work for PDFs?
  19. SamWhited And references?
  20. Flow there are no references
  21. Flow it's a direct link
  22. Flow and I'm missing texml here locally to generate the pdf
  23. SamWhited You should probably just follow the DTD then if you can't test the changes
  24. Flow or I test the changes, and if it works I change the dtd
  25. SamWhited sure, although we should probably still ask for guidance; I just don't have confidence that this won't break things.
  26. SamWhited I'm sure somebody understands our build process better though
  27. SamWhited Kev maybe
  28. SamWhited has left
  29. Flow So I build the PDF successfully, I don't think there is a reason not to merge this. And even discover later issues, we can revert the change.
  30. Flow uh, and it appears that the "put the reference only once" change does not work for PDFs
  31. SamWhited In PDFs references are end notes not footnotes, so it doesn't need to put them only once
  32. SamWhited err, footnotes not end notes, I mean
  33. SamWhited has joined
  34. Flow SamWhited: same problem: If you have multiple references on the same page you end up with multiple footnotes of the same reference on the same page
  35. SamWhited Ah, sorry, I see; yah, you're right
  36. SamWhited I thought it actually was fixed in that case, but I guess not
  37. SamWhited (as in, I thought LaTeX deduped them for you)
  38. Flow latex certainly does, I guess your input is just different references
  39. Flow SamWhited: So, since I was able to generate the HTML and PDF, I'm going to merge 454 and if things really fall apart, what I don't expect, we can revert.
  40. SamWhited I still think we should ask someone who knows what they're doing first or think about it; I don't understand our build process, so maybe I'm just being paranoid, but allowing stuff in links still seems like a huge change.
  41. SamWhited think about it for a while first, I mean
  42. SamWhited but ¯\_(ツ)_/¯ I guess if it works it's up to you
  43. Flow SamWhited: the build process in this case was gen.py on perseus
  44. SamWhited Oh, gen.py doesn't actually check anything against the DTD IIRC
  45. Flow that's right, and IMHO should be changed. But I also did a 'make'. I still think it would be vastly beneficial if we would put the tooling into a xep-tooling repo
  46. SamWhited Why didn't we before? I can't remember
  47. SamWhited Pretty sure there was something important that would break, but I don't know what it was
  48. SamWhited Flow: I *think* I've added you to the Trello, FYI. Not 100% sure…
  49. Flow SamWhited: Nothing would break if we make it a two phase step: 1 freeze every tool in the existing xeps repo 2. once the tools in xsf-tools are ready, switch
  50. SamWhited That seems fine; was that why we didn't do it before?
  51. Flow SamWhited: I don't remember, maybe someone was opposing the idea to split code and data in two repos. I like the idea
  52. Flow I remember mopharisisbest offering his help
  53. SamWhited I think whomever offered to help wanted to do a rewrite instead of just splitting it out into a new repo; maybe scope creep is why it didn't happen. That's why tooling improvements normally don't happen.
  54. SamWhited Also it would need someone on the infrastructure team side to fix the build process since the tooling wouldn't just be in the repo anymore
  55. SamWhited Which I suspect would involve getting rid of the hg repo thing (which would make me very happy, but we'd still have to find someone to do that)
  56. Flow SamWhited: why do we need someone from infra?
  57. Flow We already do most of the build and publishing process by hand
  58. SamWhited Flow: If we move gen.py out of the xeps repo, it won't be in the hg thing to run it, and anything doing automatic stuff (which I thhink exists?) will break.
  59. SamWhited And we should not mess with anything on perseus without Kev or someone making sure the infrastructure won't just break
  60. Kev Hmm? Highlight?
  61. Flow as I said, we won't move anything in the first step
  62. Flow I'm also unsure if there exists anything that runs gen.py automatically
  63. SamWhited Flow: Not necessarily gen.py; any tool, doesn't matter. We are unsure, that's correct, and that's why we'd need to pull in other people.
  64. SamWhited I'm not saying we shouldn't do it, just that we would need to coordinate with others.
  65. SamWhited Kev: Oops, sorry, just discussing moving tools out of the xeps repo again
  66. Flow probably, but I don't see this as an issue
  67. SamWhited I was just saying that we shouldn't touch anything on perseus without your buy in
  68. Kev Ah, ok.
  69. Kev Sorry, I'll be heading out in a moment.
  70. Kev But I'll repeat my usual comment that incremental change is good, complete rewrites are bad (and is what stopped it all last time).
  71. SamWhited Flow: I don't think it's a problem either, I just think it's a thing that requires doing and is worth keeping in mind, which is all I said originally.
  72. Flow I don't think complete rewrites are bad as long as the can act as drop in replacements
  73. SamWhited They are bad, because every time we have this discussion someone says they're going to do a complete rewrite, and then realizes that it would be a full time job and doesn't and nothing gets done.
  74. Flow and what is bad if that happens?
  75. SamWhited Nothing's bad if it happens, but it never does; trying it yet again and thinking it will be different this time is literally what happens every single time and for some reason people are still arguing for it.
  76. Flow If we have someone who says: "He I will help you" then you say, no don't do it because complete rewrites are bad
  77. Flow I don't buy that argument
  78. SamWhited No one said that, that's why someone volunteered last time, and I still don't see a complete rewrite or any other progress
  79. Flow last time mopharisbest volunteerd we said he can't start working because people thought it was a bad idea to split the tools into an extra repo
  80. SamWhited oh, maybe I'm misremembering then; I thought it was like Kev said, that we wanted to just move the tools and then people said "no, let's do a complete rewrite instead"
  81. Flow but anyway, what I propose is that we create an xsf-tools repo and copy the tooling from the xeps repo over
  82. Flow and then start working improving the tooling towards what we want in the new xsf-tools
  83. SamWhited yes, I think that might be a sane starting point
  84. Kev As long as they're tightly coupled somehow (presumably submodules), so you can always work out what version of the tools were used to build that version of the XEPs, I don't much care.
  85. SamWhited ahh, that's what it was
  86. Flow I would have done that months ago if I had been sure that this effort would lead to something which was actually used by someone in the end
  87. Flow I think it's trivial to add the git revisions of the involved repos into the produced artifacts
  88. Kev That's not the same thing.
  89. Flow and I note that we alrady don't know which version was used to build the artifacts
  90. SamWhited That's a good point; it wouldn't be a regression, it would be exactly the same as what we have today
  91. Flow I think I don't have any objections making xsf-tools a submodule of xeps
  92. Kev SamWhited: No, I don't think that's true.
  93. Kev Currently you can check out a commit of the XEP source and know exactly what version of the tools you need to build that commit.
  94. Kev (because they're tied)
  95. Flow that way the xsf-tools repo could try to autodetect the official xeps repo as being one level up the directory tree
  96. SamWhited oh, I see, right
  97. SamWhited sorry, I know we've had this exact discussion before, it's just been too long
  98. Flow so do we have consensus on 1. creating xsf-tools, 2. copying the code from xsf repo over 3. making xsf-tools/ a submodule of xsf ?
  99. Kev I don't think it buys us much, but I don't object to it if it's going to make incremental improvements to the tools easier for you :)
  100. SamWhited I don't like the idea of the submodule, but for the sake of not going through all this yet again then fuck it, if you want to do the work then go for it
  101. SamWhited I'm no so against it that I would object, I just doubt it will ever actually get updated.
  102. Flow I can't promise to start tomorrow, i've a freelance job left for this month that has priority, but after that, count me in
  103. Flow uh, another nit, can we go for python3?
  104. SamWhited Flow: Incremental improvement please
  105. SamWhited (I would love it to be python3 compatible, but that's yet another thing the iteam would have to work on, we'd have to compatibility test, etc.)
  106. Flow what does that mean exaclty?
  107. Flow ah com
  108. SamWhited Flow: Just do one thing to start, then we can think about python3
  109. Flow apt install python3
  110. Flow SamWhited: let's ask iteam if python3 on perseus would be possible
  111. Flow if yes, we go for python3
  112. SamWhited Let's move the files to a new repo first.
  113. SamWhited And then try experimenting with python3.
  114. winfried has left
  115. SamWhited has left
  116. bear has left
  117. bear has joined
  118. Flow has left
  119. Flow has left
  120. winfried has left
  121. winfried has left