Fully move repository to SPDX organization about fsf-api

[goneall]

I'll follow up with @davidhedlund and FSF on the topic. I'll report back on any progress with FSF.

I'm happy that we were able to resolve 3 of the very old issues for the SPDX license list and feel it was worth the effort to move the repo over.

@CAM-Gerlach thanks for the assistance and collaboration on the effort.

[goneall]

I just saw some of the follow-up issues from @davidhedlund in this repo - see issue #20 for references to very related conversations.

[goneall]

any insight on FSF interest in adopting this project

I'm waiting to hear back from FSF - I set an expectation that I would like to know within 2 weeks, so I hope to hear back soon.

BTW - we did ask this a couple years ago when this utility was initially written without much of a response. I'm hoping this time we'll be able to get an answer.

[davidhedlund]

@goneall follows up with the FSF this. I'm just a coordinator for https://directory.fsf.org/wiki/Free_Software_Directory:SPDX_Group.

I see, thanks. Sorry for the confusion; I only asked since @goneall had posed the same question to you here to which I didn't see an in-band response, and I wasn't aware of the conversations happening through other channels. Just let me know how you all want to move forward and how I can help. Thanks!

Thank you very much for your help on this project.

[goneall]

@CAM-Gerlach FYI on move status

Also - I added review and sign-off rules to the master branch.

Are there other branch protection rule you would suggest for master or gh-pages?

[CAM-Gerlach]

You know how to do it, right? You just message Github support and ask them to unfork it, and they'll do it?

I suggest adding branch protection with no special rules enabled to the gh-pages branch, and on the master branch requiring status checks to pass before merging with the Build API action as an explicitly required check, and requiring conversation resolution before merging. I also suggest only enabling your preferred merge type (merge, squash or rebase) under Merge Options in the top-level Options section of the repo settings, to ensure consistency and conformance to convention.

[goneall]

@CAM-Gerlach thanks for the suggestions.

You know how to do it, right? You just message Github support and ask them to unfork it, and they'll do it?

That what I was thinking. We also have folks from Github participating in SPDX, so I thought I would ping them. I just need to check with the SPDX community first. There was a discussion about a month ago on the SPDX tech call about repositories showing up unexpectedly in the SPDX git repo. I agreed to check on the email list before creating a repo. Although I do not expect this to be controversial, I thought I should honor the request and check first before requesting the change from Google.

I suggest adding branch protection with no special rules enabled to the gh-pages branch, and on the master branch requiring status checks to pass before merging with the Build API action as an explicitly required check, and requiring conversation resolution before merging.

Done

I also suggest only enabling your preferred merge type (merge, squash or rebase) under Merge Options in the top-level Options section of the repo settings, to ensure consistency and conformance to convention.

I'm going to leave this open - to be honest, I like the flexibility of squashing some PR's and merging others depending on how related the commits are.

[goneall]

@CAM-Gerlach - I just added some permissions, so feel free to review/update the branch protections.

I'll take care of the "un-fork".

[CAM-Gerlach]

I just need to check with the SPDX community first.

Sure, fair enough

Done

Thanks!

I'm going to leave this open - to be honest, I like the flexibility of squashing some PR's and merging others depending on how related the commits are.

Gotcha, makes sense. I personally take care to fixup and rebase my commits to ensure each one is atomic and related changes are logically grouped, but when dealing with external contributors it can be a hassle to get them to do this, or else have to do so yourself before merging.

@CAM-Gerlach - I just added some permissions, so feel free to review/update the branch protections.

Thanks! I looked over everything carefully and it all looked good, though there are two options you could think about changing, depending on your preferences, though neither are too terribly important. First, while I like the "Ensure branches are up to date before merging" option in theory, users have a tendency to merge rather than rebase to address this, which leads to a more convoluted, harder to follow commit history and requires extra git fu to clean up commits, though squash merging the PR essentially negates both of these. Second, the dismiss approving reviews when new reviewable commits are pushed option helps ensure that unreviewed code isn't merged, though you may have your reasons for not using it.

In other news, I'll open issues assigned to me for the major items in my comment so we can keep track of them in a more convenient spot.

[CAM-Gerlach]

Also, not directly related but has there been any interest from the FSF in officially adopting this? They are not too fond of GitHub and not sure if they even are okay with GitLab (which would be the easiest move given they offer CIs and Pages just like GitHub), so that might be a blocker to start, though there are probably ways around that.

