Information regarding upcoming Gitlab Migration

Bhushan Shah bshah at mykolab.com
Mon Apr 27 12:58:02 BST 2020


In part I am mostly re-iterating what Ben already mentioned in different
messages.

On Mon, Apr 27, 2020 at 12:38:42PM +0200, Aleix Pol wrote:
> Does this mean that to clone it we'll have to go "git clone
> kde:games/knetwalk" or something along the lines?

Yes

[Rest of message is with sysadmin hat off and as a developer]

> If that's the case I'd much prefer if we didn't do this, at the moment
> it's already uncomfortable for me to remember the URL for some of the
> repos (e.g. is it sysadmin/ or not?), this will only increase the
> problem and I personally don't see the advantage.

I do agree that it maybe small inconvience, but let's be honest, most of
us have been using kdesrc-build or some kind of automated tooling for
building everything, apart from very rare case we never have to manually
clone any of KDE repository, at least it is true for me personally. I am
not sure about others.

[Very non-scientific test, I did "history | grep 'git clone kde:'" on my
machine and only instances were 4, websites/conf-kde-in,
kde-build-metadata, sysadmin/irc-notifications,
sysadmin/binary-factory-tooling, rest was automatically downloaded by
the kdesrc-build]

Anyway, getting back on topic, while this option gives some initial
setbacks in our own personal workflow, let's look at bigger picture.

Let's say I am the new developer who wants to contribute to frameworks.
One of reason we are switching to gitlab is better onboarding, current
state is that we have cgit.kde.org as a repository browser.

By default I open it, I get the sorting by name, first repository is
abakus. Commits as old as 14 years(!), after that some more mix of
unmaintained repositories and scrolling almost 1.5 page, I get greeted
with baloo, first framework in whole list. Let's just assume that name
based sorting is bad idea, and we sort by activity instead.

Here I get much better results, first framework is solid. But at same
time if I was looking for SDK, kdevelop would appear at 3rd scroll-page.
Here cgit is able to show many items in single scroll page, you can be
assured that on gitlab it would not show kdevelop in first 6-7 pages.

You might wonder why search does not help here? So problem with search
is you need to know what you are looking for[*], but drive-by
contributors, or users who are simply browsing our repositories won't
know what they are looking for, they are simply trying to find a thing
that interests them. Giving them categories/groups allows them to focus
on topic they like and they can contribute to.

> e.g. Is okular graphics or office? Is gwenview plasma or graphics? Is
> krita graphics or its own thing?

I agree that categories are something which we can improve upon, but
this is something which we can improve upon, rejecting idea of
categories just because 7-10 repos are at wrong place is ultimately not
going to do anything good.

> I really prefer when I don't have to guess this kind of things when
> fetching a repository.

[*] Ironically, in your case search would be helpful as you know you are
looking for knetwalk so you can just add it and search it

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20200427/2499aae3/attachment.sig>


More information about the kde-community mailing list