ping?

ping?

@nalvarez We need you here man, i've no idea what to do with this

@bcooksley do you know of anyone else besides Nicolas that knows enough to review this kind of stuff?

I'm afraid I know of nobody else who understands these in detail.

My best recommendation here would be to examine the results of the whole process, and if it looks correct in terms of grabbing history vs. "svn log" then we should go for it.

Sounds reasonable to me, is this something that Alexander can run himself or you have to run it for him?

As I mentioned in https://phabricator.kde.org/T4803#213612 , I ran svn2git with these rules in December to produce https://github.com/aspotashev/converted-scripty-v2 for evaluation.

It's probably worth re-running now so grab any changes since then, after that we can set the repository up on invent.kde.org/git.kde.org.
If you'd like to use Gitlab immediately, please create the repository there as it will be easier to move it to it's final home.

In keeping with how we do Neon stuff, this will probably end up at sysadmin/scripty (with you given access of course) if that is okay with you.

In D25929#636568, @bcooksley wrote:

this will probably end up at sysadmin/scripty (with you given access of course) if that is okay with you.

I don't understand why this needs to be "more protected" (i.e. sysadmin/) in invent than in svn

Because it should be protected, as this is code that executes automatically on our infrastructure and only a handful of people need to make changes to this code.
Additionally to that, this code has access to a bot account that has greater privileges than a normal developer account.

In D25929#636572, @bcooksley wrote:

Because it should be protected, as this is code that executes automatically on our infrastructure and only a handful of people need to make changes to this code.
Additionally to that, this code has access to a bot account that has greater privileges than a normal developer account.

People that commited there in the last 1000 revisions

aacid
ltoscano
lueck
aspotashev
jriddell
arichardson
cfeck
yurchor
dfaure
adrianchavesfernandez
kossebau
pino

You should go to the doctor if your hand has 12 fingers

I object to this being more protected than it is right now, not that it matters anything but i object

I think I need to explicitly specify license for these new files. Not sure which license to choose, by default I would pick MIT because it's one of the most permissive ones.

Do you think it's OK to add license files into the kde-ruleset.git/l10n/ subdirectory only and leave the other files in the repo without license specified?

I think I'll print this thread as more evidence of ADHD to my doctor (I forgot about each reminder shortly after receiving it).

In D25929#635473, @aacid wrote:

@bcooksley do you know of anyone else besides Nicolas that knows enough to review this kind of stuff?

Yes hello, last night I downloaded the entire SVN repository to run the conversion. My ISP won't be happy. Will see what I can do with that today.

Almost one month ping

I think you should commit this as-is and we can do changes later directly in kde-ruleset.

In early history, the scripts were directly at the root of SVN trunk/kde-i18n/, so the conversion rules import all of kde-i18n/ *except* translations. In r414920, scripts were moved from kde-i18n/ to kde-i18n/scripts/.

These rules are incidentally importing COPYING, INSTALL, README, subdirs, teamnames, debian/, and some .po files, which were in the kde-i18n/ root before the move but aren't in scripts/. They certainly shouldn't be present in git after r414920 (currently they are, I'll fix that). But should they be present in git in the pre-move history, or should they be removed like the translation dirs are? I think they should be removed, but I'm not sure what to do about COPYING.

There's also the issue of current versions of l10n having no COPYING (no license info for scripts or translations) but that's not for me to fix :) It will have to be added either to SVN scripts/ now, or to git after the conversion. (Orrrr I could do evil anachronistic edits and add a COPYING to commits that never had one in SVN...)

In D25929#656114, @nalvarez wrote:

I think you should commit this as-is and we can do changes later directly in kde-ruleset.

Did it a few minutes ago with "arc patch D25929 && arc land arcpatch-D25929".

These rules are incidentally importing COPYING, INSTALL, README, subdirs, teamnames, debian/, and some .po files, which were in the kde-i18n/ root before the move but aren't in scripts/. They certainly shouldn't be present in git after r414920 (currently they are, I'll fix that). But should they be present in git in the pre-move history, or should they be removed like the translation dirs are? I think they should be removed, but I'm not sure what to do about COPYING.

I think it would be fine to fix in new commits and keep the history as is.

There's also the issue of current versions of l10n having no COPYING (no license info for scripts or translations) but that's not for me to fix :) It will have to be added either to SVN scripts/ now, or to git after the conversion. (Orrrr I could do evil anachronistic edits and add a COPYING to commits that never had one in SVN...)

In other KDE code repositories nobody is trying to rewrite the whole history, developers just change licenses headers and/or add COPYING files in new Git commits. And I don't think you can add COPYING to the old revisions before receiving permission to relicense from all the past contributors.

FWIW, kde-ruleset.git is also missing COPYING files and license headers.