Re: Migrate away from vger to GitHub or (on-premise) GitLab?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024-02-01 21:01, rsbecker@xxxxxxxxxxxxx wrote:
On Thursday, February 1, 2024 2:00 PM, Dragan Simic wrote:
On 2024-02-01 19:36, Hans Meiser wrote:
Quite frankly, I think you've missed some important points from the
Konstantin's message.  To sum it up a bit, not having continuous
support is simply unacceptable for any kind of a long-term project.

As I wrote, once installed on-premise, no-one will shut down an
on-premise git server except for yourself. It can run for eternity.
You just need someone to administer it properly and publish the
website.

A git server? I was under impression that you proposed running an own instance of
GitLab or something similar.

Git is unique, as a project, given that everything (! Not everything
but a whole lot) is managed using git, including the enterprise git
server platforms.

A huge advantage of using a git server is being able to mirror the
repository. If we went with a GitLab host, we could potentially mirror
over to GitHub. The drawback is that the pull request history (and
related discussions) id not (currently) preserved. I think this is a
situation no matter what, even if we go GitLab/GitLab or
GitHub/GitHub. The value of the discussion threads is the most
important part of what needs to be preserved. I have high confidence
that the team could move to either Pull Request/Merge Request
structure reasonably easily, but if we had to move again in future
(count on it), there must be a way to preserve the community assets of
the discussions that went into making decisions. Without that, I am
concerned that a migration to a GitLab (or any other) instance would
increase velocity but put long term decisions at risk.

Good point, I agree that the value of the discussions on the mailing
list is extremely high.  We should also keep in mind that the risk of
a vendor lock-in is even higher when it comes to the discussions.

Frankly, the resilience of email as a service and the openness of its
format can hardly be beaten.

In the end, it's all just about git. You may create your own git
webserver (https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb),
or just use an existing one, like the GitLab server:
https://about.gitlab.com/install/

In these servers, everything is configurable. Moreover, many plug-ins
exist for plumbing extensions to these providers. It's possible to
establish your own workflow, rights management and automatic handling.
You just need someone who is an expert with the tool of your choice.

Many other great repositories already are using one of those
providers; Meta, Google, Microsoft for example share their code there
– just to name a few. I wouldn't consider these users as being known
for being exceptional risk-takers.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux