Fwd: [kde-community] Future Git Plans

Myriam Schweingruber myriam at kde.org
Sat Feb 15 09:53:44 UTC 2014


FYI. We have been guinea pigs for KDE in the past, could be a good idea again?

Regards, Myriam


---------- Forwarded message ----------
From: Jeff Mitchell <mitchell at kde.org>
Date: Sat, Feb 15, 2014 at 4:52 AM
Subject: [kde-community] Future Git Plans
To: kde-community at kde.org, "sysadmin at kde.org" <sysadmin at kde.org>


(Sending from the proper account this time)

Hello KDE Community,

Several years ago when transitioning to Git the sysadmins evaluated
several possible options, including GitLab, Gitorious, Gitolite, and
Gerrit. At the time, GitLab was quite immature in terms of code,
community, and documentation. After evaluating options, we chose
Gitolite, and built a suite of other services and helpers on top of
it.

Gitorious has come along since being purchased by Powow AS, but still
lags behind other solutions. Gerrit is still geared towards very
specific code-review workflows and has an interface that is very
difficult to grasp for more novice users. Gitolite is absolutely
wonderful software, but it does one specific thing; we've set up a
large number of other scripts, web servers, and web applications to
address the things it doesn't do but that our community needs.

However, in the intervening years, GitLab (https://www.gitlab.com/)
has advanced tremendously, due in part to the thousands of eyeballs
it's had on its source code while gaining major footholds into the Git
hosting market. It has gained documentation, features, an API, and a
great deal of stability and maturity to its code base.

Due to its feature set, GitLab alone could take the place of at least
projects.kde.org, commits.kde.org, quickgit.kde.org, and -- due to the
built-in merge request workflow -- reviewboard.kde.org, drastically
easing management and maintenance burden for the sysadmins. If the
built-in wiki and issue tracking capabilities are enabled (which can
be managed per-project), then projects (especially self-contained
ones, such as Extragear projects) that desire a highly integrated
workflow could migrate those functions to GitLab as well (note that
this is not a statement indicating that we are planning to ditch
Bugzilla any time soon!).

Replacing Gitolite with GitLab would have a number of benefits from
the user perspective too, versus having all of those features spread
across multiple different sites. I strongly encourage interested
parties to go to http://demo.gitlab.com/ and browse around. (One
benefit that is not immediately apparent is support for HTTPS as a
protocol for pushing commits).

This replacement could require some minor changes to workflows based
on the models that GitLab vs. Gitolite supports. However, the
sysadmins feel that the benefits outweigh the burden of transition.
The concrete and specific difference that is likely to cause the most
pain is that personal forks and private repositories are handled very
differently from Gitolite; during the transition period, we would
likely require users to themselves migrate any clone/scratch
repositories to the new system that they would like to keep. A benefit
to this is that a majority of the clone and scratch repositories are
currently forgotten and unused, and this would act as a spring
cleaning.

This email serves two purposes: one, to inform the community of the
direction we would like to go with KDE's Git hosting and request
feedback; two, to ask for volunteer projects that are willing to act
as crash test dummies for the new system, helping us figure out the
best way to set it up, work out kinks, etc. Due to the bleeding-edge
nature, we're currently limiting this to self-contained projects, such
as those in Extragear.

Thanks,
Jeff
_______________________________________________
kde-community mailing list
kde-community at kde.org
https://mail.kde.org/mailman/listinfo/kde-community


-- 
Proud member of the Amarok and KDE Community
Protect your freedom and join the Fellowship of FSFE:
http://www.fsfe.org
Please don't send me proprietary file formats,
use ISO standard ODF instead (ISO/IEC 26300)


More information about the Amarok-devel mailing list