XSF Editor Team - 2020-06-17


  1. stpeter has left
  2. stpeter has joined
  3. stpeter has left
  4. stpeter has joined
  5. winfried has left
  6. winfried has joined
  7. stpeter has left
  8. stpeter has joined
  9. stpeter has left
  10. Tobi has joined
  11. stpeter has joined
  12. stpeter has left
  13. bear has left
  14. stpeter has joined
  15. soul has left
  16. soul has joined
  17. lnj has joined
  18. bear has joined
  19. stpeter has left
  20. stpeter has joined
  21. stpeter has left
  22. stpeter has joined
  23. stpeter has left
  24. stpeter has joined
  25. stpeter has left
  26. stpeter has joined
  27. Kev has left
  28. jonas’ pep., posting a comment to the user explaining how they can accept the CLA would be useful though
  29. pep. sure, we can do that already no?
  30. pep. webhook on "notes"
  31. jonas’ webhook is the other way ’round
  32. jonas’ you post a comment via API
  33. jonas’ you get notified about a comment via webhook
  34. jonas’ but how would we make the acceptance flow, assuming that --signoff isn’t enough
  35. jonas’ we need something interactive where the user can ACK it
  36. pep. You get notified about a comment, you see if it comes from somebody who hasn't signed, you post a comment
  37. jonas’ and something would have to be able to receive a webhook if we ake it based on comments
  38. jonas’ which requires a thing running on some serevr
  39. pep. And when you have confirmation that the thing has been signed, either in the issue directly "Yes I agree", or third-party, then \o/
  40. jonas’ if we can make this into a small dockerised service, sure, but someone has to develop and maintain it
  41. jonas’ (if we can do that much, I’d also go to a point where we just require approval by our @xsf-cla-bot user always, which can be done with gitlab)
  42. jonas’ (and let it auto-approve things)
  43. jonas’ I need to make dinner now
  44. jonas’ pep., I’d like to keep #949 open to test github/gitlab sync once I set up a prototype
  45. jonas’ I intend to set up one by the weekend; at latest, I’ll merge #949 next tuesday during my usual session in case I can’t setup the multi-primary sync until then
  46. pep. sure
  47. pep. I can still open PRs here and there for people to implement :p
  48. jonas’ yupp :)
  49. pep. hmm, https://about.gitlab.com/2017/10/22/gitlab-10-1-released/#reject-unsigned-commits
  50. pep. Ah wait
  51. pep. Ah ok the person was talking about DCO and then throw this feature in their post, I thought that was linked
  52. pep. Would be nice though to be able to reject commits based on the result of a script, but then it's getting close to RCEAAS, not sure how much they like that
  53. jonas’ all we can do is have the ci enforce that
  54. pep. And prevent pushes on master? Is it possible to sync with github and do that at the same time?
  55. jonas’ well, we can’t prevent pushes on master for admins, obviously
  56. jonas’ because they can simply remove that restriction
  57. pep. yes we can!
  58. jonas’ but we can prevent fat finger pushes indeed
  59. pep. Sure..
  60. jonas’ and require them to go through the gitlab UI and require the pipeline to be green for a merge
  61. pep. Yeah, like our anti-linkmauve techniques on poezio
  62. jonas’ :)
  63. pep. Requiring DCO is probably gonna makes waves as well.. even if it's just commit -s :/
  64. pep. Thought that's orthogonal to gitlab right. Or am I confused, was that only if IPR could be "solved" without a CLA bot
  65. jonas’ the latter indeed
  66. jonas’ I’d prefer abolishing clabot also for data privacy reasons to be honest
  67. jonas’ (and data protection reasons are a reason making a custom implementation harder, since we’d have to keep a list of PII)
  68. pep. Not giving info to third-parties?
  69. jonas’ (which is meh)
  70. jonas’ yes
  71. pep. The third-party can be a first party (us) though
  72. pep. But then.. does that have the same legal value, dunno
  73. jonas’ we could host that info, but then we’d need a proper privacy policy for that "CLA" service
  74. jonas’ which is again meh
  75. jonas’ because that probably involves lawyers and stuff
  76. jonas’ pep., do you think that’s something for board to ponder about?
  77. pep. To host CLA ACKs ourselves?
  78. pep. Is it not possible to use the same CLA service we use on github atm? Or is the only interface through the bot?
  79. pep. If it's possible then I'd say stick with it for now
  80. pep. That's orthogonal to what we're trying to do
  81. pep. we don't need more bumps on the road than there already is
  82. pep. Ah that seems to be a github service..
  83. jonas’ I don’t think you can hook it up to gitlab, I checked that first
  84. jonas’ interesting datapoint: https://docs.google.com/document/d/1zpjDzL7yhGBZz3_7jCjWLfRQ1Jryg1mlIVmG8y6B1_Q/edit
  85. jonas’ the cla thing is a serious bump which is kind of a blocker unless board tells us it’s ok to let it go.
  86. pep. I didn't really mean to gitlab, I was thinking maybe there would be an API that's not the bot to use it
  87. jonas’ we’re faced with: - stay on github, potentially with odd hybrid solutions towards gitlab for ci - drop clabot (potentially in favour of an xsf-dco) - write a replacement of clabot ourselves
  88. jonas’ ah, I see
  89. pep. In which case we would have to write a bot but we could still use the same third-party
  90. pep. fwiw I don't like CLAs and I'm glad that gitlab changed it to DCO, though their case is flawed because they don't actually need a CLA in the first place, nor a DCO for that matter. Their project is under a permissive license
  91. pep. Well..
  92. pep. They would need a CLA if they planned to relicense even older changes, which doesn't make much sense in their case because they're always just providing the latest revision (ish)
  93. pep. For the XSF it's a bit different as it seem relicensing all the XEPs has in fact been done already
  94. pep. case in point
  95. jonas’ yup
  96. pep. Otherwise there would be XEPs distributed under CC-like (older ones) and some under MIT-like
  97. pep. So the gitlab CLA/DCO document doesn't really apply to me here
  98. pep. We can't just rely on DCO
  99. jonas’ probably not indeed
  100. jonas’ I wonder if we could rely on something similar. I mean all we need is some kind of electronic statement on the record that the contributor has read the terms, understood them and agreed to them
  101. pep. If you start to include electronic signatures that's also gonna make waves :P
  102. pep. If you start to require electronic signatures that's also gonna make waves :P
  103. jonas’ We could request that at least one commit of each Signed-off-by identity has a line: XSF-IPR: I have read, understood and agreed to the XSF IPR policy at xy version z. All my contributions to xeps are under made in accordance to that policy. or similar
  104. jonas’ leave aside the trickiness of checking against that (we could do some caching on that data to avoid the git log grep to be expensive), but that’s about as good as what cla assistant does at the moment
  105. pep. The CLA assistant binds it against a github identity
  106. jonas’ which doesn’t matter
  107. jonas’ I can go and steal your commits and put them up
  108. jonas’ though the github ToS probably say I can’t do that
  109. jonas’ not sure
  110. pep. I'd say the CLA should state that you can't, but worst case we can also require a DCO
  111. jonas’ yes, exactly
  112. jonas’ hence "one commit of each Signed-off-by identity has a line"
  113. jonas’ so that would be used together with DCO
  114. jonas’ so that we have "someone" to point to in case of problems
  115. jonas’ (note that you could and still can agree to the IPR by just sending an email to editor@. I think in the past people didn’t even verify that properly by requiring a reply to be received...)
  116. pep. hmm, what happens when.. somebody wants to retract their ACK
  117. jonas’ that’s Board business
  118. jonas’ then we have to go through the whole retraction process
  119. pep. But from a technical standpoint, we wouldn't have anything in the repo indicating that this person has done so?
  120. jonas’ oh, you mean to remove an ack from the cache?
  121. pep. Or would you rewrite history?
  122. jonas’ right. one option would be to do this in a separate repository where we would be happily rewriting history to remove acks
  123. jonas’ i.e. a repository which only has a list of acked identities, no document data
  124. jonas’ that’s overhead though, I wonder if that’s better or worse than clabot
  125. pep. So that's our first-party entity :P
  126. jonas’ maybe, except that if we make that list public and it’s clear that it’s public, we don’t have to worry too much about the PII stuff
  127. jonas’ (since it’s the same as for any git repository, even better though because we explicitly offer retractions by history rewriting)
  128. jonas’ (though we probably shouldn’t offer that loudly because it’s a PITA)
  129. pep. And.. not sure how that works in our process at all
  130. pep. Remove the XEP?
  131. jonas’ (and also we might want to have on the git record the interval in which an entity has acked the IPR)
  132. jonas’ yeah, that’s for the day where a problem arises
  133. jonas’ we do have retracted XEPs
  134. jonas’ but I lack knowledge about the history around that
  135. pep. We do but they're still under IPR no?
  136. jonas’ and it’s a different problem really
  137. jonas’ there is XEP-0028
  138. jonas’ nobody knows what that was about ;)
  139. pep. There's also the IoT things
  140. jonas’ it’s been purged so badly that tooling even breaks on the first version found in git, because it lacks all the dtd-required fields except title, abstract and number
  141. pep. haha
  142. jonas’ let’s not get sidetracked here
  143. jonas’ so... I wonder if that list would be feasible
  144. pep. That might be part of the legal things to clear up
  145. jonas’ i.e. that repo with the single IPR-CONTRIBUTORS file
  146. jonas’ people MR to add or remove themselves, and if a commit without Signed-off-by or with a Signed-off-by which isn’t in that list is encountered, we make the CI in xeps red and post a comment
  147. jonas’ (that we can do rather painlessly)
  148. jonas’ the comment would instruct the user to add themselves to that list and re-start the pipeline once their ID has been added
  149. jonas’ I’ll add that to the board card
  150. pep. I'm not entirely sure how to act on this as board
  151. pep. "Hire legal"
  152. pep. Maybe there's a way to ask the software freedom conservancy or fsf{,e}.. dunno
  153. pep. That does seem slightly cumbersome tbh. The first time you MR you have to clone another repo, MR there, wait for it to be accepted, and then you can go back to what it is you were doing
  154. jonas’ you can do it in the gitlab web editor
  155. jonas’ no need for cloning just to edit that single file
  156. jonas’ we could even make a link which brings you right to the editor
  157. jonas’ that makes it not much more complicated than the cla assistant
  158. jonas’ you don’t have to wait for your MR on the ipr-list to pass either
  159. jonas’ I’m also, by the way, not sure if and how you can retract that via cla-assistant by the way
  160. pep. yeah I don't know, I was having a look
  161. pep. Why does CLA Assistant need all these permissions..
  162. jonas’ because everything on github needs all these permissions is my impression
  163. jonas’ re a gitlab solution: we could make the comment something like this: yadayada, don’t know you yet yada link to IPR to acknowledge your agreement, please [add your name to this list](https://gitlab.com/xsf/ipr-list/-/edit/master/IPR-CONTRIBUTORS)
  164. pep. oh, we need to notify about CLA updates :(
  165. jonas’ (click the link, it’ll work)
  166. jonas’ I suppose it’ll look different for a non-member
  167. jonas’ which I can’t make myself easily
  168. jonas’ (because a non-member would have to go through an MR)
  169. jonas’ ah, I can revoke my permissions to push to master, that helps
  170. jonas’ (also revoked yours that way, so you see it how a foreigner would see it)
  171. pep. you got your email wrong
  172. jonas’ yeah, noticed that :)
  173. pep. Should we say committer email == sign-off email?
  174. pep. and if so check with CI
  175. jonas’ not sure if that’s necessary
  176. jonas’ also maybe cumbersome
  177. jonas’ but sure, we could say so and drop the requirement for signed-off-by
  178. jonas’ and simply check by committer email
  179. jonas’ I tend to like this approach by the way
  180. pep. So what we need is actually just a commit, no content really :p
  181. jonas’ you mean on IPR-CONTRIBUTORS?
  182. pep. yeah
  183. jonas’ sure
  184. jonas’ oh, so 18:57:35 pep.> Should we say committer email == sign-off email? was in reference to ipr-list, not for xeps?
  185. pep. the former yes
  186. jonas’ yeah, then, totally && check for that, too.
  187. pep. It doesn't really make sense to enforce in xeps
  188. jonas’ (although we might want not to, because I don’t think you can pick which email gitlab chooses there)
  189. pep. What do you mean?
  190. pep. Ah, webide
  191. jonas’ yupp
  192. jonas’ it seems to use my primary without asking
  193. jonas’ so that’s probably not a smart thing to enforce
  194. pep. I think I want to drop the idea of a repo already? Or maybe a public repo where people commit themselves
  195. pep. Seems kinda error prone
  196. jonas’ what would the alternative be?
  197. pep. wait before this, did you mean you'd have failed CI in xeps add a comment in the MR? Or would that require external tooling?
  198. jonas’ the former
  199. jonas’ we could send a comment from a CI job (with API access == some token)
  200. pep. Just poke the API with CI_SOMETHING_TOKEN?
  201. pep. ok
  202. jonas’ interesting question if the job token is allowed to post comments...
  203. pep. I was gonna say otherwise, "just" have a bot listen for comments, maybe keep the IPR repo private, allow the bot and CI to access it.
  204. jonas’ that would require running a service somewhere
  205. pep. bot listens for comments, replies if author hasn't signed yet leaving something saying "Please reply with "Yes I do"" and then bot updates IPR repo, triggering CI again
  206. pep. yeah..
  207. jonas’ if we have to run a service, we can also give it a nicer web frontend than having to post a comment with specific text
  208. pep. Yeah but it's more work :P
  209. pep. And then we need to worry about oauth etc..
  210. jonas’ the web frontend wouldn’t be that much more work over correctly filtering comments from webhooks
  211. jonas’ that’s true
  212. jonas’ forgot about oauth there for a second
  213. jonas’ more to think about, I think I’ll let this topic rest until tomorrow
  214. bear has left
  215. Tobi has left
  216. bear has joined
  217. lnj has left
  218. winfried has left
  219. winfried has joined