Experiences with self-hosted git servers

[Adriaan de Groot]

On Tuesday, 4 February 2020 15:37:57 CET Ed Maste wrote:
> There are a number of options for self-hosting, such as Gitea, GitLab,
> as well as git's plain built-in server. Phabricator (which we use for
> code reviews) also includes a repository hosting module named
> Diffusion.
> 
> I am interested in hearing from FreeBSD users and developers who have
> used one or more of these, or other Git hosting tools - what worked
> well, what didn't? What do you wish you had known before getting
> started?

With my KDE hat on (yet my FreeBSD mail address): talk to KDE sysadmin (part 
of whom I'm BCCing).

We migrated from SVN to git a few years ago, and first did cgit (that's git's 
internal server, I think) plus reviewboard; then cgit plus phabricator; now 
we're migrating to GitLab and dropping cgit and phabricator. That last 
migration is taking a while.

KDE differs from FreeBSD in that we have about 300 repositories (one for each 
bit of KDE software) rather than a small number of really big repo's (e.g. 
src, ports). There is a vaguely similar mechanism of "joining the project" and 
code-review is generally enforced by social contract, like in FreeBSD ports.

GitLab is generally pretty responsive in working with larger Free Software 
projects; it is used by KDE and Gnome in that way, who have their self-hosted 
Community Edition GitLabs to work with, more-or-less integrated with their own 
identity provider systems. Having a web-based workflow, that also supports 
drive-by-contributions, is seen as a bonus over plain git + phab. Especially 
Phabricator seems to be a drag on potential-new-contributors (and I'm not sure 
if it's developed anymore, which is one of the reasons KDE is switching away 
from it).

Mainly for the move to GitLab:

 - figure out what role issues will play; are those for reviews? Developer 
planning? bug reports? How do they align with Bugzilla use?
 - figure out a branching strategy; what kind of private branches do you want? 
where are force-pushes allowed (eg. when rebasing or re-doing a patchset)? 
squash or maintain development history? commit to master only?
 - think about a labels- and tags-scheme;

[ade]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freebsd.org/pipermail/freebsd-git/attachments/20200204/2f733c02/attachment.sig>