I co-maintain a project which builds Docker images of active Python releases for use by downstream Python projects for their CI. It’s open source and fully volunteer. It’s been on GL for 4 years, and it’s been working great. It essentially just runs every few hours, grabs the latest Python tarballs and builds them in GL pipelines. For the most part it’s fully automated and we’ve been very happy with it.
I’ve recently started to get notifications that its namespace is running out of Shared Runner Pipeline minutes. I’ve tried to re-up our Open Source registration to gain more minutes, but have not heard anything back from GL in almost a week. (Aside from my qualms about the actual process of signing up for the GL Open Source program, it’s worked well for us in the past.). Is there anyone at GitLab that can help move the process along and get us more minutes?
Hi @barry I’m happy to take a look at this for you. I did find your GitLab for Open Source Program application dated 2022-10-13, reviewed it today, and approved your membership. You should soon receive an email containing details on activating your subscription license.
Processing applications is currently taking our team longer than it usually does, as an unprecedented number of projects are submitting application forms in light of the upcoming changes to GitLab’s Free-tier offerings. We’re doing our best to keep up—but, sometimes processing any particular application may take a few days.
Thanks so much @bbehr ! I did receive the email and will try activating it tomorrow. No worries about the delay. I was getting desperate because we have the Python 3.11 release coming this month and I was down to 5% of our minutes left!
With (hopefully) minimal snark — I’m trying my hardest, anyway — I’ll suggest that, while the volume may indeed be unprecedented for GitLab’s OSS program, it’s not much of a surprise considering everyone went through the exact same thing with Travis CI just two years ago.
And, hey, GitLab is already way ahead of the curve there. The Travis team took until FOUR MONTHS (to the day) after we’d already bailed on their service — because our trial credits ran out and builds started failing — before they even responded to any of our project’s attempts at getting accepted into their OSS program.
The response, when it came, was an approval, along with an initial grant of enough credits for roughly three months’ worth of automatic CI builds. (Then what, we wait another four months to be granted more?) But oddly enough, in light of that history we didn’t find the idea of moving our builds back to Travis (for three months?) very enticing.
Of course, myself and my OSS teams greatly appreciate the gitlab.com service. My one suggestion is that it should be a lot easier to sign up for the OSS program. Some of the instructions are incorrect* and other information should be easily automated from my repo, like the license file, etc.
*There’s a step where it asks you to take a screenshot to show your license tag, but there doesn’t appear to be any way to make that tag actually show up in the display, despite the clear OSS license I use.
Thanks for your feedback here. We always appreciate it. We’re always looking at ways we can automate additional aspects of the application process and will gladly consider this. My dream scenario is currently one that allows us to better utilize SPDX headers. Hope to get there sooner rather than later!
As for inconsistent and incorrect documentation: That’s something we definitely can (and should) act on immediately. Can you please help me better understand where you’re seeing the confusing or incorrect instructions?
That would be great. It sure seems like the whole process could be automated given the project name or URL. I’m guessing its tricky because you’re using the third party SheerID to do the verification. OTOH, since the project must be open and public, they ought to be able to confirm the license choice.
Thanks for passing this along, @barry. I can see the confusion now. The documentation instructs users to click Add LICENSE, but in Screenshot 1 the license (MIT) is already applied, so that button does not appear.
If your repository already contains a LICENSE.md file and GitLab can use it to deduce the license you’re using for your project, it will overwrite the text of the Add LICENSE button with the name of the project’s license.
You can see how this works by glimpsing the buttons to the right of the license identifier in Screenshot 1. The buttons Add README and Add CHANGELOG, for example, exist because the project does not currently contain those files.
@bbehr - actually, my repo does already contain a LICENSE.txt and a README.md, but no CHANGELOG or CONTRIBUTING files, and I see none of those buttons.
Interesting! Thanks for your effort in cataloging this and pointing it out, @barry. I would not have expected that to be the behavior, but, well, there it is! (I don’t suppose you’re logged out? I know that might affect the appearance of the buttons.)
I will consult with a few of my colleagues so we can determine the best way to update the documentation. Thanks again.
I’m happy to take a look at this for you. I did find your GitLab for Open Source Program application dated 2022-10-13, reviewed it today, and approved your membership. You should soon receive an email containing details on activating your subscription license.