XSF Editor Team - 2020-06-15

I hope that reply was not too unhelpful.

I would have to get up to read it

but you’ve made me curious

Summary: I think we should stay with github if we can. But if we can't, we need the Editors to be able to function.

It's not worth getting up for :)

What I didn't say is that there is a real barrier to switching platforms for contributors, because if they're doing XSF work on work time (as I am, and I think several people are), they'd need to check that Legal are happy with the gitlab terms, having already gone through that dance once to check the github terms are ok.

Uh, why didn’t you say that?

this was completely off my radar

I thought it was enough to note that switching was a barrier to contribution. I don't want to start an amateur lawyering thread on standards@.

right, but I think it’s a very valid concern

more than just the generic "this isn’t the main platform for individual users" barrier-to-contribution

When we switched to github similar concerns were raised, including from Kurt (@isode) claiming Isode would never allow use of github, when I was already using it. I didn't want the pain.

But did want at least people here to be aware and weigh it in decisions.

And my other point stands - a process/tooling that the Editors can't/won't use is a bigger issue than preventing contribution.

thanks

with Sams suggestion we might have the cake and eat it too, at least for most part. we might not get the value added stuff like seeing rendered previews and diffs in MRs, though

(or at least not as neatly integrated, though I guess we can do a lot if someone starts to poke at the github api)

ugh

we cannot use gitlab ci/cd externally on github: https://gitlab.com/gitlab-org/gitlab/-/issues/5667

or maybe we can, hm, but it’d be even more degraded

we wouldn’t get CI checks on PRs

ugh, so

anyone with more ideas how to solve this?

I see those ways: 1. We stay on GitHub primarily and use GitLab CI/CD as well as the container registry for handling everything which happens on the main branch, i.e. building the images, sending out emails etc.. PRs would be handled by travis-ci, because we cannot get PRs working in GitLab CI from GitHub. 2. The primary repository moves to GitLab and we set up a push mirror to GitHub. PRs would be accepted on github, but with lower "SLA", since editors would have to manually transfer stuff. PRs on GitLab would get all the bells and whistles like pre-rendered diffs and stuff. 3. We move completely off GitHub.

pep., opinion?

(option 4: find someone else to fix all the things on something which isn’t gitlab CI)

Oh, and of course, using GitLab CI "remotely" has the same issue as docker hub and all the other tools: you have to grant +rw on all things

it really is GitHub’s f*d up permission model

might use a separate "machine account" (from GitHub ToS) for that, I’d sacrifice my free machine account (as per ToS) for that even

would still gain +rw on all things under xsf

hm, no, I can’t do that for $reasons

someone else would have to

2. seems annoying for editors :/

indeed

it also won’t fix the permission issue

Having to move stufffrom one to the other

1. Seems like an ugly compromise

the only thing fixing the permission issue is, unfortunately, (3)

though, no, (2) can be done without full repository access

just webhooks AFAICT

Can we archive if we keep xep-attic on github?

what would that buy us?

hmm?

Archiving?

what would we gain from keeping xep-attic on github?

I won't claim to understand more than the basics from what you're trying to do, but I notice that you keep not referring to GitHubs own actions. Doesn't that suffice?

jonas’, ah, well "people don't want to move", so I'd assume they also don't want that to move

Guus, I don’t have much experience with actions

Isn't that supposed to be augmentable with easy snippets?

I’m not sure we can do all of what we need to do there (while I’ve proven already that we can with CI), but one issue would be that there is no docker registry we can readily use from Actions

(GitHub "packages" (docker registry) aren’t world-readable, so we’d have to put some privileged token on our server to be able to update the images there, which is again a permission issue)

I'll take your word for it. Just mentioned it in case you hadn't considered it yet.

Guus, I’m not 100% certain that Actions wouldn’t solve everything

well, I mean, at least the most pressing issues

it won’t give us the nice extra features we could have with gitlab

pep., so yeah, (2) would work without the permission nightmare

but it’s quite annoying for us indeed

though still less annoying potentially than the current process, since you can just merge + push to gitlab and let the mirroring + pipeline take care of the rest

(while with the current process you’ll have to do the email sending and stuff manually)

If using docker is a limiting factor, can we consider moving away from that?

Guus, we could also build tarballs and push them as build artifacts, but they have exactly the same limitations on GitHub.

I'm just spitballing

Guus, yes, thank you for that

I really appreciate it

I’m being specific about what I considered (and rejected) in the hopes that you point out a flaw, it’s not meant to be aggressive in any way

I don't understand enough of the problem space to evaluate

pep., I think that xep-attic is virtually irrelevant for normal people.

pep., how terrible do you think (2) would be for us editors?

we'd have to basically pull everything and wait for CI to process before being able to do anything. So I guess your tuesday night becomes two sessions split over the week :p

Github sees when something has been merged if it's on master? We wouldn't have to close PRs there? ✏

for the former: no, we’d have travis-ci to check PRs on GitHub, so we could just do the merge locally, push to gitlab and let gitlab do its thing

for the latter: correct, if the commit ID at the tip of the PR appears on master, the PR is auto-closed and marked as merged ✏

Ah ok so we're giving up on gitlab-ci for MRs at all, no rendered version etc.

no possible htmldiff

for GitHub PRs, that’s true

