Notice regarding upcoming gitlab migration

[Jack]

The forwarded note includes "
> To assist developers with the transition process, Sysadmin has  
> developed a utility ('git kpull') which once setup on a developers  
> system will automatically migrate any git.kde.org/anongit.kde.org to  
> the new structure automatically, before proceeding with a regular  
> 'git pull' when run in a Git repository.
Does anyone know how to get this setup on a developers system?  As I  
understand it, that really needs to be run within the two weeks after  
the migration to make the transition as easy as possible.

Thanks for any pointers.

Jack

On 2020.05.15 13:38, Thomas Baumgart wrote:
> Hi all,
> 
> as already announced, the migration to the KDE Gitlab infrastructure
> will happen this weekend.  Please take a minute and read the
> below information.
> 
> Regards
> 
> Thomas
> 
> ----------  Forwarded Message  ----------
> 
> Subject: Notice regarding upcoming gitlab migration
> Date: Freitag, 15. Mai 2020, 11:18:48 CEST
> From: Bhushan Shah <bshah at mykolab.com>
> To: kde-cvs-announce at kde.org, sysadmin at kde.org
> 
> Good afternoon!
> 
> This email is regarding the upcoming gitlab migration which sysadmins
> are planning to action this weekend.
> 
> -- Timeline --
> 
> At the moment we are intending to perform a bulk migration of all
> repositories from git.kde.org to invent.kde.org on 16 May 2020.
> 
> We plan to start this migration from saturday 03:00 UTC / 05:00 CEST.
> When this transition commences, git.kde.org and invent.kde.org will
> be made read-only.
> 
> Following this, the current system will be kept active in a read-only
> configuration for two weeks (until 30 May 2020) to allow for everyone
> to smoothly transition local clones and any automated systems over to
> the new Gitlab setup.
> 
> -- New releases --
> 
> Since this migration also requires changes on the translation
> infrastructure side, maintainers should not make new releases starting
> from today until migration is completed on both source hosting and
> translations infrastructure side.
> 
> At this time we anticipate that complete update of the other  
> associated
> infrastructure (including translations) may take up to a week and
> therefore recommend that projects reschedule any releases (apart from
> security fixes) to take place after 25 May 2020.
> 
> -- Tooling --
> 
> To assist developers with the transition process, Sysadmin has
> developed a utility ('git kpull') which once setup on a developers
> system will automatically migrate any git.kde.org/anongit.kde.org to
> the new structure automatically, before proceeding with a regular 'git
> pull' when run in a Git repository.
> 
> Additionally, as some developers had concerns regarding locating
> repositories, an additional utility known as 'git kclone' is being
> shipped as well. This will allow developers to run "git kclone
> <identifier>" to clone a repository.
> 
> In the majority (95%) of cases we expect "<identifier>" to be
> identical to the repository name (frameworks/kcoreaddons being
> kcoreaddons for instance), however where the name is common (such as
> 'dialer') then it will be prefixed by the name of the originating
> project (so maui/dialer would have an identifier of maui-dialer)
> following the convention we use at the moment for projects wishing to
> have a repository using a common name.
> 
> It should be noted that 'git kclone' is also able to perform bulk
> clones based on wildcard patterns (which you could use to clone all
> frameworks by running "git kclone frameworks/*" for example)
> 
> Instructions on how to set this up on your system will be sent out
> after the migration.
> 
> -- Continuous Integration --
> 
> Following the migration, we will continue to use our existing Jenkins
> based setup. Migration to using Gitlab for CI purposes will take place
> at a later date once the necessary adjustments to the CI
> infrastructure have been completed.
> 
> During the intervening time CI capability will be available on Gitlab
> for evaluation and testing purposes only.
> 
> This is not supported as a standard production level service by
> Sysadmin and therefore should not be relied upon by projects as part
> of their workflow.
> 
> -- Tasks --
> 
> Tasks will be migrated from Phabricator at a future point in time.
> These will remain on Phabricator for the time being and are not
> affected by the migration.
> 
> Projects wishing to start entirely new boards and not needing to work
> with  existing boards on Phabricator should feel free to begin making
> use of their new Gitlab boards following the migration.
> 
> -- Migration from Phabricator --
> 
> Existing code reviews will not be migrated from Phabricator as part of
> this migration process and will need to be completed using the usual
> process on Phabricator. It is expected that following the completion
> of the migration of code hosting that no further new reviews will be
> started on Phabricator.
> 
> Please note that because Phabricator is dependent on the existing
> git.kde.org/anongit.kde.org setup, once those are shutdown the hooks
> that automatically close reviews will no longer operate.
> 
> Tasks will be migrated in a future step, following which Phabricator
> will be shutdown. Based on initial testing we expect to be able to
> provide a static copy of Phabricator (for reviews only as tasks will
> have been migrated at this stage) for long term archival purposes.
> 
> -- Conclusion --
> 
> Should anyone have any questions regarding the above, please let us  
> know
> at sysadmin at kde.org
> 
> --
> Bhushan Shah
> KDE Sysadmin team
> IRC Nick : bshah on Freenode
> GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC  
> E11D
> 
> -----------------------------------------
> --
> 
> Regards
> 
> Thomas Baumgart
> 
> https://www.signal.org/       Signal, the better WhatsApp
> -------------------------------------------------------------
> To be or not to be that is the question. - Any programmer
> knows the answer: $2B | !$2B is $FF.
> -------------------------------------------------------------
>