Am I missing something or does the security release recommend updating to the latest version without saying what that latest version is (at time of writing)?
Come to think of it, how can you find what version of Gitlab is being run? (through the web interface on a CE instance)
> "It would make sense if they had a "newest only", where if you have one deployment running and 10 pending, by the time the current deployment finishes, gitlab would cancel all deployments except for the latest one. This way you don't have to wait for old deployments, and you're free to do a rollback at any time."
Hi, GitLab Team member here. This is exactly how GitLab functions when you use "newest first" process mode [1] with Prevent outdated deployment jobs enabled [2]. By default, pipeline job retries for deployment rollback is enabled, you can rollback to any of the failed old deployments, except where its disabled. [3]
But there's no way to have an actual "developer" role that isn't using non-ultimate seat right?
I get why in some sense, because once you use ultimate you switch to using a EE install instead of the CE. But I think even having the choice between ultimate and normal paid tiers would be great, even if it means no free users on the instance.
thanks, i wasn't aware of this. that's even more than i was looking for, except, the no commercial activity rule seems a bit limiting:
Not seek profit: An organization can accept donations to sustain its work, but it can’t seek to make a profit by selling services, by charging for enhancements or add-ons, or by other means.
so i can't sell services to sustain the project? there is a large difference between earning some money to help fund the project, making barely enough to be able to work on the project fulltime and actually making enough of a profit to afford commercial services.
if i am employed and work on a FOSS project on work time, then i am not selling any services, nor am i making a profit.
if i do exactly the same but as a contractor, then i am selling a service.
you may want to elaborate how you interpret and verify this rule.
also i'd rather have less free services but a more liberal allowance on commercial activity. like a regular free account but without the user limit.
user limits are very frustrating because they prevent me from managing all potential contributors, even if they are not very active.
GitLab team member here! User Limits will not apply to a public group as a top namespace and as at this time, no limit on private groups within a public top namespace group. See the 6th Q&A entry in the FAQ page (https://about.gitlab.com/pricing/faq-efficient-free-tier/#us...), excerpt here:
> Q. Do these changes apply to private projects within a top-level namespace with public visibility? A. User limits are currently applied based on the visibility of the top-level namespace. We will monitor how top-level namespaces with public visibility are using private projects to identify whether any limits on such projects are needed.
Hi, GitLab team member here. Due to a number of factors, which includes high applicant volumes, the talent acquisition team may not be able to provide detailed decline feedback. You can get more details on our handbook page: https://about.gitlab.com/handbook/hiring/interviewing/#rejec...
> it may not be possible for the talent acquisition team to provide detailed decline feedback
That sounds like the exception, but ok, what happens when it is not possible?
Like you know, send a message "Dear candidate, unfortunately the talent acquisiton team did not manage to provide decline feedback because of xxxxxxx[0] , sorry."
Or "nothing"?
And in how many cases does this happen?
Like 1%, 5%, 35% or 99%?
IMHO it would be much simpler to directly write in your handbook something like:
"No decline feedback will be provided. No exceptions."
This way the candidate won't be expecting it.
[0] Examples:
my dog ate the feedback
the feedback was stored in a cabinet that got flooded
the hard disk where the feedback was stored failed before a backup was made
A minor correction above, the last phrase is supposed to read "why we prioritized annual over monthly pricing", as described on the linked GitLab handbook page.
GitLab team member here! This implementation will be client-side only, with a selection of extensions allowed. Self-hosted instance admins will be able to enable or create an allow-list of extensions on their instance.
You can learn more in this epic: https://gitlab.com/groups/gitlab-org/-/epics/7683
