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.


  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.


  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’


  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.


  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’


  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.


  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.


  183. jonas’


  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’


  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.


  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.


  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