Sysadmin Load Reduction: Code Related Services

[Luigi Toscano]

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

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

-- 
Luigi