XSF Editor Team - 2020-06-14

jonas’, do you prefer me to merge things now or just approve them and you'll merge later?

Have you tested announcements btw?

which things?

PRs

yes, I tested announcements, but only to my private email

(see the linked MR)

would you work on editor stuff right now?

Sure

I see

so the things on gitlab.com are ready to be used

right now, emails only go to my private mail address, but that can easily be changed

if we dare

(oh, and if we get the new sender address subscribed to the mailing list first :D)

pep., if you want, you can play a round of "how does this new gitlab thing feel" under my supervision now

otherwise I’ll pick a PR which can be merged to play through the pipelines with real stuff myself

Hey, based on https://mail.jabber.org/pipermail/standards/2020-May/037495.html https://mail.jabber.org/pipermail/standards/2020-June/037552.html it looks like SASL Channel-Binding Type Capability should be XEP'd but was forgotten about.

What does the sender address look like btw

oh have already merged gitlab stuff :p

I just realized

Not like it impacts the current build anyway :)

which current build?

Zash, I have it in the spreadsheet, but it hasn’t been tuesday yet ;)

travis/dockerhub?

though today will be special and I’ll do editor stuff despite it not being tuesday

pep., did you do editor things today?

no

ok, so it doesn’t matter indeed

I’ll switch places and then we can coordinate, there are a few things in the queue which need to be processed, and it’d be good if we could do that together now-ish to iron out the issues ✏

Oh, Georgs mail wasn't that long ago. Don't stress on my account. :)

Zash, I need to test things anyways :)

pep., so I’ll play the game with the protoxep and then I’ll show you the (temporary) ropes for a PR

k

https://gitlab.com/xsf/xeps/-/merge_requests/4

I think this is going to be my favourite feature: https://xsf.gitlab.io/-/xeps/-/jobs/594352928/artifacts/rendered-changes/xep-0440.html

nice indeed

new sender address is xep-editor-pipeline@zombofant.net temporarily. If we continue to use this flow, I’ll see that we set up a proper email sender account on atlas so that we can send from editor@xmpp.org

yeah

This is also supposed to generate an archive directly?

Ah no, mr..

not a full archive

just the one with the changed stuff, which is also exposed in the web UI

okay, provisional email stuff is sorted out

I’m hitting the green button now

man I’m excited

I read pack@main as pac man :x

:D

I’m so looking forward to completely removing the docker stuff in favour of build artifacts one day

in contrast to github, you can get a publicly readable link to the latest artifact of a job on a branch trivially :)

one thing we still need to do manually is tagging

but I’ve got a tool for that in the pipeline, too

it does work mostly already, but it still has some issues with some corner cases

ah well, one mail was generated incorrectly

I guess some problems were to be expected if you don’t clear the runner caches after messing with stuff *a lot*

but everything else seems to have worked flawlessly

let me put the docker image up

ah, the docker builder was stuck. meh.

So we'll need to give commit rights to xep-attic to the CI also?

it already has that

xep-attic was updated correctly

via a Deploy Key (which grants +w to exactly one repository); private key is in a protected CI variable

k

yet another thing you cannot easily do with github

yeah

https://gitlab.com/xsf/xep-attic/-/commit/4741034c2874583a7678caecc51418d29c87229e?view=parallel it has a bit of noise in it because of the caches I should’ve cleared, but nothing fatal

attic is updated on eos2 now, too

this is looking good

yeah looks good :)

pep., wanna handle https://github.com/xsf/xeps/pull/949?

That is..?

workflow would be to create a MR for that branch on github (by pulling it locally and pushing it to a feature branch on the gitlab repo), checking it looks OK and then hitting the green button

huh

I'm kinda lost with what to do wrt validation in that PR

sorry, I got confused

I still am to an extent

need to read up on council logs, I have it as "to merge" in my list

I guess it's blocked on adding the possibility to include validation to registrar stuff

Wasn't the vote on the version prior to the validation changes?

https://github.com/xsf/xeps/pull/960 this would be a good next candidate

Zash, it was yes