for GitLab MRs, we’d still have that

but those are only given to those who come to GitLab for their MRs

GitHub PRs would not receive such service

k

I'm not entirely happy with having to entrypoints tbh

But..

I always read "k" as a very short (both in lettercount and tone), but I get the impression that’s not (always) your intention?

I use "k" as "ok"

I am not happy at all with that. I’m going to sleep over it and send a proposal to the list tomorrow.

right, other people I write with use "k" for "ok" but only if they want to be short in tone, too

so I’ll remap that in my head for you, thanks

languages :P

yeah, let’s stop using them

I'll start the research for a matrix-like device where I can transmit raw thoughts

sounds like a plan

hmm, having both gitlab and github means we have to maintain both travis-ci and gitlab-ci

To do.. more or less the same thing

What about CLA-signing btw, have you found anything?

right, I’d have a plan how to do that, but I’d need to run it by board

effectively, CI-check for DCO + put wording in the repo that DCO == accept IPR

on CI-fail use gitlab API to put a comment with explanation on it

that’s the key downside for gitlab IMO

because that’s much more complex than clicking that button

"put wording in the repo that DCO == accept IPR" that sounds like a CLA

maybe

That's not the goal of the DCO

it is not?

nope

The DCO just certifies the origin of the change

And guarantees that the author has a license to use/share/modify/etc.

ah, indeed

misread that when I skimmed over it

meh

It's of course good to have, but I guess a CLA would include this

it is still not quite clear to me why, legally, we need to tell people that when they submit a document which states that it is under XSF IPR (note that the XEP template includes that), it is in fact under XSF IPR and they agree to that

I don't know if there are CLA templates relying on DCO ✏

we should maybe run that by a lawyer.

I’ll drop something on the board trello board ✏

What does the current github thing look like again

Figuring this out would be a prerequisite to using gitlab as an entrypoint, certainly. I'm afraid board is just gonna drop it :(

Judging by the past track record

created a card

k

as a truly crappy workaround we could set up a GitHub Action which forwards pushes to GitHub main branch to GitLab main branch, kind of like a weird chimera of (1) and (2)

would give us the power of GitLab CI without the permission issues

but again only for the main branch, not for PRs

pep., though, DCO as on https://developercertificate.org/ states: > (d) I understand and agree that this project and the contribution > are public and that a record of the contribution (including all > personal information I submit with it, including my sign-off) is > maintained indefinitely and may be redistributed consistent with > this project or the open source license(s) involved. ✏

most notably > may be redistributed consistent with this project or the open source license(s) involved

CLA is not a(n open-source) license though. Well, it's a license to relicense

The XSF still needs something that explicitely asks the contributor to say "I authorize the XSF to relicense my work under the IPR"

do we?

don’t we just need "I authorize that my contribuiton may be redistributed consistent with the IPR"?

Does https://developercertificate.org define "open source license"?

that it specifically says "open source license" is a nitpick which doesn’t quite matter

there are projects which use Signed-off-by with different semantics, e.g. gentoo (as I just learnt)

I see. I guess as long as it's defined in their repo..

https://github.com/gentoo/gentoo/pull/16258#issuecomment-644148441 https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin

That's not DCO from https://developercertificate.org/ then, it's just something that reuses the same form ✏

exactly

Hijacking semantics :P

But I guess that's fine

hmm where do you see that gentoo does?

does what?

also, the git-commit manpage itself says > The meaning of a signoff depends on the project

Their DCO doesn't seem to include attribution

did I talk about attribution?

Ah ok I thought you did

I just said that they’re not using developercertificate.org

They redefine it but it seems to me it's "just" another implementation of about the same thing

sure

ours would be the same, in the end

Maybe using "free software" instead of "open source"

instead of $opensourcelicense it’s XSF IPR

rereading the IPR

"Once an author assigns ownership to the XSF, the XSF shall in turn make the Extension available to all entities so that they may create, use, sell, distribute, or dispose of Implementations or Deployments of XMPP and all XMPP Extensions in perpetuity and without payment or hindrance."

This doesn't mention "study" :P

let us please forget that immediately

though I would argue that study is a way to use an extension

It'd be fun to see if there is actually any case of the IPR being discussed in court

"no"

I can't say for the DCO, if we would "just" need to replace that last line with "XSF IPR". It seems to me the IPR is closer to a CLA than a license (it has the notion of "re-attribution"). But IANAL, I don't know if what I'm saying makes sense at all :/

what is re-attribution and why does it matter?

Well a CLA is only really useful in a copyleft context, where you need the author's approval to relicense (what I call reattribution, which is probably a bit maladroit. There's actually CAAs and CLAs..)

GPLv3+ effectively allows that ("or any later version"); GPLv3+ is a free software/open source license; the DCO and the Gentoo-CO both allow the GPLv3+.

hence, they allow re-licensing

but I’ll head to bed now

yeah the "or later" thing is special..

But it's proper to GPL and only to have another GPL version apply, not any license

I'm curious actually if we even need anybody to signup anything

The xeps repo is under the IPR license

We would just need a "normal" DCO to not take any legal responsability if the change wasn't something the user can submit

My 2 cents

Now we need a real lawyer

We would need to change the "free software" wording though

As I doubt the IPR is

correction: it's not an OSI approved license. It might still fit into free software