boleary-gl

Anytime you publish something, it is copyrighted. The data within may not be, but my presentation of it in a certain database certainly is.

Or use another source that is non-GPL - that's proposed here: https://github.com/rails/rails/issues/41750#issuecomment-805...

Heroku apps run in a hyper scale cloud, sure, but they abstract away all of that. When you "graduate" from Heroku you have to move your entire app and re-architect the entire thing.

The idea behind this effort is to put you in a cloud native hyper cloud environment of your choice to start with and make that just as easy as Heroku. The big difference will be when you "graduate" - you'll already be in AWS or what have you, and under the covers isn't a black box but is a well formed set of GitLab primitives that you can now continue to use and expand upon.

We attempted it in a previous OKR last quarter: https://gitlab.com/groups/gitlab-com/marketing/corporate_mar.... That's why I mentioned it in the past tense. This article was not part of that old OKR, you can see the issues that brought it up.

And the "we" there refers more to my team - the author of the post is on my team. GitLab OKRs start at the company level, but every team has their own that roll up: https://about.gitlab.com/company/okrs/.

Where does that show anyone from the PR department approving it? I don't see anyone I recognize from the PR department there...

This is how "unfiltered" blogs work: https://about.gitlab.com/handbook/marketing/blog/unfiltered/

I wrote that sentence and you took that completely out of context.

Here's the context if someone really does care: https://gitlab.com/gitlab-com/marketing/corporate_marketing/...

It's also important to note in a non-transparent company you wouldn't see any of this

GitLab employee here. That was based on requirements outside of our control - and it is still available to employees and candidates. Everything is public by default, except for things that can't be - but we're public about what isn't public: https://about.gitlab.com/handbook/communication/#not-public

I like that title a lot - it is a more concise statement.

Production apps in a hyper scale cloud

I think that lots of the clouds will have their own offering, but having an open source based offering across clouds is what we're going for.

Also it's very early stages - but the goal would to be better than Beanstalk

In this context "Hyper Cloud" means one of the major cloud vendors - AWS, GCP, Azure.

GitLab employee here.

That is correct - we also will be posting updates here: https://twitter.com/gitlabstatus/.

Both?

GitLab team member here.

We're actively working on mitigating this spam attack: https://twitter.com/gitlabstatus/status/1358777539624198145

You can read a bunch about how we made that decision here: https://about.gitlab.com/handbook/ceo/pricing/#price-differe...

GitLab Team Member here. If you could reach out to your account team, that would be great. We’d love to hear your thoughts and have an opportunity to understand what is valuable to you. We realize that this is a significant change for Starter/Bronze users, and we want to make sure we can provide you with the best possible service through the transition. We’re also offering a free upgrade to Premium for the first 25 users, which may help you get a better sense of Premium's value for your team.

GitLab Team Member here. The pricing is the same for both our SaaS and self-managed products - and the tiers are now identical as well.

Yes! Thank you for this (in hindsight, obvious) idea.

Can you share an example or screenshot of what you mean around the rendering issue in merge requests?

As for the issue redirects - it does stink. It's an artifact of our move to a single code base for CE and EE [1]. A lot of issues have long-standing SEO so the "old" issue often comes up in a Google search.

[1] https://about.gitlab.com/blog/2019/08/23/a-single-codebase-f...

No, Wikimedia is going to be using the Community Edition (CE) of GitLab, which is free and open source under an MIT license. This decision and the reasons for it are described in more detail in the FAQ section of the linked article.

That's correct - with the GitLab Enterprise Edition you can self-host GitLab and get access to all of the features - both those from the Core open source version as well as our proprietary features.

GitLab team member here

This is fantastic! If interested, you may want to check out our program for Open Source users of GitLab: https://about.gitlab.com/handbook/marketing/community-relati....

GitLab team member here.

That is correct - in 2017 https://about.gitlab.com/blog/2017/03/15/gitter-acquisition/. But as announced today, Gitter will be going to Matrix going forward.

GitLab team member here - thanks for sharing! This is great.

GitLab team member here - can you share what made you want to make the move?

GitLab team-member here.

GitLab also detects if there is a conflict on a merge request as things change and will notify the user

This is awesome! Thanks for sharing.

GitLab technical evangelist here

We've been sharing updates on the linked status page, the original link of this thread.

As is mentioned in the issue you linked, it appears there is some network peering issue for some types of traffic between Level 3 in Philly and Cloudflare. We've been pushing escalation at both providers.

I feel your frustration as it's impacting me too. Right now I'm only able to work around it being an intermittent problem by connecting to a VPN. Unfortunately the packets aren't even getting to Cloudflare, much less to us, so while we're pushing as hard as we can, there's nothing we can actually do beyond that.

GitLab Developer Evangelist here

GitLab flow is much closer to trunk based development than git flow is. While no one "flow" works for everyone, I think that we are clearly in agreement that the simpler you can make your workflow, the better. The problem is some companies and organizations can't get all the way to trunk-based development based on their own regulatory needs or the type of software they are producing.

That's why we think GitLab flow is a great way to balance both - in fact in the other linked blog post [1] we mention that GitLab flow should allow for CD from either branches or tags. From the main branch would then basically be the same as trunk based development, yes?

[1] https://about.gitlab.com/blog/2016/07/27/the-11-rules-of-git...

We're working on this issue here: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/8052. Hardest part - like much of software engineering - is trying to figure out how to reproduce it.