- SamWhited has left
- winfried has left
- Holger has left
- winfried has left
- Flow has joined
-
Flow
SamWhited: Are you processing the ISR-SASL2 protoXEP or shall I?
-
SamWhited
Flow: Go ahead; you sent an update that was still broken. Please make sure CI passes before merging.
-
Flow
SamWhited: Does CI also run for inbox?
-
SamWhited
Flow: No, I couldn't get building things in the inbox to work
-
Flow
SamWhited: https://github.com/xsf/xeps/pull/454/commits/314b0207d109d8fbc13725d964f2d46a8d6d8784 If there are no objections, then I'm going to merge it
-
SamWhited
Flow: I think adding stuff to link is going to break things
-
Flow
turns out it was the dtd who is broken
-
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
-
SamWhited
Flow: 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)
-
Flow
sylistic reasons
-
Flow
It work for HTML, i.e. it does what you would expect
-
SamWhited
Does it work for PDFs?
-
SamWhited
And references?
-
Flow
there are no references
-
Flow
it's a direct link
-
Flow
and I'm missing texml here locally to generate the pdf
-
SamWhited
You should probably just follow the DTD then if you can't test the changes
-
Flow
or I test the changes, and if it works I change the dtd
-
SamWhited
sure, although we should probably still ask for guidance; I just don't have confidence that this won't break things.
-
SamWhited
I'm sure somebody understands our build process better though
-
SamWhited
Kev maybe
- SamWhited has left
-
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.
-
Flow
uh, and it appears that the "put the reference only once" change does not work for PDFs
-
SamWhited
In PDFs references are end notes not footnotes, so it doesn't need to put them only once
-
SamWhited
err, footnotes not end notes, I mean
- SamWhited has joined
-
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
-
SamWhited
Ah, sorry, I see; yah, you're right
-
SamWhited
I thought it actually was fixed in that case, but I guess not
-
SamWhited
(as in, I thought LaTeX deduped them for you)
-
Flow
latex certainly does, I guess your input is just different references
-
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.
-
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.
-
SamWhited
think about it for a while first, I mean
-
SamWhited
but ¯\_(ツ)_/¯ I guess if it works it's up to you
-
Flow
SamWhited: the build process in this case was gen.py on perseus
-
SamWhited
Oh, gen.py doesn't actually check anything against the DTD IIRC
-
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
-
SamWhited
Why didn't we before? I can't remember
-
SamWhited
Pretty sure there was something important that would break, but I don't know what it was
-
SamWhited
Flow: I *think* I've added you to the Trello, FYI. Not 100% sure…
-
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
-
SamWhited
That seems fine; was that why we didn't do it before?
-
Flow
SamWhited: I don't remember, maybe someone was opposing the idea to split code and data in two repos. I like the idea
-
Flow
I remember mopharisisbest offering his help
-
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.
-
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
-
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)
-
Flow
SamWhited: why do we need someone from infra?
-
Flow
We already do most of the build and publishing process by hand
-
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.
-
SamWhited
And we should not mess with anything on perseus without Kev or someone making sure the infrastructure won't just break
-
Kev
Hmm? Highlight?
-
Flow
as I said, we won't move anything in the first step
-
Flow
I'm also unsure if there exists anything that runs gen.py automatically
-
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.
-
SamWhited
I'm not saying we shouldn't do it, just that we would need to coordinate with others.
-
SamWhited
Kev: Oops, sorry, just discussing moving tools out of the xeps repo again
-
Flow
probably, but I don't see this as an issue
-
SamWhited
I was just saying that we shouldn't touch anything on perseus without your buy in
-
Kev
Ah, ok.
-
Kev
Sorry, I'll be heading out in a moment.
-
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).
-
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.
-
Flow
I don't think complete rewrites are bad as long as the can act as drop in replacements
-
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.
-
Flow
and what is bad if that happens?
-
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.
-
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
-
Flow
I don't buy that argument
-
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
-
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
-
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"
-
Flow
but anyway, what I propose is that we create an xsf-tools repo and copy the tooling from the xeps repo over
-
Flow
and then start working improving the tooling towards what we want in the new xsf-tools
-
SamWhited
yes, I think that might be a sane starting point
-
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.
-
SamWhited
ahh, that's what it was
-
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
-
Flow
I think it's trivial to add the git revisions of the involved repos into the produced artifacts
-
Kev
That's not the same thing.
-
Flow
and I note that we alrady don't know which version was used to build the artifacts
-
SamWhited
That's a good point; it wouldn't be a regression, it would be exactly the same as what we have today
-
Flow
I think I don't have any objections making xsf-tools a submodule of xeps
-
Kev
SamWhited: No, I don't think that's true.
-
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.
-
Kev
(because they're tied)
-
Flow
that way the xsf-tools repo could try to autodetect the official xeps repo as being one level up the directory tree
-
SamWhited
oh, I see, right
-
SamWhited
sorry, I know we've had this exact discussion before, it's just been too long
-
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 ?
-
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 :)
-
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
-
SamWhited
I'm no so against it that I would object, I just doubt it will ever actually get updated.
-
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
-
Flow
uh, another nit, can we go for python3?
-
SamWhited
Flow: 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.)
-
Flow
what does that mean exaclty?
-
Flow
ah com
-
SamWhited
Flow: Just do one thing to start, then we can think about python3
-
Flow
apt install python3
-
Flow
SamWhited: let's ask iteam if python3 on perseus would be possible
-
Flow
if yes, we go for python3
-
SamWhited
Let's move the files to a new repo first.
-
SamWhited
And then try experimenting with python3.
- winfried has left
- SamWhited has left
- bear has left
- bear has joined
- Flow has left
- Flow has left
- winfried has left
- winfried has left