Sysadmin Load Reduction: Code Related Services

Luigi Toscano luigi.toscano at
Mon Nov 18 17:53:23 GMT 2019

Ben Cooksley ha scritto:
> On Tue, Nov 19, 2019 at 6:20 AM Luigi Toscano <luigi.toscano at> wrote:
>> Ben Cooksley ha scritto:
>>> On Tue, Nov 19, 2019 at 1:34 AM Harald Sitter <sitter at> wrote:
>>>> On Sat, Nov 16, 2019 at 9:40 PM Ben Cooksley <bcooksley at> wrote:
>>>>> On Sun, Nov 17, 2019 at 5:19 AM Carl Schwan <carl at> wrote:
>>>>>> Hi all,
>>>>> Hi Carl,
>>>>>> Can the gitlab api be of useful in the future?
>>>>>> e.g
>>>>> 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:

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

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.


More information about the kde-community mailing list