Information regarding upcoming Gitlab Migration

[Johan Ouwerkerk]

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

To some extent, yes, but some assumptions are baked in at a quite
fundamental level for e.g. kdesrc-build (if I understand the Perl
correctly):

- Uniqueness of project names. Cannot have two "documentation"
projects being advertised through kde-build-metadata
- There must be a single shared root prefix for all projects. This
prefix may be the empty string, but the point is that repo paths
advertised in kde-build-metadata must work from this single root
prefix

Any solution that wishes to preserve tooling must take these
fundamental constraints as given or else risk that you cannot move
until the whole world is fixed first.

I'm obviously biased as someone who invested some time and effort in
kdesrc-build, but the busfactor is a real concern here. E.g.: Michael
clearly just hasn't had the time lately to spend on kdesrc-build and I
don't think it's such a great idea for me to merge in major changes
without him reviewing it first.

>
> 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 think that this is a bit of a lost cause. I think there's going to
be some level of annoyance all around until the pain has finally died
away because everybody made the upgrade. We can have a script to help
with that but that will inherently assume quite a bit about how you
set up your projects manually to begin with and it will still piss off
a lot of people because we break their workflow no matter what.

The main problem is not technical here, the main problem is that
people who use that manual git clone workflow do so because they don't
want to use the layers of tooling. So adding layers of tooling to
"fix" the manual work flow is defeating the point, and therefore the
pain is here to stay I think.

At a fundamental the only way to avoid the pain is for the URLs to
continue to work somehow, but I gather that is a completely unfeasible
solution in terms of not driving sysadmin crazy. A fairly big one is
that the fingerprint of the host's SSH key will be different.

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

Yep. And I think for the exact same reason why a porting/transitioning
script is probably not going help all that much -- too much diff in
setup/config/versions/tools on the other end to deal with in a
reasonable script.

It's the main source of complexity in a tool like kdesrc-build and
that has lot's of Perl to hammer systems into submission... :)

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

I think we're in a situation that this migration is going to cause
pain for the human element no matter what. I also think that
ultimately from a technical pov it mostly doesn't really matter. As
someone else already mentioned: the Internet has search engines for
that.

What exact flavour of labeling/grouping/hierarchy we use, I think it
is mostly bikeshedding: I would predict that at first this is going to
be annoying for many if not nearly all contributors. After a while
we've all made the upgrade (just a matter of tweaking your
~/.gitconfig & git remote set-url per repo) and then it's business as
usual.

So yes this is about the social aspect. Personally I think the pain is
unavoidable for the individual contributor, but what seems to be
getting lost in this discussion is that there *is* also an amount of
pain that can be avoided. We can avoid pain for the sysadmin team by
choosing whatever is easiest to maintain long term here. We can avoid
pain for the maintainers of tooling by choosing whatever fits the
tooling most easily.

In particular we can avoid choosing an option that imposes additional
parallel sysadmin work indefinitely, like e.g. dedicated mirror
services to redirect stuff.

I would like to propose that the sysadmin team pick the layout that is
easiest to *implement*, which I suspect is also the most like what we
have now, and that we live with that. Unless there is a pressing need,
like real hard data that we're losing contributors because they can't
find our repos or a sysadmin burden that would be excessively higher
than otherwise... let's keep things as simple and straightforward for
syadmin and tooling maintainers to implement during the Gitlab
migration.

Let's worry about the perfect project layout once we've identified the
need. That way it's a lot easier to garner consensus for a practical
solution that isn't just a wishlist of all the features we would like
but which Gitlab may or may not have and which tooling is probably
completely unprepared for.

By all means disregard this stuff if the pressing need has already
been identified and I've either neglected to read e-mails properly or
wasn't aware for some other, possibly historical, reason.

Regards,

- Johan