Re: Namespaces for a few repositories on invent (was Re: Migration to Gitlab -- Update)
On Mon, May 11, 2020 at 1:40 AM Bhushan Shah wrote: > > On Sun, May 10, 2020 at 02:54:35PM +0200, Luigi Toscano wrote: > > I went through the list of the new structure, and I can only imagine the > > work > > needed to reshuffle > > Am I still on time to propose some fine tuning? > > Sure, feel free to make suggestions on final place of items on structure > > > == Proposed moves: > > kio-upnp-ms: applications -> network > > mark: applications -> education > > kdecoration-viewer: applications -> sdk > > kolorfill: applications -> games > > klook: applications -> graphics > > peruse: applications -> graphics > > done! > > > == A bit more open questions about: > > libkdegameai: libraries -> games (like libkdegames) > > done! > > > macports-kde: sdk -> packaging (not 100% sure) > > this kinda looks unmaintained to me, last commit is in 2014/15, and > otherwise seems untouched, should unmaintained be better place for this? > > > kup: system -> utilities (like kbackup!) > > Good that we have backup for backup applications , anyway > would it make sense to move this otherway around? (kbackup -> system?) I > kind of consider backup "system"/"core" stuff... > > > mangonel seems a bit of place too in system (which has mostly lower-level > > configuration stuff), maybe utilities? > > done! > > > > > == There are a few second-level namespaces, are we going to keep them? I > > can see: > > Thanks for noticing the second-level namespaces, I completely overlooked > it seems > > > * graphics/digikam/ > > - it only contains digikam-doc, which should maybe just go under graphics/ > > * graphics/libs > > - a few libraries which be moved under graphics/ directly (or libraries, > > but > > they are graphics-related) > > * network/telepathy > > - only telepathy-logger-qt, it could go under network/ directly > > I've flattened these ones. > > > * others/kde-edu-courses/ > > - why not directly under education ? > > I guess it can go into education, but looking at content I am more > inclined to think that this belongs into unmaintained, aren't those > applications instead using the GHNS? I am not even sure where this > content is hosted if at all (seems to have .php files in there) I suspect we're going to find one of two things out here: 1) That these data files are currently not in use 2) They're source files for content currently on files.kde.org/edu.kde.org (which has some Edu applications pulling new content directly from it, using one of the pre-OCS variants of GHNS) > > > Also unmaintained/ contains two of them (necessitas, strigi), but it doesn't > > matter much I guess. > > I've flattened necessitas and strigi. > > > Ciao! > > -- > > Luigi Cheers, Ben > > -- > Bhushan Shah > http://blog.bshah.in > IRC Nick : bshah on Freenode > GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
Re: Namespaces for a few repositories on invent (was Re: Migration to Gitlab -- Update)
On Sun, May 10, 2020 at 02:54:35PM +0200, Luigi Toscano wrote: > I went through the list of the new structure, and I can only imagine the work > needed to reshuffle > Am I still on time to propose some fine tuning? Sure, feel free to make suggestions on final place of items on structure > == Proposed moves: > kio-upnp-ms: applications -> network > mark: applications -> education > kdecoration-viewer: applications -> sdk > kolorfill: applications -> games > klook: applications -> graphics > peruse: applications -> graphics done! > == A bit more open questions about: > libkdegameai: libraries -> games (like libkdegames) done! > macports-kde: sdk -> packaging (not 100% sure) this kinda looks unmaintained to me, last commit is in 2014/15, and otherwise seems untouched, should unmaintained be better place for this? > kup: system -> utilities (like kbackup!) Good that we have backup for backup applications , anyway would it make sense to move this otherway around? (kbackup -> system?) I kind of consider backup "system"/"core" stuff... > mangonel seems a bit of place too in system (which has mostly lower-level > configuration stuff), maybe utilities? done! > > == There are a few second-level namespaces, are we going to keep them? I can > see: Thanks for noticing the second-level namespaces, I completely overlooked it seems > * graphics/digikam/ > - it only contains digikam-doc, which should maybe just go under graphics/ > * graphics/libs > - a few libraries which be moved under graphics/ directly (or libraries, but > they are graphics-related) > * network/telepathy > - only telepathy-logger-qt, it could go under network/ directly I've flattened these ones. > * others/kde-edu-courses/ > - why not directly under education ? I guess it can go into education, but looking at content I am more inclined to think that this belongs into unmaintained, aren't those applications instead using the GHNS? I am not even sure where this content is hosted if at all (seems to have .php files in there) > Also unmaintained/ contains two of them (necessitas, strigi), but it doesn't > matter much I guess. I've flattened necessitas and strigi. > Ciao! > -- > Luigi -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Namespaces for a few repositories on invent (was Re: Migration to Gitlab -- Update)
Ben Cooksley ha scritto: > -- Structure -- > > Following lengthy discussion in the original thread, it was agreed > that the original sysadmin proposal of various categories would be > implemented, with repositories organised according to that structure. > > You can find this documented at > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent I went through the list of the new structure, and I can only imagine the work needed to reshuffle Am I still on time to propose some fine tuning? == Proposed moves: kio-upnp-ms: applications -> network mark: applications -> education kdecoration-viewer: applications -> sdk kolorfill: applications -> games klook: applications -> graphics peruse: applications -> graphics == A bit more open questions about: libkdegameai: libraries -> games (like libkdegames) macports-kde: sdk -> packaging (not 100% sure) kup: system -> utilities (like kbackup!) mangonel seems a bit of place too in system (which has mostly lower-level configuration stuff), maybe utilities? == There are a few second-level namespaces, are we going to keep them? I can see: * graphics/digikam/ - it only contains digikam-doc, which should maybe just go under graphics/ * graphics/libs - a few libraries which be moved under graphics/ directly (or libraries, but they are graphics-related) * network/telepathy - only telepathy-logger-qt, it could go under network/ directly * others/kde-edu-courses/ - why not directly under education ? Also unmaintained/ contains two of them (necessitas, strigi), but it doesn't matter much I guess. Ciao! -- Luigi
Re: Migration to Gitlab -- Update
Hello, On Sun, May 10, 2020 at 01:20:23PM +0200, Johan Ouwerkerk wrote: > On Sun, May 10, 2020 at 9:49 AM Ben Cooksley wrote: > > > > Following lengthy discussion in the original thread, it was agreed > > that the original sysadmin proposal of various categories would be > > implemented, with repositories organised according to that structure. > > > > You can find this documented at > > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent > > > > -- Conclusion -- > > > > Should anyone have any questions regarding the above, please let us know! > > > > Just to confirm, by documented you mean that the layout of the various > `metadata.yaml` files indicates what the layout of the repositories > will become? Becuase looking at Keysmith for example, it seems that > the metadata repopath has not been updated yet: > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent/utilities/keysmith/metadata.yaml?h=bshah/invent Yes, that is correct, currently directory structure is what will be final structure, repopath and other bits will migrated all at once when actual move happens -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D signature.asc Description: PGP signature
Re: Migration to Gitlab -- Update
On Sun, May 10, 2020 at 9:49 AM Ben Cooksley wrote: > > Following lengthy discussion in the original thread, it was agreed > that the original sysadmin proposal of various categories would be > implemented, with repositories organised according to that structure. > > You can find this documented at > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent > > -- Conclusion -- > > Should anyone have any questions regarding the above, please let us know! > Just to confirm, by documented you mean that the layout of the various `metadata.yaml` files indicates what the layout of the repositories will become? Becuase looking at Keysmith for example, it seems that the metadata repopath has not been updated yet: https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent/utilities/keysmith/metadata.yaml?h=bshah/invent Regards, - Johan
Migration to Gitlab -- Update
Good morning all,
We recently had a rather lengthy discussion concerning the final
manner in which Gitlab will be deployed for KDE.
To ensure everything is clear, we'd like to summarise that and present
the final structure which has been agreed upon, along with details on
tools that will be able to assist Developers with the migration and
working with Gitlab in the long term.
-- 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.
When this transition commences, git.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.
-- Structure --
Following lengthy discussion in the original thread, it was agreed
that the original sysadmin proposal of various categories would be
implemented, with repositories organised according to that structure.
You can find this documented at
https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
-- 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
" to clone a repository.
In the majority (95%) of cases we expect "" 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
closer to the migration commencing.
-- 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!
Thanks,
Ben Cooksley
KDE Sysadmin
