FlowSamWhited: Are you processing the ISR-SASL2 protoXEP or shall I?
SamWhitedFlow: Go ahead; you sent an update that was still broken. Please make sure CI passes before merging.
FlowSamWhited: Does CI also run for inbox?
SamWhitedFlow: No, I couldn't get building things in the inbox to work
FlowSamWhited: https://github.com/xsf/xeps/pull/454/commits/314b0207d109d8fbc13725d964f2d46a8d6d8784
If there are no objections, then I'm going to merge it
SamWhitedFlow: I think adding stuff to link is going to break things
Flowturns out it was the dtd who is broken
SamWhitedI'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
SamWhitedFlow: In this particular case, why don't you just use &xep0198;?
SamWhited(and not link directly to the section since it's in the text anyways)
Flowsylistic reasons
FlowIt work for HTML, i.e. it does what you would expect
SamWhitedDoes it work for PDFs?
SamWhitedAnd references?
Flowthere are no references
Flowit's a direct link
Flowand I'm missing texml here locally to generate the pdf
SamWhitedYou should probably just follow the DTD then if you can't test the changes
Flowor I test the changes, and if it works I change the dtd
SamWhitedsure, although we should probably still ask for guidance; I just don't have confidence that this won't break things.
SamWhitedI'm sure somebody understands our build process better though
SamWhitedKev maybe
SamWhitedhas left
FlowSo 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.
Flowuh, and it appears that the "put the reference only once" change does not work for PDFs
SamWhitedIn PDFs references are end notes not footnotes, so it doesn't need to put them only once
SamWhitederr, footnotes not end notes, I mean
SamWhitedhas joined
FlowSamWhited: 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
SamWhitedAh, sorry, I see; yah, you're right
SamWhitedI thought it actually was fixed in that case, but I guess not
SamWhited(as in, I thought LaTeX deduped them for you)
Flowlatex certainly does, I guess your input is just different references
FlowSamWhited: 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.
SamWhitedI 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.
SamWhitedthink about it for a while first, I mean
SamWhitedbut ¯\_(ツ)_/¯ I guess if it works it's up to you
FlowSamWhited: the build process in this case was gen.py on perseus
SamWhitedOh, gen.py doesn't actually check anything against the DTD IIRC
Flowthat'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
SamWhitedWhy didn't we before? I can't remember
SamWhitedPretty sure there was something important that would break, but I don't know what it was
SamWhitedFlow: I *think* I've added you to the Trello, FYI. Not 100% sure…
FlowSamWhited: 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
SamWhitedThat seems fine; was that why we didn't do it before?
FlowSamWhited: I don't remember, maybe someone was opposing the idea to split code and data in two repos. I like the idea
FlowI remember mopharisisbest offering his help
SamWhitedI 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.
SamWhitedAlso 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
SamWhitedWhich 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)
FlowSamWhited: why do we need someone from infra?
FlowWe already do most of the build and publishing process by hand
SamWhitedFlow: 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.
SamWhitedAnd we should not mess with anything on perseus without Kev or someone making sure the infrastructure won't just break
KevHmm? Highlight?
Flowas I said, we won't move anything in the first step
FlowI'm also unsure if there exists anything that runs gen.py automatically
SamWhitedFlow: 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.
SamWhitedI'm not saying we shouldn't do it, just that we would need to coordinate with others.
SamWhitedKev: Oops, sorry, just discussing moving tools out of the xeps repo again
Flowprobably, but I don't see this as an issue
SamWhitedI was just saying that we shouldn't touch anything on perseus without your buy in
KevAh, ok.
KevSorry, I'll be heading out in a moment.
KevBut I'll repeat my usual comment that incremental change is good, complete rewrites are bad (and is what stopped it all last time).
SamWhitedFlow: 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.
FlowI don't think complete rewrites are bad as long as the can act as drop in replacements
SamWhitedThey 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.
Flowand what is bad if that happens?
SamWhitedNothing'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.
FlowIf we have someone who says: "He I will help you" then you say, no don't do it because complete rewrites are bad
FlowI don't buy that argument
SamWhitedNo one said that, that's why someone volunteered last time, and I still don't see a complete rewrite or any other progress
Flowlast 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
SamWhitedoh, 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"
Flowbut anyway, what I propose is that we create an xsf-tools repo and copy the tooling from the xeps repo over
Flowand then start working improving the tooling towards what we want in the new xsf-tools
SamWhitedyes, I think that might be a sane starting point
KevAs 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.
SamWhitedahh, that's what it was
FlowI 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
FlowI think it's trivial to add the git revisions of the involved repos into the produced artifacts
KevThat's not the same thing.
Flowand I note that we alrady don't know which version was used to build the artifacts
SamWhitedThat's a good point; it wouldn't be a regression, it would be exactly the same as what we have today
FlowI think I don't have any objections making xsf-tools a submodule of xeps
KevSamWhited: No, I don't think that's true.
KevCurrently you can check out a commit of the XEP source and know exactly what version of the tools you need to build that commit.
Kev(because they're tied)
Flowthat way the xsf-tools repo could try to autodetect the official xeps repo as being one level up the directory tree
SamWhitedoh, I see, right
SamWhitedsorry, I know we've had this exact discussion before, it's just been too long
Flowso 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 ?
KevI 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 :)
SamWhitedI 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
SamWhitedI'm no so against it that I would object, I just doubt it will ever actually get updated.
FlowI can't promise to start tomorrow, i've a freelance job left for this month that has priority, but after that, count me in
Flowuh, another nit, can we go for python3?
SamWhitedFlow: Incremental improvement please
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.)
Flowwhat does that mean exaclty?
Flowah com
SamWhitedFlow: Just do one thing to start, then we can think about python3
Flowapt install python3
FlowSamWhited: let's ask iteam if python3 on perseus would be possible
Flowif yes, we go for python3
SamWhitedLet's move the files to a new repo first.