Sysadmin Load Reduction: Code Related Services

[Ben Cooksley]

On Tue, Nov 19, 2019 at 6:53 AM Luigi Toscano <luigi.toscano at tiscali.it> wrote:
>
> Ben Cooksley ha scritto:
> > 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.
>
> Uhm, there is something, but it requires administrative access and I'm not
> sure whether it's available in the community edition:
>
> https://docs.gitlab.com/ee/api/custom_attributes.html

>From what I can tell this is available in the Community Edition.

It is however though only available via the API (and isn't shown
anywhere in the Gitlab UI), and of course can only be changed by an
administrator (ie. Sysadmin)

>
> >>>> 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.
>
> I understand that, but still it means that we can't flatten the translation
> repositories removing the namespaces.
>

Won't you still have issues though when repositories are renamed though?
Moves into Plasma and Frameworks from already reviewed repositories
are fairly uncommon from my recollection (about as common as
repository renames)

> Unless you use the future flattened translation repository as a way to see the
> existing names. In fact, it should be possible to periodically (every two
> days?) generate a list of all repository names; that should allow to check for
> duplicates. Maybe this could reduce the minimum amount of uncertainty when
> creating new repositories.
>
> --
> Luigi

Cheers,
Ben