Information regarding upcoming Gitlab Migration

[Ben Cooksley]

On Tue, Apr 28, 2020 at 11:09 PM Adriaan de Groot <groot at kde.org> wrote:
>
> 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`

Would some form of git alias/custom command script that works similar
to the following be suitable?

git kde-clone skrooge

That script would then search the appropriate groups (ignoring any
personal repositories including forks), find the necessary repository
and perform the clone as appropriate for you. Should it find multiple
results it would output it's results and then exit with a failure
(giving you names and the clone urls to pick from manually)

To handle the usecase of existing repositories, a similar "git
kde-pull" script could exist that would perform the necessary updates
to the pull url to translate them to the new Gitlab world (I'd prefer
doing it via a hook that you could set globally, but alas git doesn't
have a hook that runs anywhere in the fetch workflow)

>
> (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]

Cheers,
Ben