-
jonas’
pep., posting a comment to the user explaining how they can accept the CLA would be useful though
-
pep.
sure, we can do that already no?
-
pep.
webhook on "notes"
-
jonas’
webhook is the other way ’round
-
jonas’
you post a comment via API
-
jonas’
you get notified about a comment via webhook
-
jonas’
but how would we make the acceptance flow, assuming that --signoff isn’t enough
-
jonas’
we need something interactive where the user can ACK it
-
pep.
You get notified about a comment, you see if it comes from somebody who hasn't signed, you post a comment
-
jonas’
and something would have to be able to receive a webhook if we ake it based on comments
-
jonas’
which requires a thing running on some serevr
-
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/
-
jonas’
if we can make this into a small dockerised service, sure, but someone has to develop and maintain it
-
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)
-
jonas’
(and let it auto-approve things)
-
jonas’
I need to make dinner now
-
jonas’
pep., I’d like to keep #949 open to test github/gitlab sync once I set up a prototype
-
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
-
pep.
sure
-
pep.
I can still open PRs here and there for people to implement :p
-
jonas’
yupp :)
-
pep.
hmm, https://about.gitlab.com/2017/10/22/gitlab-10-1-released/#reject-unsigned-commits
-
pep.
Ah wait
-
pep.
Ah ok the person was talking about DCO and then throw this feature in their post, I thought that was linked
-
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
-
jonas’
all we can do is have the ci enforce that
-
pep.
And prevent pushes on master? Is it possible to sync with github and do that at the same time?
-
jonas’
well, we can’t prevent pushes on master for admins, obviously
-
jonas’
because they can simply remove that restriction
-
pep.
yes we can!
-
jonas’
but we can prevent fat finger pushes indeed
-
pep.
Sure..
-
jonas’
and require them to go through the gitlab UI and require the pipeline to be green for a merge
-
pep.
Yeah, like our anti-linkmauve techniques on poezio
-
jonas’
:)
-
pep.
Requiring DCO is probably gonna makes waves as well.. even if it's just commit -s :/
-
pep.
Thought that's orthogonal to gitlab right. Or am I confused, was that only if IPR could be "solved" without a CLA bot
-
jonas’
the latter indeed
-
jonas’
I’d prefer abolishing clabot also for data privacy reasons to be honest
-
jonas’
(and data protection reasons are a reason making a custom implementation harder, since we’d have to keep a list of PII)
-
pep.
Not giving info to third-parties?
-
jonas’
(which is meh)
-
jonas’
yes
-
pep.
The third-party can be a first party (us) though
-
pep.
But then.. does that have the same legal value, dunno
-
jonas’
we could host that info, but then we’d need a proper privacy policy for that "CLA" service
-
jonas’
which is again meh
-
jonas’
because that probably involves lawyers and stuff
-
jonas’
pep., do you think that’s something for board to ponder about?
-
pep.
To host CLA ACKs ourselves?
-
pep.
Is it not possible to use the same CLA service we use on github atm? Or is the only interface through the bot?
-
pep.
If it's possible then I'd say stick with it for now
-
pep.
That's orthogonal to what we're trying to do
-
pep.
we don't need more bumps on the road than there already is
-
pep.
Ah that seems to be a github service..
-
jonas’
I don’t think you can hook it up to gitlab, I checked that first
-
jonas’
interesting datapoint: https://docs.google.com/document/d/1zpjDzL7yhGBZz3_7jCjWLfRQ1Jryg1mlIVmG8y6B1_Q/edit
-
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.
-
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
-
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
-
jonas’
ah, I see
-
pep.
In which case we would have to write a bot but we could still use the same third-party
-
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
-
pep.
Well..
-
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)
-
pep.
For the XSF it's a bit different as it seem relicensing all the XEPs has in fact been done already
-
pep.
case in point
-
jonas’
yup
-
pep.
Otherwise there would be XEPs distributed under CC-like (older ones) and some under MIT-like
-
pep.
So the gitlab CLA/DCO document doesn't really apply to me here
-
pep.
We can't just rely on DCO
-
jonas’
probably not indeed
-
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
-
pep.
If you start to include electronic signatures that's also gonna make waves :P✎ -
pep.
If you start to require electronic signatures that's also gonna make waves :P ✏
-
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
-
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
-
pep.
The CLA assistant binds it against a github identity
-
jonas’
which doesn’t matter
-
jonas’
I can go and steal your commits and put them up
-
jonas’
though the github ToS probably say I can’t do that
-
jonas’
not sure
-
pep.
I'd say the CLA should state that you can't, but worst case we can also require a DCO
-
jonas’
yes, exactly
-
jonas’
hence "one commit of each Signed-off-by identity has a line"
-
jonas’
so that would be used together with DCO
-
jonas’
so that we have "someone" to point to in case of problems
-
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...)
-
pep.
hmm, what happens when.. somebody wants to retract their ACK
-
jonas’
that’s Board business
-
jonas’
then we have to go through the whole retraction process
-
pep.
But from a technical standpoint, we wouldn't have anything in the repo indicating that this person has done so?
-
jonas’
oh, you mean to remove an ack from the cache?
-
pep.
Or would you rewrite history?
-
jonas’
right. one option would be to do this in a separate repository where we would be happily rewriting history to remove acks
-
jonas’
i.e. a repository which only has a list of acked identities, no document data
-
jonas’
that’s overhead though, I wonder if that’s better or worse than clabot
-
pep.
So that's our first-party entity :P
-
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
-
jonas’
(since it’s the same as for any git repository, even better though because we explicitly offer retractions by history rewriting)
-
jonas’
(though we probably shouldn’t offer that loudly because it’s a PITA)
-
pep.
And.. not sure how that works in our process at all
-
pep.
Remove the XEP?
-
jonas’
(and also we might want to have on the git record the interval in which an entity has acked the IPR)
-
jonas’
yeah, that’s for the day where a problem arises
-
jonas’
we do have retracted XEPs
-
jonas’
but I lack knowledge about the history around that
-
pep.
We do but they're still under IPR no?
-
jonas’
and it’s a different problem really
-
jonas’
there is XEP-0028
-
jonas’
nobody knows what that was about ;)
-
pep.
There's also the IoT things
-
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
-
pep.
haha
-
jonas’
let’s not get sidetracked here
-
jonas’
so... I wonder if that list would be feasible
-
pep.
That might be part of the legal things to clear up
-
jonas’
i.e. that repo with the single IPR-CONTRIBUTORS file
-
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
-
jonas’
(that we can do rather painlessly)
-
jonas’
the comment would instruct the user to add themselves to that list and re-start the pipeline once their ID has been added
-
jonas’
I’ll add that to the board card
-
pep.
I'm not entirely sure how to act on this as board
-
pep.
"Hire legal"
-
pep.
Maybe there's a way to ask the software freedom conservancy or fsf{,e}.. dunno
-
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
-
jonas’
you can do it in the gitlab web editor
-
jonas’
no need for cloning just to edit that single file
-
jonas’
we could even make a link which brings you right to the editor
-
jonas’
that makes it not much more complicated than the cla assistant
-
jonas’
you don’t have to wait for your MR on the ipr-list to pass either
-
jonas’
I’m also, by the way, not sure if and how you can retract that via cla-assistant by the way
-
pep.
yeah I don't know, I was having a look
-
pep.
Why does CLA Assistant need all these permissions..
-
jonas’
because everything on github needs all these permissions is my impression
-
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)
-
pep.
oh, we need to notify about CLA updates :(
-
jonas’
(click the link, it’ll work)
-
jonas’
I suppose it’ll look different for a non-member
-
jonas’
which I can’t make myself easily
-
jonas’
(because a non-member would have to go through an MR)
-
jonas’
ah, I can revoke my permissions to push to master, that helps
-
jonas’
(also revoked yours that way, so you see it how a foreigner would see it)
-
pep.
you got your email wrong
-
jonas’
yeah, noticed that :)
-
pep.
Should we say committer email == sign-off email?
-
pep.
and if so check with CI
-
jonas’
not sure if that’s necessary
-
jonas’
also maybe cumbersome
-
jonas’
but sure, we could say so and drop the requirement for signed-off-by
-
jonas’
and simply check by committer email
-
jonas’
I tend to like this approach by the way
-
pep.
So what we need is actually just a commit, no content really :p
-
jonas’
you mean on IPR-CONTRIBUTORS?
-
pep.
yeah
-
jonas’
sure
-
jonas’
oh, so 18:57:35 pep.> Should we say committer email == sign-off email? was in reference to ipr-list, not for xeps?
-
pep.
the former yes
-
jonas’
yeah, then, totally && check for that, too.
-
pep.
It doesn't really make sense to enforce in xeps
-
jonas’
(although we might want not to, because I don’t think you can pick which email gitlab chooses there)
-
pep.
What do you mean?
-
pep.
Ah, webide
-
jonas’
yupp
-
jonas’
it seems to use my primary without asking
-
jonas’
so that’s probably not a smart thing to enforce
-
pep.
I think I want to drop the idea of a repo already? Or maybe a public repo where people commit themselves
-
pep.
Seems kinda error prone
-
jonas’
what would the alternative be?
-
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?
-
jonas’
the former
-
jonas’
we could send a comment from a CI job (with API access == some token)
-
pep.
Just poke the API with CI_SOMETHING_TOKEN?
-
pep.
ok
-
jonas’
interesting question if the job token is allowed to post comments...
-
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.
-
jonas’
that would require running a service somewhere
-
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
-
pep.
yeah..
-
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
-
pep.
Yeah but it's more work :P
-
pep.
And then we need to worry about oauth etc..
-
jonas’
the web frontend wouldn’t be that much more work over correctly filtering comments from webhooks
-
jonas’
that’s true
-
jonas’
forgot about oauth there for a second
-
jonas’
more to think about, I think I’ll let this topic rest until tomorrow