[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#845297: Migration to Salsa

Note: you can drop me in the CC, I'm following the bug report via the
debian-www mailing list.

El 29/04/18 a las 13:49, Alex Muntada escribió:

> Laura explained the translation workflow to me, and I thought
> that we wouldn't need to keep track of current CVS revisions
> because using the last commit id from a file and checking if a
> commit id is ancestor to another should be enough:
No, as you note below.
>   $ git log -1 --oneline english/license.wml
>   8e8136309fa use https for the link to www.spi-inc.org
>   $ git log -1 --oneline catalan/license.wml
>   8e8136309fa use https for the link to www.spi-inc.org
>   $ git merge-base --is-ancestor 8e8136309fa 8e8136309fa
>   $ echo $?
>   0
> However, I didn't take into account that sometimes there are
> changes applied to several files at the same time that have
> nothing to do with translations (as showed in the example above).
> Therefore, it seems that we'll need to translate CVS revisions to
> commit IDs at least once after the repository has been migrated
> finally to git and before any translation is performed.
This can be done in the meanwhile in the test_cvs2git repo:


I've just added there the file cvs-revisions which was generated by the
cvs2git script during the conversion.

> Since we can't be sure that people translating will stop during
> the migration, maybe we can add a kill-switch in the scripts so
> we can enable it before migrating and removing it to enable the
> translation work after everything is setup correctly in git.
> Something like this makes sense?
>   1. People translate on CVS.
>   2. Add a kill-switch to translations scripts.
>   3. Let people translate on CVS until migration date.
>   4. Enable kill-switch so people cannot translate.
>   5. Migrate repo to git.
>   6. Setup new workflow.
>   7. Make changes to translations docs.
>   8. Remove kill-switch.
>   9. Let people translate on git.
> Steps 5-7 should take the shortest time possible to avoid impact,
> of course.
> The kill-switch should be very easy to implement, e.g.:
>   my $kill_switch = 0;
>   die "Sorry! webwml migration in progress. Check the wiki.\n"
>       if $kill_switch;

I have no opinion on this. Frankly I don't know what to do if we cannot
get the new workflow working when Alioth is shutdown or the cvs service
Maybe we can try to setup a CVS repo in other place, or ask translators
to manually keep track of the translation-check line (even when the
dashboards are not working).

> Since I'm not very familiar with the translation workflow yet,
> I'd like to work on the Perl scripts that will deal with the
> files in git, etc. But I'm fine doing something else if someone
> prefers to do that.
I think the next steps are:
1.- Writing a script to get all the files with translation-check line to
be updated using the corresponding git hash. (This can be done in the
test_webwml_cvs2git repo, and when we do the authentic migration we run
it again)
2.- Get the copypage.pl and the smart_change.pl scripts working with git


Laura Arjona Reina

Reply to: