-
Kev
I hope that reply was not too unhelpful.
-
jonas’
I would have to get up to read it
-
jonas’
but you’ve made me curious
-
Kev
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.
-
Kev
It's not worth getting up for :)
-
Kev
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.
-
jonas’
Uh, why didn’t you say that?
-
jonas’
this was completely off my radar
-
Kev
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@.
-
jonas’
right, but I think it’s a very valid concern
-
jonas’
more than just the generic "this isn’t the main platform for individual users" barrier-to-contribution
-
Kev
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.
-
Kev
But did want at least people here to be aware and weigh it in decisions.
-
Kev
And my other point stands - a process/tooling that the Editors can't/won't use is a bigger issue than preventing contribution.
-
jonas’
thanks
-
jonas’
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
-
jonas’
(or at least not as neatly integrated, though I guess we can do a lot if someone starts to poke at the github api)
-
jonas’
ugh
-
jonas’
we cannot use gitlab ci/cd externally on github: https://gitlab.com/gitlab-org/gitlab/-/issues/5667
-
jonas’
or maybe we can, hm, but it’d be even more degraded
-
jonas’
we wouldn’t get CI checks on PRs
-
jonas’
ugh, so
-
jonas’
anyone with more ideas how to solve this?
-
jonas’
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.
-
jonas’
pep., opinion?
-
jonas’
(option 4: find someone else to fix all the things on something which isn’t gitlab CI)
-
jonas’
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
-
jonas’
it really is GitHub’s f*d up permission model
-
jonas’
might use a separate "machine account" (from GitHub ToS) for that, I’d sacrifice my free machine account (as per ToS) for that even
-
jonas’
would still gain +rw on all things under xsf
-
jonas’
hm, no, I can’t do that for $reasons
-
jonas’
someone else would have to
-
pep.
2. seems annoying for editors :/
-
jonas’
indeed
-
jonas’
it also won’t fix the permission issue
-
pep.
Having to move stufffrom one to the other
-
pep.
1. Seems like an ugly compromise
-
jonas’
the only thing fixing the permission issue is, unfortunately, (3)
-
jonas’
though, no, (2) can be done without full repository access
-
jonas’
just webhooks AFAICT
-
pep.
Can we archive if we keep xep-attic on github?
-
jonas’
what would that buy us?
-
pep.
hmm?
-
pep.
Archiving?
-
jonas’
what would we gain from keeping xep-attic on github?
-
Guus
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?
-
pep.
jonas’, ah, well "people don't want to move", so I'd assume they also don't want that to move
-
jonas’
Guus, I don’t have much experience with actions
-
Guus
Isn't that supposed to be augmentable with easy snippets?
-
jonas’
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
-
jonas’
(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)
-
Guus
I'll take your word for it. Just mentioned it in case you hadn't considered it yet.
-
jonas’
Guus, I’m not 100% certain that Actions wouldn’t solve everything
-
jonas’
well, I mean, at least the most pressing issues
-
jonas’
it won’t give us the nice extra features we could have with gitlab
-
jonas’
pep., so yeah, (2) would work without the permission nightmare
-
jonas’
but it’s quite annoying for us indeed
-
jonas’
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
-
jonas’
(while with the current process you’ll have to do the email sending and stuff manually)
-
Guus
If using docker is a limiting factor, can we consider moving away from that?
-
jonas’
Guus, we could also build tarballs and push them as build artifacts, but they have exactly the same limitations on GitHub.
-
Guus
I'm just spitballing
-
jonas’
Guus, yes, thank you for that
-
jonas’
I really appreciate it
-
jonas’
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
-
Guus
I don't understand enough of the problem space to evaluate
-
jonas’
pep., I think that xep-attic is virtually irrelevant for normal people.
-
jonas’
pep., how terrible do you think (2) would be for us editors?
-
pep.
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
-
pep.
Github see when something has been merged if it's on master? We wouldn't have to close PRs there?✎ -
pep.
Github sees when something has been merged if it's on master? We wouldn't have to close PRs there? ✏
-
jonas’
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
-
jonas’
for the latter: correct, if the commit ID at the tip of the PR appears on master, the PR is auto-closed✎ -
jonas’
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 ✏
-
pep.
Ah ok so we're giving up on gitlab-ci for MRs at all, no rendered version etc.
-
pep.
no possible htmldiff
-
jonas’
for GitHub PRs, that’s true
-
jonas’
for GitLab MRs, we’d still have that
-
jonas’
but those are only given to those who come to GitLab for their MRs
-
jonas’
GitHub PRs would not receive such service
-
pep.
k
-
pep.
I'm not entirely happy with having to entrypoints tbh
-
pep.
But..
-
jonas’
I always read "k" as a very short (both in lettercount and tone), but I get the impression that’s not (always) your intention?
-
pep.
I use "k" as "ok"
-
jonas’
I am not happy at all with that. I’m going to sleep over it and send a proposal to the list tomorrow.
-
jonas’
right, other people I write with use "k" for "ok" but only if they want to be short in tone, too
-
jonas’
so I’ll remap that in my head for you, thanks
-
pep.
languages :P
-
jonas’
yeah, let’s stop using them
-
pep.
I'll start the research for a matrix-like device where I can transmit raw thoughts
-
jonas’
sounds like a plan
-
pep.
hmm, having both gitlab and github means we have to maintain both travis-ci and gitlab-ci
-
pep.
To do.. more or less the same thing
-
pep.
What about CLA-signing btw, have you found anything?
-
jonas’
right, I’d have a plan how to do that, but I’d need to run it by board
-
jonas’
effectively, CI-check for DCO + put wording in the repo that DCO == accept IPR
-
jonas’
on CI-fail use gitlab API to put a comment with explanation on it
-
jonas’
that’s the key downside for gitlab IMO
-
jonas’
because that’s much more complex than clicking that button
-
pep.
"put wording in the repo that DCO == accept IPR" that sounds like a CLA
-
jonas’
maybe
-
pep.
That's not the goal of the DCO
-
jonas’
it is not?
-
pep.
nope
-
pep.
The DCO just certifies the origin of the change
-
pep.
And guarantees that the author has a license to use/share/modify/etc.
-
jonas’
ah, indeed
-
jonas’
misread that when I skimmed over it
-
jonas’
meh
-
pep.
It's of course good to have, but I guess a CLA would include this
-
jonas’
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
-
pep.
A don't know if there are CLA templates relying on DCO✎ -
pep.
I don't know if there are CLA templates relying on DCO ✏
-
jonas’
we should maybe run that by a lawyer.
-
jonas’
I’ll drop something on the trello board✎ -
jonas’
I’ll drop something on the board trello board ✏
-
pep.
What does the current github thing look like again
-
pep.
Figuring this out would be a prerequisite to using gitlab as an entrypoint, certainly. I'm afraid board is just gonna drop it :(
-
pep.
Judging by the past track record
-
jonas’
created a card
-
pep.
k
-
jonas’
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)
-
jonas’
would give us the power of GitLab CI without the permission issues
-
jonas’
but again only for the main branch, not for PRs
-
jonas’
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.✎ -
jonas’
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. ✏
-
jonas’
most notably > may be redistributed consistent with this project or the open source license(s) involved
-
pep.
CLA is not a(n open-source) license though. Well, it's a license to relicense
-
pep.
The XSF still needs something that explicitely asks the contributor to say "I authorize the XSF to relicense my work under the IPR"
-
jonas’
do we?
-
jonas’
don’t we just need "I authorize that my contribuiton may be redistributed consistent with the IPR"?
-
pep.
Does https://developercertificate.org define "open source license"?
-
jonas’
that it specifically says "open source license" is a nitpick which doesn’t quite matter
-
jonas’
there are projects which use Signed-off-by with different semantics, e.g. gentoo (as I just learnt)
-
pep.
I see. I guess as long as it's defined in their repo..
-
pep.
That's not DCO from https://developercertificate.org/ then, it's just something that reuses the same forme✎ -
jonas’
https://github.com/gentoo/gentoo/pull/16258#issuecomment-644148441 https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin
-
pep.
That's not DCO from https://developercertificate.org/ then, it's just something that reuses the same form ✏
-
jonas’
exactly
-
pep.
Hijacking semantics :P
-
pep.
But I guess that's fine
-
pep.
hmm where do you see that gentoo does?
-
jonas’
does what?
-
jonas’
also, the git-commit manpage itself says > The meaning of a signoff depends on the project
-
pep.
Their DCO doesn't seem to include attribution
-
jonas’
did I talk about attribution?
-
pep.
Ah ok I thought you did
-
jonas’
I just said that they’re not using developercertificate.org
-
pep.
They redefine it but it seems to me it's "just" another implementation of about the same thing
-
jonas’
sure
-
jonas’
ours would be the same, in the end
-
pep.
Maybe using "free software" instead of "open source"
-
jonas’
instead of $opensourcelicense it’s XSF IPR
-
pep.
rereading the IPR
-
pep.
"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."
-
pep.
This doesn't mention "study" :P
-
jonas’
let us please forget that immediately
-
jonas’
though I would argue that study is a way to use an extension
-
pep.
It'd be fun to see if there is actually any case of the IPR being discussed in court
-
jonas’
"no"
-
pep.
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 :/
-
jonas’
what is re-attribution and why does it matter?
-
pep.
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..)
-
jonas’
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+.
-
jonas’
hence, they allow re-licensing
-
jonas’
but I’ll head to bed now
-
pep.
yeah the "or later" thing is special..
-
pep.
But it's proper to GPL and only to have another GPL version apply, not any license
-
pep.
I'm curious actually if we even need anybody to signup anything
-
pep.
The xeps repo is under the IPR license
-
pep.
We would just need a "normal" DCO to not take any legal responsability if the change wasn't something the user can submit
-
pep.
My 2 cents
-
pep.
Now we need a real lawyer
-
pep.
We would need to change the "free software" wording though
-
pep.
As I doubt the IPR is
-
pep.
correction: it's not an OSI approved license. It might still fit into free software