XSF Editor Team - 2017-03-20

SamWhited: Are you processing the ISR-SASL2 protoXEP or shall I?

Flow: Go ahead; you sent an update that was still broken. Please make sure CI passes before merging.

SamWhited: Does CI also run for inbox?

Flow: No, I couldn't get building things in the inbox to work

SamWhited: https://github.com/xsf/xeps/pull/454/commits/314b0207d109d8fbc13725d964f2d46a8d6d8784 If there are no objections, then I'm going to merge it

Flow: I think adding stuff to link is going to break things

turns out it was the dtd who is broken

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

Flow: In this particular case, why don't you just use &xep0198;?

(and not link directly to the section since it's in the text anyways)

sylistic reasons

It work for HTML, i.e. it does what you would expect

Does it work for PDFs?

And references?

there are no references

it's a direct link

and I'm missing texml here locally to generate the pdf

You should probably just follow the DTD then if you can't test the changes

or I test the changes, and if it works I change the dtd

sure, although we should probably still ask for guidance; I just don't have confidence that this won't break things.

I'm sure somebody understands our build process better though

Kev maybe

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.

uh, and it appears that the "put the reference only once" change does not work for PDFs

In PDFs references are end notes not footnotes, so it doesn't need to put them only once

err, footnotes not end notes, I mean

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

Ah, sorry, I see; yah, you're right

I thought it actually was fixed in that case, but I guess not

(as in, I thought LaTeX deduped them for you)

latex certainly does, I guess your input is just different references

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.

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.

think about it for a while first, I mean

but ¯\_(ツ)_/¯ I guess if it works it's up to you

SamWhited: the build process in this case was gen.py on perseus

Oh, gen.py doesn't actually check anything against the DTD IIRC

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

Why didn't we before? I can't remember

Pretty sure there was something important that would break, but I don't know what it was

Flow: I *think* I've added you to the Trello, FYI. Not 100% sure…

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

That seems fine; was that why we didn't do it before?

SamWhited: I don't remember, maybe someone was opposing the idea to split code and data in two repos. I like the idea

I remember mopharisisbest offering his help

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.

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

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)

SamWhited: why do we need someone from infra?

We already do most of the build and publishing process by hand

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.

And we should not mess with anything on perseus without Kev or someone making sure the infrastructure won't just break

Hmm? Highlight?

as I said, we won't move anything in the first step

I'm also unsure if there exists anything that runs gen.py automatically

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.

I'm not saying we shouldn't do it, just that we would need to coordinate with others.

Kev: Oops, sorry, just discussing moving tools out of the xeps repo again

probably, but I don't see this as an issue

I was just saying that we shouldn't touch anything on perseus without your buy in

Ah, ok.

Sorry, I'll be heading out in a moment.

But I'll repeat my usual comment that incremental change is good, complete rewrites are bad (and is what stopped it all last time).

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.

I don't think complete rewrites are bad as long as the can act as drop in replacements

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.

and what is bad if that happens?

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.

If we have someone who says: "He I will help you" then you say, no don't do it because complete rewrites are bad

I don't buy that argument

No one said that, that's why someone volunteered last time, and I still don't see a complete rewrite or any other progress

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

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"

but anyway, what I propose is that we create an xsf-tools repo and copy the tooling from the xeps repo over

and then start working improving the tooling towards what we want in the new xsf-tools

yes, I think that might be a sane starting point

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.

ahh, that's what it was

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

I think it's trivial to add the git revisions of the involved repos into the produced artifacts

That's not the same thing.

and I note that we alrady don't know which version was used to build the artifacts

That's a good point; it wouldn't be a regression, it would be exactly the same as what we have today

I think I don't have any objections making xsf-tools a submodule of xeps

SamWhited: No, I don't think that's true.

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.

(because they're tied)

that way the xsf-tools repo could try to autodetect the official xeps repo as being one level up the directory tree

oh, I see, right

sorry, I know we've had this exact discussion before, it's just been too long

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 ?

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 :)

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

I'm no so against it that I would object, I just doubt it will ever actually get updated.

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

uh, another nit, can we go for python3?

Flow: Incremental improvement please

(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.)

what does that mean exaclty?

ah com

Flow: Just do one thing to start, then we can think about python3

apt install python3

SamWhited: let's ask iteam if python3 on perseus would be possible

if yes, we go for python3

Let's move the files to a new repo first.

And then try experimenting with python3.