Information regarding upcoming Gitlab Migration

Tue Apr 28 12:08:33 BST 2020

There are a whole bunch of considerations and use-cases being discussed at 
once in this thread, and Leinir's post made me think a bit about different 
actors can interact with "the collection of repositories".

One actor is "tooling", as Albert has pointed out. Whatever the resulting 
structure is, it needs to be communicated to tool authors on time for tools to 
be updated, released, and rolled out for use. Tools mentioned so far:
 - kdesrc-build
 - i18n / scripty
 - release scripts
The tools don't have An Opinion regarding the layout, they just need to be 
updated.

A tool-like actor that I don't think has been mentioned so far is "existing 
checkouts". I have a src/kde with all the bits I've looked at "recently". 
There may even be some SVN checkouts there -- I'm willing to forget about 
those. Surprising and annoying me every time I update those sometime in the 
future is not good, but it's only going to annoy me once (per repo, so at most 
143 times for my clones).

I'd be *vaguely* worried about existing crontabs and automatic jobs that we've 
forgotten about, or which others have forgotten about. Those aren't fixable in 
the face of any changes to repositories, anyway.

Turning to human actors, who are the more interesting ones,

On 2020 prilula d. 28id 10:38:36 CEST Dan Leinir Turthra Jensen wrote:
> On Monday, 27 April 2020 21:25:09 BST Albert Astals Cid wrote:
> > El dilluns, 27 d’abril de 2020, a les 13:58:02 CEST, Bhushan Shah va
> > > 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?

> > > > 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.

Humans come in all shapes and sizes; here's one called Aleix who likes to 
remember the name of a thing, one single label. (Ironic: this particular Aleix 
is also labelled "Aleix Pol" and possibly "Aleix Pol Gonzales") The question 
I'd ask is "in what **context** do you need to remember the URL of a repo?" 
and for that matter: "why is 'knetwalk' an obvious thing to remember, and 
'games/knetwalk' not-obvious?"

Context here can mean many things. In this thread we've had mentioned:
 - people just browsing and wanting A Big List
   Here a hierarchical approach means more clicks and navigating a tree,
   rather than a flat structure.
 - people browsing for a known label
   Using ^F in a flat list or some search field (see also Ian Wadham's
   message just now) doesn't seem *that* different to me, although I've
   got to give ^F the benefit of speed and simplicity.
 - developers sharing a task list and reviews

.. probably more. Some of these roles have, depending on the chosen solution, 
problems that can be solved with a *technical* addition 
(bigflatlistofrepositories.kde.org .. or whatever), others are going to need a 
social solution.

Personally, I'm with Leinir here:

> Just adding my "i don't use kdesrc-build, and git clone kde:x everything
> myself" voice, here. 

Perhaps it's the "old school", but kdesrc-build doesn't do anything for me. 
I'm intermittently interested in the source of some random part of KDE -- 
generally because it's mentioned on IRC -- and then I need that source where I 
can look at it. Whether it's 'git clone' or 'kdesrc-build --just-the-source-
please' doesn't matter much.

If there's any compiling to be done, the less magic there is between me and 
the compile, the better.

So, yeah: `git clone kde:x` all the way, but I'm also not really invested in 
the structure of the label x, or the precise configuration of kde:.

> Now, if a simple(ish) script can be created to make
> something akin to the kde: rewriting work, even if what it really does is to
> search gitlab and create a clone with the appropriate command, i could deal
> with that, but having the ability to simply ask for the project name is
> more than a little useful.

I think we shouldn't underestimate how names are a social construct, though: 
the current flat structure comes after a structured SVN naming epoch. But I'd 
totes +1 a search-and-redirector, especially if it means I can write `git 
clone kde:peruse` and the resulting .git/config has followed the redirects and 
whatnot and ended up with `url: kdeforreal:audio/peruse`

(That said, bigflatlistofrepositories.kde.org .. or maybe call it cgit.kde.org 
.. could be a particular view onto gitlab which does flattening and search, 
but only if there's people around to create it and maintain it)

[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://mail.kde.org/pipermail/kde-core-devel/attachments/20200428/d17e61bf/attachment.sig>