Sysadmin Load Reduction: Code Related Services

[Ben Cooksley]

On Tue, Nov 19, 2019 at 6:20 AM Luigi Toscano <luigi.toscano at tiscali.it> wrote:
>
> Ben Cooksley ha scritto:
> > On Tue, Nov 19, 2019 at 1:34 AM Harald Sitter <sitter at kde.org> wrote:
> >>
> >> On Sat, Nov 16, 2019 at 9:40 PM Ben Cooksley <bcooksley at kde.org> wrote:
> >>>
> >>> On Sun, Nov 17, 2019 at 5:19 AM Carl Schwan <carl at carlschwan.eu> wrote:
> >>>>
> >>>> Hi all,
> >>>
> >>> Hi Carl,
> >>>
> >>>>
> >>>> Can the gitlab api be of useful in the future?
> >>>>
> >>>> e.g https://invent.kde.org/api/v4/groups/7
> >>>
> >>> While for many purposes Gitlab's API wil be perfectly fine, it doesn't
> >>> provide us with the i18n branch information which some users will
> >>> require.
> >>
> >> Something to perhaps consider at this point is to revise the
> >> repo-metadata format in general and offload data to gitlab?
> >
> > Once we have transitioned repository hosting and code review to
> > Gitlab, restructuring how repo-metadata works was one of the items I
> > wanted to look into (if anything because i'd like to automate updates
> > to repo-metadata so we don't have to create them on Gitlab and then
> > register them in repo-metadata as a second separate step)
>
> Uhm, does gitlab allow to define custom properties? That may solve the
> problem. (but probably it doesn't, or it would have already proposed.)

It doesn't allow us to define custom properties i'm afraid.

>
> >> project, e.g. projects/kde/workspace/sddm-kcm.yaml or perhaps even
> >> more ideally projects/sddm-kcm.yaml (because the current dir structure
> >> duplicates information encoded in repopath; so I would think either we
> >> should drop the property or flatten projects/).
> >
> > We should mirror the repopath as in the Gitlab world it will be
> > possible for us to have two repositories that have the same name, just
> > in different parts of the tree.
>
> Can we keep the rule of having unique repository names, even if we could use
> them? One of the plans to reduce the moves around for translations is to
> flatten the structure without namespaces. Allowing duplicates would make this
> impossible and introduce more complication (and it may complicate our life as
> well if a duplicated repository ever moves to plasma or to frameworks).

It'll be hard to tell whether a name is unique or not when creating a
repository unfortunately.
For the most part I do not expect collisions to occur though and we
certainly won't aim to create duplicate names.

Note that I do not expect repositories to ever really move beyond the
module they're created in (as a multimedia application will always be
a multimedia application for instance).

The release component (playground, extragear, release service) will
not be encoded in the path which should greatly minimize the number of
moves.
Plasma and Frameworks will be two exceptions there, but that is
because they're both modules and release units.

>
> --
> Luigi

Cheers,
Ben