[goneall]

has there been any interest from the FSF in officially adopting this?

I think having FSF adopt this would be ideal since they should be the authoritative source for the FSF data such as the tag-overrides array. We did approach FSF when @wking first wrote the utility and were not successful in getting any interest.

They are not too fond of Github

I'm quite open to contributing to projects on other platforms. If FSF is willing to adopt or help maintain this on a different platform, we should probably decide before resolving this issue.

I did notice @davidhedlund has an interest in this utility for other FSF projects.

@davidhedlund - any thoughts on FSF adopting this or a different utility to provide the FSF license data in a machine readable format?

[CAM-Gerlach]

I'm quite open to contributing to projects on other platforms. If FSF is willing to adopt or help maintain this on a different platform, we should probably decide before resolving this issue.

Yeah, and the same with most of the other issues here, really. A platform like GitLab would be a simple migration and offer almost all the same facilities as GitHub (static hosting, CIs, issues, PRs, reviewing, etc) while being open source, but if the FSF adopts this, I imagine they would probably want to host it directly on their own infra via Savannah/cgit/etc.

That would require them to re-implement the CI/deploy/hosting stack and be a bit of a barrier to outside contributors/maintainers (and as far as I'm aware, there appears to be be no built-in mechanisms for PRs, code review, CI checks, issue tracking, doc building and many of the other things we've come to expect from modern OSS code collaboration sites), but given all that would then be their responsibility while removing it from us, that would be their call—it is intended to be their API, after all!

It does kinda put a pause on things here until this issue is decided; no need to invest further in infra that might not be needed depending on if/how they want to move forward with this.

[CAM-Gerlach]

Thanks, looking forward to hearing what develops on that front.

Well, that was almost all you, so give yourself more credit, heh. The only critical thing I fixed was a couple relatively simple breaking issues with the code, and by a bit of a hack too. But thanks, I do appreciate it ^_^

[CAM-Gerlach]

Also, one more reason to unfork if the FSF doesn't decide to adopt this themselves—forks are not indexable/searchable by GitHub. Just bit me today in another forked project that serves a distinct purpose from the original.

[davidhedlund]

Also, one more reason to unfork if the FSF doesn't decide to adopt this themselves—forks are not indexable/searchable by GitHub. Just bit me today in another forked project that serves a distinct purpose from the original.

What the Fork!

Can you please suggest GitHub to make them indexable/searchable?

[CAM-Gerlach]

@davidhedlund You can suggest it at github/feedback/discussions. However, while its rather annoying, I'm not sure much will happen, as I presume the reason is to conserve resources given including forks would magnify the search space by potentially many times for relatively little gain. The primary use case of forks on GitHub is to store personal copies of repos for experimentation, local changes and pushing changes upstream, and if the fork evolves to be the canonical project (like this one) or a distinct one (like the one I referred to above that I ran in to), where searching it rather than the upstream or your own local repo has significant value, it should be made the tip of its fork network or unforked into its own project.

In any case, back on topic—any insight on FSF interest in adopting this project, and on the purpose of the repo you linked in #20 ?

[davidhedlund]

@davidhedlund You can suggest it at github/feedback/discussions. However, while its rather annoying, I'm not sure much will happen, as I presume the reason is to conserve resources given including forks would magnify the search space by potentially many times for relatively little gain. The primary use case of forks on GitHub is to store personal copies of repos for experimentation, local changes and pushing changes upstream, and if the fork evolves to be the canonical project (like this one) or a distinct one (like the one I referred to above that I ran in to), where searching it rather than the upstream or your own local repo has significant value, it should be made the tip of its fork network or unforked into its own project.

Ok.

In any case, back on topic—any insight on FSF interest in adopting this project, and on the purpose of the repo you linked in #20 ?

@goneall follows up with the FSF this. I'm just a coordinator for https://directory.fsf.org/wiki/Free_Software_Directory:SPDX_Group.

[CAM-Gerlach]

@goneall follows up with the FSF this. I'm just a coordinator for https://directory.fsf.org/wiki/Free_Software_Directory:SPDX_Group.

I see, thanks. Sorry for the confusion; I only asked since @goneall had posed the same question to you here to which I didn't see an in-band response, and I wasn't aware of the conversations happening through other channels. Just let me know how you all want to move forward and how I can help. Thanks!