Hi Operyl - GitLab Product Leader here. Our process for updating the What's New content is delayed slightly from the release (as we use the release post images that are published on the 22nd for the What's New highlights). They'll show up shortly.
Product Leader from GitLab here - In support of what Mitchell said. One lesson we learned from Auto DevOps is that composability and transparency were key. Just like you mentioned tinco - users struggled when things eventually broke - or they wanted to customize beyond the out of the box customizations that were available. That's why we evolved to have composable Auto DevOps[1] and Helm installs via CI/CD pipelines.[2]
In general our "Why Starter" page has some great rationale for why we encourage small teams to utilize GitLab Starter/Bronze. https://about.gitlab.com/pricing/starter/
> For Gitlab, I believe they are or are planning on providing experimental support for CNB. You can probably already use it today if you use pack directly in your pipeline.
> * Both are slow. Silly slow. A 2 second target for page loads is horrific. Jumping around a file structure and exploring blame is really really painful; but 90% of the time I'm on the pipelines page and its so so so slow. Its actually faster for me to have my pipelines webhook a private server for a faster dash.
Agreed - and we're working on performance improvements for GitLab.com. Do you use GitLab.com or a self-managed instance?
> * GitLab is better for CI/CD. Easier, more sensible. I use it all the time; I set new clients up on it.
Thanks - I'll give the feedback to the teams to keep up the good work. We do focus on sensible defaults and easy setup.
> * Gitlab is better for k8's - several clients use it and love it.
Awesome to hear, I have some heritage with this part of the product so I'm glad you love it.
> * Search sucks on them both. They both give a paginated list when what I always want is a place in repo / filetype / etc. filter, post initial search (i.e, I'm looking for loadModule in webpack, I want to ignore tests (when I didn't know which was the test folder before searching), and jump between definition and usage, as well as find out if there is any documentation. Its not worth doing each individually. I want all at once)
> * API's are really slow. GitLab is probably worse here. My default webpage (localhost home page) is a dashboard of quick links and widgets. One of those widgets shows my failing pipelines. It takes 6 seconds on a good day. I bypassed it (as above) to let me be more responsive. I didn't have to bother bypassing it w/GitHub
Uggh - I'm sorry. I don't quite understand your reference to a default webpage and widgets. Is it pulling from GitLab APIs to give you a dashboard of your development work?
> * On my NAS I maintain images of GitLab hosts and backups of all my repos. I have an image of the self-hosted gitlab we had at a previous (it closed) company. Being able to fall back to self-hosted is the oft-touted godsend, but being able to restart a retired self-hosted has literally made me and the others involved several thousand each (twice old clients have wanted a one off job. GitLab is the core of testing and deploying infrastructure).
I didn't follow this one explicitly either. I'm glad you've got backups, are you suggesting GitLab needs some improved restore capabilities from backups?
Whoops - I think you are suggesting deploying GitLab the application to your existing Kubernetes cluster. The issue, and highlight from the blog post, were about deploying your applications (in GitLab projects) to a Kubernetes cluster.
For a bit more about WHY we choose breadth over depth - We believe that the company plowing ahead of other contributors is more valuable in the long run. It encourages others to contribute to the polish while we validate a future direction. You can read more on our company strategy page - https://about.gitlab.com/company/strategy/#breadth-over-dept...
As open-source software we want everyone to contribute to the ongoing improvement of GitLab.