Thanks for your insights and comparisons Tim. You make an incredibly compelling case (for a switch to the Omnibus install).

Your points re lifecycle management costs are on point and not lost on me! As has been discussed, it would certainly lighten the maintenance load for both us and end users - which can only be a plus for TurnKey. Anything that reduces the time and effort (internally or externally), means we can all do more of something else (hopefully more compelling than updating software)...! ;)

I anticipate that we will certainly look to a packaged GitLab install at some point (hopefully not too far away). Although I'm still not sure which direction we'll go; Omnibus or Debian backports. Personally, I'd prefer to leverage the Debian backports package(s), as it conforms to the "proper" Debian packaging regime - as noted in my previous post; small individual packages with a dependency tree. Using that install path would allay many of my concerns about the "monolithic" Omnibus package, whilst still providing most (if not all) the value you ascribe to the Omnibus install. GitLab itself still wouldn't get auto security updates, but the underlying dependencies would. And updating GitLab would still be a simple apt update && apt install gitlab-ce! ;)

The fact that GitLab are now financially sponsoring a small team within Debian to do the (backports) packaging, adds weight too. A single (no matter how motivated) Debian developer maintaining it is nowhere near as appealing.

The bigger question of exactly how we will manage that transition remains though. It requires some further thought and consideration... I plan to discuss with Alon next week, so hope to make a decision soon, and start working towards the agreed plan soon after that.

FWIW I have been writing a response to your further points, but I need to get on with other stuff. I was just going to post what I'd written, but it's not quite ready for public consumption. It's a bit long winded and repetitive and could possibly be misconstrued as an anti GitLab rant (which it wasn't intended to be). Instead I've cut it back savagely, unfortunately, it no longer addresses many/most of your GitLab related points.

Regarding Gitea, it's worth noting that the primary reason why we built a Gitea appliance (and why I often mention it to users struggling in one way or another with GitLab) is that we've had a number of requests for it, both explicitly (i.e. they want a "Gitea appliance") and generically (i.e. they want something "more" than Revision Control but "less" than GitLab).

Bottom line is that I have no interest in dissing GitLab and I don't suggest Gitea as a "silver bullet" that is unequivocally "better" than GitLab by all metrics (it's clearly not). Although I do stand by the fact that in many use cases, Gitea is a legitimate (if not preferable) option to GitLab, depending on needs, preferences and available resources.

I have no desire to discourage anyone from using GitLab, merely a desire to highlight the Gitea appliance as something that may be a preferable alternative to some users. It certainly fulfils my needs better than GitLab.

Regardless of my personal opinions, while GitLab remains open source, we'll continue to provide a GitLab appliance (hopefully it'll soon be better than the one we currently provide).

Take care mate and thanks again for sharing your insights and experience. I may not always follow your advice/opinion exactly, but do I always appreciate your input and take it into consideration.