XSF Editor Team - 2020-06-15

  1. larma has left
  2. Tobi has joined
  3. lnj has joined
  4. bear has left
  5. Kev has joined
  6. bear has joined
  7. lnj has left
  8. flow has joined
  9. lnj has joined
  10. Kev I hope that reply was not too unhelpful.
  11. jonas’ I would have to get up to read it
  12. jonas’ but you’ve made me curious
  13. winfried has left
  14. winfried has joined
  15. 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.
  16. Kev It's not worth getting up for :)
  17. winfried has left
  18. winfried has joined
  19. 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.
  20. jonas’ Uh, why didn’t you say that?
  21. jonas’ this was completely off my radar
  22. 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@.
  23. jonas’ right, but I think it’s a very valid concern
  24. jonas’ more than just the generic "this isn’t the main platform for individual users" barrier-to-contribution
  25. 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.
  26. Kev But did want at least people here to be aware and weigh it in decisions.
  27. Kev And my other point stands - a process/tooling that the Editors can't/won't use is a bigger issue than preventing contribution.
  28. jonas’ thanks
  29. 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
  30. 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)
  31. larma has joined
  32. Zash has joined
  33. Zash has left
  34. larma has left
  35. larma has joined
  36. jonas’ ugh
  37. jonas’ we cannot use gitlab ci/cd externally on github: https://gitlab.com/gitlab-org/gitlab/-/issues/5667
  38. jonas’ or maybe we can, hm, but it’d be even more degraded
  39. jonas’ we wouldn’t get CI checks on PRs
  40. winfried has left
  41. winfried has joined
  42. winfried has left
  43. winfried has joined
  44. jonas’ ugh, so
  45. jonas’ anyone with more ideas how to solve this?
  46. 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.
  47. jonas’ pep., opinion?
  48. jonas’ (option 4: find someone else to fix all the things on something which isn’t gitlab CI)
  49. 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
  50. jonas’ it really is GitHub’s f*d up permission model
  51. 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
  52. jonas’ would still gain +rw on all things under xsf
  53. jonas’ hm, no, I can’t do that for $reasons
  54. jonas’ someone else would have to
  55. pep. 2. seems annoying for editors :/
  56. jonas’ indeed
  57. jonas’ it also won’t fix the permission issue
  58. pep. Having to move stufffrom one to the other
  59. pep. 1. Seems like an ugly compromise
  60. jonas’ the only thing fixing the permission issue is, unfortunately, (3)
  61. jonas’ though, no, (2) can be done without full repository access
  62. jonas’ just webhooks AFAICT
  63. pep. Can we archive if we keep xep-attic on github?
  64. jonas’ what would that buy us?
  65. pep. hmm?
  66. pep. Archiving?
  67. jonas’ what would we gain from keeping xep-attic on github?
  68. 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?
  69. pep. jonas’, ah, well "people don't want to move", so I'd assume they also don't want that to move
  70. jonas’ Guus, I don’t have much experience with actions
  71. Guus Isn't that supposed to be augmentable with easy snippets?
  72. 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
  73. 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)
  74. Guus I'll take your word for it. Just mentioned it in case you hadn't considered it yet.
  75. jonas’ Guus, I’m not 100% certain that Actions wouldn’t solve everything
  76. jonas’ well, I mean, at least the most pressing issues
  77. jonas’ it won’t give us the nice extra features we could have with gitlab
  78. jonas’ pep., so yeah, (2) would work without the permission nightmare
  79. jonas’ but it’s quite annoying for us indeed
  80. 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
  81. jonas’ (while with the current process you’ll have to do the email sending and stuff manually)
  82. Guus If using docker is a limiting factor, can we consider moving away from that?
  83. jonas’ Guus, we could also build tarballs and push them as build artifacts, but they have exactly the same limitations on GitHub.
  84. Guus I'm just spitballing
  85. jonas’ Guus, yes, thank you for that
  86. jonas’ I really appreciate it
  87. 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
  88. Guus I don't understand enough of the problem space to evaluate
  89. winfried has left
  90. winfried has joined
  91. jonas’ pep., I think that xep-attic is virtually irrelevant for normal people.
  92. jonas’ pep., how terrible do you think (2) would be for us editors?
  93. winfried has left
  94. winfried has joined
  95. 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
  96. pep. Github see when something has been merged if it's on master? We wouldn't have to close PRs there?
  97. pep. Github sees when something has been merged if it's on master? We wouldn't have to close PRs there?
  98. 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
  99. jonas’ for the latter: correct, if the commit ID at the tip of the PR appears on master, the PR is auto-closed
  100. 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
  101. pep. Ah ok so we're giving up on gitlab-ci for MRs at all, no rendered version etc.
  102. pep. no possible htmldiff
  103. jonas’ for GitHub PRs, that’s true
  104. jonas’ for GitLab MRs, we’d still have that
  105. jonas’ but those are only given to those who come to GitLab for their MRs
  106. jonas’ GitHub PRs would not receive such service
  107. pep. k
  108. pep. I'm not entirely happy with having to entrypoints tbh
  109. pep. But..
  110. 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?
  111. pep. I use "k" as "ok"
  112. jonas’ I am not happy at all with that. I’m going to sleep over it and send a proposal to the list tomorrow.
  113. jonas’ right, other people I write with use "k" for "ok" but only if they want to be short in tone, too
  114. jonas’ so I’ll remap that in my head for you, thanks
  115. pep. languages :P
  116. jonas’ yeah, let’s stop using them
  117. pep. I'll start the research for a matrix-like device where I can transmit raw thoughts
  118. jonas’ sounds like a plan
  119. pep. hmm, having both gitlab and github means we have to maintain both travis-ci and gitlab-ci
  120. pep. To do.. more or less the same thing
  121. pep. What about CLA-signing btw, have you found anything?
  122. jonas’ right, I’d have a plan how to do that, but I’d need to run it by board
  123. jonas’ effectively, CI-check for DCO + put wording in the repo that DCO == accept IPR
  124. jonas’ on CI-fail use gitlab API to put a comment with explanation on it
  125. jonas’ that’s the key downside for gitlab IMO
  126. jonas’ because that’s much more complex than clicking that button
  127. pep. "put wording in the repo that DCO == accept IPR" that sounds like a CLA
  128. jonas’ maybe
  129. pep. That's not the goal of the DCO
  130. jonas’ it is not?
  131. pep. nope
  132. pep. The DCO just certifies the origin of the change
  133. pep. And guarantees that the author has a license to use/share/modify/etc.
  134. jonas’ ah, indeed
  135. jonas’ misread that when I skimmed over it
  136. jonas’ meh
  137. pep. It's of course good to have, but I guess a CLA would include this
  138. 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
  139. pep. A don't know if there are CLA templates relying on DCO
  140. pep. I don't know if there are CLA templates relying on DCO
  141. jonas’ we should maybe run that by a lawyer.
  142. jonas’ I’ll drop something on the trello board
  143. jonas’ I’ll drop something on the board trello board
  144. pep. What does the current github thing look like again
  145. pep. Figuring this out would be a prerequisite to using gitlab as an entrypoint, certainly. I'm afraid board is just gonna drop it :(
  146. pep. Judging by the past track record
  147. jonas’ created a card
  148. pep. k
  149. 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)
  150. jonas’ would give us the power of GitLab CI without the permission issues
  151. jonas’ but again only for the main branch, not for PRs
  152. 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.
  153. 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.
  154. jonas’ most notably > may be redistributed consistent with this project or the open source license(s) involved
  155. pep. CLA is not a(n open-source) license though. Well, it's a license to relicense
  156. pep. The XSF still needs something that explicitely asks the contributor to say "I authorize the XSF to relicense my work under the IPR"
  157. jonas’ do we?
  158. jonas’ don’t we just need "I authorize that my contribuiton may be redistributed consistent with the IPR"?
  159. pep. Does https://developercertificate.org define "open source license"?
  160. jonas’ that it specifically says "open source license" is a nitpick which doesn’t quite matter
  161. jonas’ there are projects which use Signed-off-by with different semantics, e.g. gentoo (as I just learnt)
  162. pep. I see. I guess as long as it's defined in their repo..
  163. pep. That's not DCO from https://developercertificate.org/ then, it's just something that reuses the same forme
  164. jonas’ https://github.com/gentoo/gentoo/pull/16258#issuecomment-644148441 https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin
  165. pep. That's not DCO from https://developercertificate.org/ then, it's just something that reuses the same form
  166. jonas’ exactly
  167. pep. Hijacking semantics :P
  168. pep. But I guess that's fine
  169. pep. hmm where do you see that gentoo does?
  170. jonas’ does what?
  171. jonas’ also, the git-commit manpage itself says > The meaning of a signoff depends on the project
  172. pep. Their DCO doesn't seem to include attribution
  173. jonas’ did I talk about attribution?
  174. pep. Ah ok I thought you did
  175. jonas’ I just said that they’re not using developercertificate.org
  176. pep. They redefine it but it seems to me it's "just" another implementation of about the same thing
  177. jonas’ sure
  178. jonas’ ours would be the same, in the end
  179. pep. Maybe using "free software" instead of "open source"
  180. jonas’ instead of $opensourcelicense it’s XSF IPR
  181. pep. rereading the IPR
  182. 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."
  183. pep. This doesn't mention "study" :P
  184. jonas’ let us please forget that immediately
  185. jonas’ though I would argue that study is a way to use an extension
  186. pep. It'd be fun to see if there is actually any case of the IPR being discussed in court
  187. jonas’ "no"
  188. 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 :/
  189. jonas’ what is re-attribution and why does it matter?
  190. 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..)
  191. 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+.
  192. jonas’ hence, they allow re-licensing
  193. jonas’ but I’ll head to bed now
  194. pep. yeah the "or later" thing is special..
  195. pep. But it's proper to GPL and only to have another GPL version apply, not any license
  196. pep. I'm curious actually if we even need anybody to signup anything
  197. pep. The xeps repo is under the IPR license
  198. pep. We would just need a "normal" DCO to not take any legal responsability if the change wasn't something the user can submit
  199. pep. My 2 cents
  200. pep. Now we need a real lawyer
  201. pep. We would need to change the "free software" wording though
  202. pep. As I doubt the IPR is
  203. pep. correction: it's not an OSI approved license. It might still fit into free software
  204. larma has left