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