On Fri, May 1, 2020 at 5:44 AM Aleix Pol <aleix...@kde.org> wrote: > > On Wed, Apr 29, 2020 at 12:25 PM Bhushan Shah <bs...@kde.org> wrote: > > > > Good afternoon, > > > > [Please keep sysad...@kde.org list or bs...@kde.org in the CC for > > replies] > > > > I want to clarify some bits for which we have gotten a questions about, > > > > - Non unique naming: There's some teams which prefer if we dropped the > > namespace- part from their name which we have added. While currently > > this does not result in the naming conflict right away, we realize > > this will cause it at one point, for example, > > > > maui-dialer -> maui/dialer > > plasma-dialer -> plasma-mobile/dialer > > > > To minimize the impact of the Gitlab move we won't be doing such > > renames which introduce non-unique names right away. But we would > > prefer if the existing tooling or infrastructure is ready for this > > kind of cases at later point. Only way to enforce non-unique naming is > > one big KDE/ subgroup which we want to avoid. > > > > Current naming in the repo-metadata branch[1] I've pointed does not > > reflect those renames, as we are not planning to do those renames > > right away during gitlab move, but at a later stage. > > We have made a big fuss in the past about having different projects > that do the same thing and now we'll have that but also we'll have > several projects with the same name? > It really feels off to me and I wonder if this is related to the move to > gitlab. > > > - Existing configurations: we want to reduce impact on existing release > > schedule, and existing developer workflow, therefore we will continue > > to privide the existing anongit.kde.org and git.kde.org (although this > > will be read-only) with current flat structuring for 3 weeks after > > actual migration, which will keep the existing scripts/clones working > > enough to give developers time to change to the new structure. > > > > We will also try to provide a script which allows you to migrate your > > existing clones to new repo paths and as mentioned by Ben in other > > message, potentially a git-kde script which would allow you to clone > > individual repository without knowing it's namespace (provided that > > there is no conflict of it's name). like "git kde karchive" > > IMHO needing tools ad-hoc to KDE development can be a barrier of entrance. > I feel like these things make us look distant, it's important that > people's skills translate automatically when they want to get started.
These tools are being provided as migration assistants. New contributors won't have a problem, as they'll be used to finding the project at games/knetwalk (to use an example). > > > - Translations: we will co-ordinate with the translations team to let > > them adapt their tooling to updated structure as this requires changes > > on their side how translations are stored in svn repository > > Thanks! :) Cheers, Ben