XSF Editor Team - 2020-06-17


  1. jonas’

    pep., posting a comment to the user explaining how they can accept the CLA would be useful though

  2. pep.

    sure, we can do that already no?

  3. pep.

    webhook on "notes"

  4. jonas’

    webhook is the other way ’round

  5. jonas’

    you post a comment via API

  6. jonas’

    you get notified about a comment via webhook

  7. jonas’

    but how would we make the acceptance flow, assuming that --signoff isn’t enough

  8. jonas’

    we need something interactive where the user can ACK it

  9. pep.

    You get notified about a comment, you see if it comes from somebody who hasn't signed, you post a comment

  10. jonas’

    and something would have to be able to receive a webhook if we ake it based on comments

  11. jonas’

    which requires a thing running on some serevr

  12. 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/

  13. jonas’

    if we can make this into a small dockerised service, sure, but someone has to develop and maintain it

  14. 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)

  15. jonas’

    (and let it auto-approve things)

  16. jonas’

    I need to make dinner now

  17. jonas’

    pep., I’d like to keep #949 open to test github/gitlab sync once I set up a prototype

  18. 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

  19. pep.

    sure

  20. pep.

    I can still open PRs here and there for people to implement :p

  21. jonas’

    yupp :)

  22. pep.

    hmm, https://about.gitlab.com/2017/10/22/gitlab-10-1-released/#reject-unsigned-commits

  23. pep.

    Ah wait

  24. pep.

    Ah ok the person was talking about DCO and then throw this feature in their post, I thought that was linked

  25. 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

  26. jonas’

    all we can do is have the ci enforce that

  27. pep.

    And prevent pushes on master? Is it possible to sync with github and do that at the same time?

  28. jonas’

    well, we can’t prevent pushes on master for admins, obviously

  29. jonas’

    because they can simply remove that restriction

  30. pep.

    yes we can!

  31. jonas’

    but we can prevent fat finger pushes indeed

  32. pep.

    Sure..

  33. jonas’

    and require them to go through the gitlab UI and require the pipeline to be green for a merge

  34. pep.

    Yeah, like our anti-linkmauve techniques on poezio

  35. jonas’

    :)

  36. pep.

    Requiring DCO is probably gonna makes waves as well.. even if it's just commit -s :/

  37. pep.

    Thought that's orthogonal to gitlab right. Or am I confused, was that only if IPR could be "solved" without a CLA bot

  38. jonas’

    the latter indeed

  39. jonas’

    I’d prefer abolishing clabot also for data privacy reasons to be honest

  40. jonas’

    (and data protection reasons are a reason making a custom implementation harder, since we’d have to keep a list of PII)

  41. pep.

    Not giving info to third-parties?

  42. jonas’

    (which is meh)

  43. jonas’

    yes

  44. pep.

    The third-party can be a first party (us) though

  45. pep.

    But then.. does that have the same legal value, dunno

  46. jonas’

    we could host that info, but then we’d need a proper privacy policy for that "CLA" service

  47. jonas’

    which is again meh

  48. jonas’

    because that probably involves lawyers and stuff

  49. jonas’

    pep., do you think that’s something for board to ponder about?

  50. pep.

    To host CLA ACKs ourselves?

  51. pep.

    Is it not possible to use the same CLA service we use on github atm? Or is the only interface through the bot?

  52. pep.

    If it's possible then I'd say stick with it for now

  53. pep.

    That's orthogonal to what we're trying to do

  54. pep.

    we don't need more bumps on the road than there already is

  55. pep.

    Ah that seems to be a github service..

  56. jonas’

    I don’t think you can hook it up to gitlab, I checked that first

  57. jonas’

    interesting datapoint: https://docs.google.com/document/d/1zpjDzL7yhGBZz3_7jCjWLfRQ1Jryg1mlIVmG8y6B1_Q/edit

  58. 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.

  59. 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

  60. 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

  61. jonas’

    ah, I see

  62. pep.

    In which case we would have to write a bot but we could still use the same third-party

  63. 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

  64. pep.

    Well..

  65. 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)

  66. pep.

    For the XSF it's a bit different as it seem relicensing all the XEPs has in fact been done already

  67. pep.

    case in point

  68. jonas’

    yup

  69. pep.

    Otherwise there would be XEPs distributed under CC-like (older ones) and some under MIT-like

  70. pep.

    So the gitlab CLA/DCO document doesn't really apply to me here

  71. pep.

    We can't just rely on DCO

  72. jonas’

    probably not indeed

  73. 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

  74. pep.

    If you start to include electronic signatures that's also gonna make waves :P

  75. pep.

    If you start to require electronic signatures that's also gonna make waves :P

  76. 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

  77. 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

  78. pep.

    The CLA assistant binds it against a github identity

  79. jonas’

    which doesn’t matter

  80. jonas’

    I can go and steal your commits and put them up

  81. jonas’

    though the github ToS probably say I can’t do that

  82. jonas’

    not sure

  83. pep.

    I'd say the CLA should state that you can't, but worst case we can also require a DCO

  84. jonas’

    yes, exactly

  85. jonas’

    hence "one commit of each Signed-off-by identity has a line"

  86. jonas’

    so that would be used together with DCO

  87. jonas’

    so that we have "someone" to point to in case of problems

  88. 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...)

  89. pep.

    hmm, what happens when.. somebody wants to retract their ACK

  90. jonas’

    that’s Board business

  91. jonas’

    then we have to go through the whole retraction process

  92. pep.

    But from a technical standpoint, we wouldn't have anything in the repo indicating that this person has done so?

  93. jonas’

    oh, you mean to remove an ack from the cache?

  94. pep.

    Or would you rewrite history?

  95. jonas’

    right. one option would be to do this in a separate repository where we would be happily rewriting history to remove acks

  96. jonas’

    i.e. a repository which only has a list of acked identities, no document data

  97. jonas’

    that’s overhead though, I wonder if that’s better or worse than clabot

  98. pep.

    So that's our first-party entity :P

  99. 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

  100. jonas’

    (since it’s the same as for any git repository, even better though because we explicitly offer retractions by history rewriting)

  101. jonas’

    (though we probably shouldn’t offer that loudly because it’s a PITA)

  102. pep.

    And.. not sure how that works in our process at all

  103. pep.

    Remove the XEP?

  104. jonas’

    (and also we might want to have on the git record the interval in which an entity has acked the IPR)

  105. jonas’

    yeah, that’s for the day where a problem arises

  106. jonas’

    we do have retracted XEPs

  107. jonas’

    but I lack knowledge about the history around that

  108. pep.

    We do but they're still under IPR no?

  109. jonas’

    and it’s a different problem really

  110. jonas’

    there is XEP-0028

  111. jonas’

    nobody knows what that was about ;)

  112. pep.

    There's also the IoT things

  113. 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

  114. pep.

    haha

  115. jonas’

    let’s not get sidetracked here

  116. jonas’

    so... I wonder if that list would be feasible

  117. pep.

    That might be part of the legal things to clear up

  118. jonas’

    i.e. that repo with the single IPR-CONTRIBUTORS file

  119. 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

  120. jonas’

    (that we can do rather painlessly)

  121. jonas’

    the comment would instruct the user to add themselves to that list and re-start the pipeline once their ID has been added

  122. jonas’

    I’ll add that to the board card

  123. pep.

    I'm not entirely sure how to act on this as board

  124. pep.

    "Hire legal"

  125. pep.

    Maybe there's a way to ask the software freedom conservancy or fsf{,e}.. dunno

  126. 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

  127. jonas’

    you can do it in the gitlab web editor

  128. jonas’

    no need for cloning just to edit that single file

  129. jonas’

    we could even make a link which brings you right to the editor

  130. jonas’

    that makes it not much more complicated than the cla assistant

  131. jonas’

    you don’t have to wait for your MR on the ipr-list to pass either

  132. jonas’

    I’m also, by the way, not sure if and how you can retract that via cla-assistant by the way

  133. pep.

    yeah I don't know, I was having a look

  134. pep.

    Why does CLA Assistant need all these permissions..

  135. jonas’

    because everything on github needs all these permissions is my impression

  136. 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)

  137. pep.

    oh, we need to notify about CLA updates :(

  138. jonas’

    (click the link, it’ll work)

  139. jonas’

    I suppose it’ll look different for a non-member

  140. jonas’

    which I can’t make myself easily

  141. jonas’

    (because a non-member would have to go through an MR)

  142. jonas’

    ah, I can revoke my permissions to push to master, that helps

  143. jonas’

    (also revoked yours that way, so you see it how a foreigner would see it)

  144. pep.

    you got your email wrong

  145. jonas’

    yeah, noticed that :)

  146. pep.

    Should we say committer email == sign-off email?

  147. pep.

    and if so check with CI

  148. jonas’

    not sure if that’s necessary

  149. jonas’

    also maybe cumbersome

  150. jonas’

    but sure, we could say so and drop the requirement for signed-off-by

  151. jonas’

    and simply check by committer email

  152. jonas’

    I tend to like this approach by the way

  153. pep.

    So what we need is actually just a commit, no content really :p

  154. jonas’

    you mean on IPR-CONTRIBUTORS?

  155. pep.

    yeah

  156. jonas’

    sure

  157. jonas’

    oh, so 18:57:35 pep.> Should we say committer email == sign-off email? was in reference to ipr-list, not for xeps?

  158. pep.

    the former yes

  159. jonas’

    yeah, then, totally && check for that, too.

  160. pep.

    It doesn't really make sense to enforce in xeps

  161. jonas’

    (although we might want not to, because I don’t think you can pick which email gitlab chooses there)

  162. pep.

    What do you mean?

  163. pep.

    Ah, webide

  164. jonas’

    yupp

  165. jonas’

    it seems to use my primary without asking

  166. jonas’

    so that’s probably not a smart thing to enforce

  167. pep.

    I think I want to drop the idea of a repo already? Or maybe a public repo where people commit themselves

  168. pep.

    Seems kinda error prone

  169. jonas’

    what would the alternative be?

  170. 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?

  171. jonas’

    the former

  172. jonas’

    we could send a comment from a CI job (with API access == some token)

  173. pep.

    Just poke the API with CI_SOMETHING_TOKEN?

  174. pep.

    ok

  175. jonas’

    interesting question if the job token is allowed to post comments...

  176. 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.

  177. jonas’

    that would require running a service somewhere

  178. 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

  179. pep.

    yeah..

  180. 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

  181. pep.

    Yeah but it's more work :P

  182. pep.

    And then we need to worry about oauth etc..

  183. jonas’

    the web frontend wouldn’t be that much more work over correctly filtering comments from webhooks

  184. jonas’

    that’s true

  185. jonas’

    forgot about oauth there for a second

  186. jonas’

    more to think about, I think I’ll let this topic rest until tomorrow