XSF Editor Team - 2018-02-08

jcbrand: still up for our meeting?

hi jonasw

ready when you are

jcbrand: k I need five more mins

here I am!

jonasw: I'm running `make docker`

Currently generating pdfs

I don’t even know what that does :D

ah, I always run my own docker invocation (docker build . --build-arg NCORES=9 --build-arg TARGETS="html inbox-html") to avoid building PDFs

ok

locally building the PDFs takes long and doesn’t bring any value; if there’s a syntax error or something, you’ll notice with the HTML build

I see the pdfs take long

yeah

and for a quick local test, a waste of time

the PDFs are in a bad shape in any case

(somebody should probably start to make a huge cleanup, but I don’t see that happening any time soon :))

I want to add a Makefile recipe then to only build docker with HTML

that sounds reasoanble

an additional one

so I think we have two PRs which we could process, those by @sco0ter on github (#580 and #582)

jonasw: BTW, while I'm thinking of it... I have a question for you

feel free

when doing triaging... some tickets get the tag "ready to merge"

why do that instead of just merging? I guess to answer my own question, because after merging you need to generate the HTML and PDFs and send out emails?

yeah

I like to batch things up

ok

I can do triaging during a five minute break

jonasw: looks like I might need docker credentials?

`docker: Error response from daemon: pull access denied for xmpp-org/extensions, repository does not exist or may require 'docker login'`

what

I don’t think that you do

I’m pretty sure that’s public

I got that when I ran 'make testdocker'

ah

that’s because my home-brew docker-command doesn’t have the -t xmpp-org/extensions argument

if you replace "xmpp-org/extensions" in the testdocker invocation with the image ID from the build ("Successfully built somehexstring"), it should work

ah, then I'll just add "-t xmpp-org/extensions" rather

yah

probably makes sense

I'm adding it to the Makefile

cool :)

Ok, looking at #580

did you read the README I wrote?

Yes

sweet

but that was quite a while ago

I do sometimes refer back to it when looking at the PRs

so, this will be very convenient to keep in mind specifically: https://github.com/xsf/xeps#general-notes-on-making-changes

because this xeplist.xml is the most important thing for all the automation I wrote

it is crucial that the "old-xeplist.xml" refers to the last pushed state

so before doing anything, do make build/xeplist.xml && cp build/xeplist.xml tools/old-xeplist.xml

ok, just before I do that...

I have now docker running

But it just gives me Nginx's default message

yeah, you need to go to /extensions/ manually

ok

you’ll get a directory listing there

hmm

ah

ok cool, so that's working

I'll build the xeplist

ok done

cool

so now you can either make a new branch (which I’d recommend) or work on top of master

making a new branch makes it easy to throw away stuff when you messed something up

ok, I'll make a new branch

Do you merge into the new branch or into master and then make the branch?

and now the cool magic: you can use git pull origin pull/580/head to pull the changes from #580

ok ya

new branch and then merge

ok and for #582 as well?

I’d handle them separately at first

so for 580, I’m not sure if we want a version block or not

for now, let’s do one, because it’s a good exercise to do

version block?

yeah, revision block

something like this I’d suggest for #580 (so in xep-0174): <revision> <version>2.0.1</version> <date>2018-02-08</date> <initials>cs (XEP Editor: jc)</initials> <remark><p>Fix incorrect STARTTLS examples.</p></remark> </revision>

(right below &stpeter;)

you may adapt the wording and your initials at will of course

I’m not sure if we even should have the "(XEP Editor: xyz)" thing, because git has that information too, in most cases, and it isn’t really useful.

feel free to omit

I was just wondering about that

will remove

once you’ve added that block, make a commit; run make build/xeplist.xml to see if it’s happy with it ✏

No output, so I assume it's happy?

that’s a good assumption

xeplist.xml looks ok

great!

do you test the HTML then via docker?

yes

you can also build the HTML files with make

in fact, you’ll have to do that to put the files into the attic

(or rather: tools/archive.py will do that for you)

we could try that right away actually

did you clone xep-attic next to the xeps repository (i.e.: assuming you have an directory "editor", xep-attic would be at "editor/xep-attic" and xeps would be at "editor/xeps")?

yes

I have that

so `make html`?

you can just run: ./tools/archive.py tools/old-xeplist.xml build/xeplist.xml

it will do a few things: 1. list which XEPs have changed between the two xeplist files you passed there; 2. invoke make build/xep-xyz.html for those; 3. copy the resulting HTML files into the ../xep-attic/content/ directory

yeah, so there's a new HTML file in the attic now

\o/

content/xep-0174-2.0.1.html

fine :) ✏

you thought something was wrong?

I thought I pasted that :D

great, so you can now merge your branch into master, but don’t push yet.

(if you’ve commited the revision block to git yet)

and you can repeat the same process for #582

ok, will do

I didn't know this trick of pulling in pull requests

yeah, I learnt that a few weeks ago in some XMPP-related MUC

before I always puzzled together the URLs manually (https://github.com/$prauthor/xeps $branchname), which didn’t always work

I always had to guess whether Flows fork of the repository was called xeps-xsf or xsf-xeps and I always got it wrong on the first attempt ;-)

Should I again make a revision block?

yeah, for this one definitely

it touches on registar issues

ok

still only a patch revision though, because it doesn’t change normative language or intent in any way

I guess when in doubt, rather make it

(it’s technically an oversight in editor work, we should’ve made sure that everything was coherent)

yeah

even though, there’s an argument against that (because revision blocks essentially determine when a XEP will be deferred; so when doing editorial things on Experimental XEPs, one might to skip that; or maybe we need to re-define when deferral kicks in, I dunno)

