Hi Andika,
Yes, it seems that my commit broke some continuous build in Gitlab, so Michael reverted it. To avoid wasting time, could someone indicate us how to proceed?
To avoid wasting time, you should open a merge request against the project, instead of pushing directly to the main or stable branches. Otherwise, any breakage will be uncaught, and somebody will have to revert the commit.
For instance:
the change was pushed to Git and the CI pipeline broke because of a missing file:
If you had opened a merge request, instead, you would have noticed the missing file, and you could have amended the commit to your merge request branch.
Another example:
```
Again, opening a merge request would have found this issue before it hit the main development branch.
That commit (and the similar one in iagno) ought to be reversed as well, but at least the games are not part of core GNOME.
I don't mind to do it again (even adding the PO files in the commit) but I think that's not the proper way to do things.
Micheal is part of the release team; the release team is empowered to revert any commit that breaks the continuous integration build of GNOME, because that continuous integration is what generates:
- the nightly and stable application flatpaks
- the nightly and stable run times (also used for CI in various applications)
- the release VM builds
Breaking those means stalling the work of a lot of other projects.
Maybe someone could review DL's way to add new languages for help or, at least, grant team coordinators commit access to be able to solve this issues without breaking anything (nor depend on other people)
The appropriate way to commit changes is to have them run through the per-module continuous integration. If that passes, but things still break when we try to build the whole of GNOME core modules and applications, then we can discuss about that; but if you work around the measures we have in place *precisely* to catch these issues, then I'm afraid you're going to get more commits reverted. Or the release team might simply decide to revoke direct commit access to localisation team coordinators, and avoid reverting broken commits.
Ciao,
Emmanuele.
El mié., 4 nov. 2020 a las 13:20, Andika Triwidada (<
andika gmail com>) escribió:
Hi Daniel,
Thanks for your help. It seems that Michael Catanzaro revert all your modifications before I have chance to commit files. Please advice how to proceed?
Hi Andika,
I've added 'id' language to those modules. Please check if you can now commit translations for them using DL.
Let us know if you have any problem with it.
Regards
El dom., 1 nov. 2020 a las 2:48, Andika Triwidada (<
andika gmail com>) escribió:
Hello, I think this problem is well known for Documentation translation. If a language has not been translated, required directory help/language-code will not be there, and DL can not automatically create it. Then in turn, DL will not present "submit to repository" on pull down options.
Currently, we face this problem on these modules:
We would be very grateful if someone who has git write access to those modules can help us create those prerequisite directories and language entry in config files.
Regards,
Andika
gnome-i18n mailing list
gnome-i18n gnome org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
