Ben Cooksley ha scritto: > On Tue, Nov 19, 2019 at 6:20 AM Luigi Toscano <luigi.tosc...@tiscali.it> > wrote: >> >> Ben Cooksley ha scritto: >>> On Tue, Nov 19, 2019 at 1:34 AM Harald Sitter <sit...@kde.org> wrote: >>>> >>>> On Sat, Nov 16, 2019 at 9:40 PM Ben Cooksley <bcooks...@kde.org> wrote: >>>>> >>>>> On Sun, Nov 17, 2019 at 5:19 AM Carl Schwan <c...@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