ok

so... 1.15.1 then?

yupp

oh, I should have copied over the old xeplist again

no it’s fine

all operations except sending email are idempotent

in fact, do not copy it over until you have sent the emails

(because the email sending also uses the xeplists)

(unless you want to do it manually, which I would definitely not recommend ;-)

So you run `make build/xeplist.xml && cp build/xeplist.xml tools/old-xeplist.xml` once before merging PRs?

yeah

after a git pull that is

(in case somebody else did some work inbetween)

ok

I notice in the readme you have a different order, you mention sending out emails before copying over to the xeplist

okay, maybe I wasn’t clear, let me try again. the coarse workflow is: - sit down to do editor work - do the git pull && make build/xeplist.xml && cp build/xeplist.xml tools/old-xeplist.xml - start making branches and merging PRs; merge branches back to master - git push - run tools/archive.py […] - run tools/send-updates.py […] ✏

+ all the testing in-between to make sure that things are okay

you only run make build/xeplist.xml; the cp is never run again until after the send-updates.py

(if you now accidentally copied over the old-xeplist.xml with some intermediate state, that’s fine, it’s recoverable)

(also I doubt it’s an issue if we don’t send mails for both)

hmm, when I run `./tools/archive.py tools/old-xeplist.xml build/xeplist.xml` it only picks up the change in XEP-0174, not the change in XEP-0060

Should I run `make build/xeplist.xml` first?

yes

running make build/xeplist.xml is always safe

ok, so diffing with `origin master` looks good

I'll push, since you've already mentioned it in the workflow

ah, wait

ok

one second please

I want to test intosis PR first

and merge that too if needed

or if possible

so yeah: merge intosis PR and run docker build . --build-arg NCORES=9 --build-arg TARGETS="refs" to see if it works

if it does, that’s fine and you can push I think

ah, and there’s one more thing we can do

let me know when you’ve handled intosis PR

ping

hello

I think things have settled

Shall we continue here/

?

might as well

okay, so once everything is merged and the last docker build went through, you can run the git push

when the push’s over, you can observe the build here: https://hub.docker.com/r/xmppxsf/xeps/builds/

(you won’t see output though; only when it switches to error or failed or success at some point) ✏

while the build is running, you can update the attic with the archive.py tool and commit and push everything in there (git add content/*.html && git commit && git push) ✏

once that’s done, we’ll prepare the sending of emails

The Makefile recipe I added, can I simply commit and push to master, or do you want to see a PR?

jonasw: ^ otherwise done and ready for sending emails

you can paste the diff here (from git diff) and I’ll have a quick look

diff --git a/Makefile b/Makefile index f1ea374..e682928 100644 --- a/Makefile +++ b/Makefile @@ -167,6 +167,10 @@ preview: docker: docker build -t xmpp-org/extensions . +.PHONY: dockerhtml +dockerhtml: + docker build -t xmpp-org/extensions . --build-arg NCORES=9 --build-arg TARGETS="html inbox-html" + .PHONY: testdocker testdocker: docker run -d --name tmpxeps -p 3080:80 xmpp-org/extensions

yeah, that looks safe

looks terrible

you can commit & push that

ok done

so now emails I guess

so regarding sending emails, you’ll have to create a config file; the name is not relevant, I’m using "config.ini": [smtp] host=smtp.zombofant.net user=jonas.wielicki from=Jonas Wielicki (XSF Editor) <jonas@wielicki.name> host is the SMTP server to use, user is the login user name and from is the From header for the mail

I guess you can guess how to adapt that to your setup (I think you’re running your own mail server?)

is zombofant.net your SMTP server?

yes

ok yeah, I run my own

smtp.zombofant.net is the SMTP servre, so if yours is foobar.domain.example, you’d have to write foobar.domain.example, not smtp.foobar.domain.example

to be clear

yes

so once you’ve set that config up, you can invoke: ./tools/send-updates.py -nc config.ini tools/old-xeplist.xml build/xeplist.xml standards@xmpp.org the -n is equivalent to --dry-run and will only print the mails, without ever connecting to your server

you’ll know when it tries to send email because it’ll ask for your password

(at this point, if you’re worried, you can of course read the source code of the script :-))

is this the email address that's registered on the XSF members list?

I have one email on the XSF members list and another for the other lists...

not ideal but ja :)

you shoudl be using a mail address which is subscribed to standards@, because that’s where the mails go

ah standards

ok

so invoke the tool as described above to get a view on how the mails which are to be sent will look. you should have three mails (two UPDATED and one DEFERRED)

yep, I checked

looks good

cool

so now just running it without -n ?

you can then invoke it either without the "n", or even with "y". without "n", it’ll ask for each mail. with "y", it will send all emails without further output & asking

your choice :)

the standards list is kinda slow (and I think we’re currently having bad internet weather judging by the MUC issues we just had), so it’ll take a few minutes until your mails appear on the list, but I guess you’re used to that already

Emails are sent out

cool

you’re done I think :)

even though

I realize we should’ve waited until the build was done

that’s not a huge issue though

ah

build’s going to be finished in 60 minutes probably

ok next tiem

yeah

Thanks very much for your help with this

you’re welcome

and still, remember what I wrote: there’s no pressure here. just because I took the time to introduce you, doesn’t mean anybody expects a high level of activity from now on :)

thanks. I'll do what and when I can :)

I'm glad I bought beer yesterday, now I can celebrate

ha

have a good evening

same to you

build has passed, jcbrand.

looks good so far :)

good

yupp, all touched XEPs look as they should :)

good job :)

thanks :)