KevSummary: I think we should stay with github if we can. But if we can't, we need the Editors to be able to function.
KevIt's not worth getting up for :)
winfriedhas left
winfriedhas joined
KevWhat 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
KevI 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
KevWhen 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.
KevBut did want at least people here to be aware and weigh it in decisions.
KevAnd 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)
larmahas joined
Zashhas joined
Zashhas left
larmahas left
larmahas joined
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
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
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?
GuusI 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
GuusIsn'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)
GuusI'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)
GuusIf 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.
GuusI'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
GuusI don't understand enough of the problem space to evaluate
winfriedhas left
winfriedhas joined
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?
winfriedhas left
winfriedhas joined
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.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