workflow would be to create a MR for that branch on github (by pulling it locally and pushing it to a feature branch on the gitlab repo), adding a commit which adds a revision block, checking it looks OK and then hitting the green button

doing now

:+1:

Maybe I'll get my own fork on gitlab for the next try :p

Why is there no pipeline?

Ah because eh

not rebased

right

when you rebase, you’ll also have to rebase the branch on the github side to make github see that it’s going to be merged

https://gitlab.com/xsf/xeps/-/merge_requests/5

(needs to happen before the push to master on the github side happens; only cosmetics though)

Can I push stuff to flow's branch?

yes

I need to add a remote etc. right?

yes

flow is particularly nasty, because his xeps fork isn’t called xeps

you’ll need git@github.com:flowdalic/xeps-xsf

yeah that's fine :p

I actually had him as a remote already

pep., needs revision block

ah fail

also I do wonder why it also rendered '440

Is that why there's also 0440 in the rendered changes?

right

ah, I understand why, hah

nothing to worry about

it bases the files to include there on diff-tree against main, but in this case, your branch doesn’t contain xep-0440 yet, so it notices that it "changed"

(and it gets the built version from the build cache)

k

something to fix to reduce confusion, but nothing to worry about.

can you wait a sec?

I’d like to patch the tooling live-ish ✏

k

hmm I just pushed the revision block. I'll rebase when you're done

I pushed fixes

(to your branch :-x)

lets see what that does

k

huh

ahhh... meh

corner cases everywhere :D

fixed

pep., ^

"50" being a magic number that's just likely to work most of the time? :p

it’s also the depth used by the gitlab runners by default

k

ok, CI passed for the MR!

yupp

it also extracted the correct file :)

yeah

so you can hit the button from my side

from your side?

uh.. germanism probably

"I am ok with you hitting the green button now"

done

If this works out I hope we switch quickly so we don't "have to" maintain both in parallel

sure

if board approves, I intend to do a hard switch in the next two weeks

What about current PRs? rebase/push to gitlab? Grabbing authorship for all of them?

Also I'm sure some are gonna grump saying "I don't like gitlab blah blah"

I intend to do a clean re-import of the repo once we agree on switching

pep., oh, I have an easy reply for them

"Are you going to maintain the build process on github in the same quality? Then do that and we stay there."

Or .. "github is more popular, we're jeopardizing the XSF's popularity!!"

"you can send MRs via email without account"

"email is an ancient tech!!" :P

(maybe, I haven’t checket the "without account" part)

I don't think you can

this is perfect, everything went exactly as expected

It's certainly possible to use your github account to connect to gitlab though

ah yes, you need an account

and yes, you can sign in with github

(images on eos2 pulled)

I’m going to do the tagging for you and synced to github

hmm, we'll have to push your CI change to flow's branch on github

do we?

nope, all good

k

the only requirement is that the commit ID of the head of the branch shows up on master

doesn’t matter if it’s via a merge commit or followed by other commits

all set

I like this flow

I’m going to compose an email to editor@ and standards@ now

k

mail sent

enough pondering

it is also amazing that the gitlab ci runners are nearly twice as fast as docker hub, even for the non-incremental builds

(and if we still felt them to be too slow because of a shared resource, we could host our own e.g. on eos)

Is it possible in github to prevent a repo from accepting PRs?

It's only possible to disable issues right?

We can add templates for github etc. I guess saying "New location: .."

pep., you can archive a repository

which is what I intend to do

I wonder if we won't be asked to compromise and mirror instead :/

not to inconviene lazy people using github, or sth :p

would be an option

sam also suggests to use GitLab CI on a GitHub repo

should be possible, never tried it

wonder how terrible the integration is going t obe

should test that with a non-xsf repo some time next week

It is possible at all? does github integrate that?

We can also mirror a github repo, but then we lose the CI for MRs ✏

pep., gitlab offers "CI/CD for External Repo" when you create a new project

need to test that

Ah, ok

something something webhook I guess

well just like other CI solutions..

yes

but we might still gain the docker registry + artifacts + caching ✏

but we might still gain the docker registry + artifacts + caching + hidden CI variables + … ✏