Whenever I try to submit the updated Bulgarian translation I get the following error:
An error occurred during applying your action: The commit failed. The error was: “[Errno 1] Command: ‘[‘git’, ‘push’, ‘origin’, ‘glib-2-80’]’, Error: Warning: Permanently added ‘ssh.gitlab.gnome.org’ (ED25519) to the list of known hosts. remote: GitLab: You are not allowed to push code to protected branches on this project. To gitlab.gnome.org:GNOME/glib.git ! [remote rejected] glib-2-80 → glib-2-80 (pre-receive hook declined) error: failed to push some refs to ‘gitlab.gnome.org:GNOME/glib.git’ ”
This is expected: GLib moved to a workflow completely based on merge request this past development cycle. This means coordinators have to open a merge request to submit a translation update, as Damned Lies does not support doing that for you.
OK. I get your reasons and no workflow is cast in stone. Now that I have reviewed the previous discussion I see that there is short notice on the module though exactly as @afranke predicted - I missed the notice since I mainly work with the lower half of the page.
I will try to do pull requests in time in order to submit the translations.
Is there any particular reason glib has such a policy now? Should we expect more modules to move to more stringent updates?
Contributing via different means for some modules creates some friction. Before the move to gitlab I used to do git pushes for the translations and was a bit aghast when I had to move to the vertimus workflow. Now that I am accustomed to that - I can to pull requests.
Any advice who to ping for quicker review now that the release is imminent?
As Philip explained in the topic I linked: it’s because GLib sits at the very bottom of the stack, and it’s pretty much the best place to compromise a huge chunk of the free software ecosystem. Forcing everything to go through merge requests avoids code getting integrated in the main development branch without a proper review, and a chance of running the CI pipeline.
Ideally? Yes, we should really move the whole of GNOME to this workflow.
The xz security incident demonstrated that it’s incredibly easy to compromise projects without a very strong maintenance access policy, and the whole of the GNOME stack is constantly under-maintained.
The idea that a class of contributors gets to push directly to the main development branch and side step the whole system of checks in place to avoid breaking the stack is, quite honestly, a recipe for disaster.
That’s why the tooling should be modified to open a merge request instead of pushing directly to a branch. Ideally, no translator coordinator should have to open a merge request directly to a project.
You don’t need to ping anybody: all the people with the ability to review a merge request receive a notification when one is open.
What if damned-lies commited translations to a different branch that it is allowed to push? Then developers must occasionally merge that branch back, which is probably less work than having a MR for every update of every language.
Then the “translations” branch would need to be kept in sync and constantly rebased against the target branch; it’s considerably more work than a simple workflow like:
the coordinator presses the “submit” button on Damned Lies
DL creates a temporary branch from the current tip of the target branch
DL creates a commit with the changes on the temporary branch, pointing to the corresponding entry on the localisation team’s page so the project maintainer can verify the changes
DL pushes the branch and creates a merge request
the branch for the merge request gets deleted when the merge request is applied
The temporary branch can have a specific template, like i18n-${lang}-${branch}, so that multiple localisation teams can open their own MR.
Why would that be a problem? Maintainers merge small branches every day, multiple times.
To expand on that, from my point of view, merging small branches is very easy. Reviewing branches is less easy, and perhaps the work of reviewing somehow is getting conflated with the work of merging. Thankfully, the translations have already been reviewed within each translation team, before an MR is opened, so the maintainer literally just has to check the CI status and press the ‘merge’ button. It’s no work at all, and I’m very happy to do it in exchange for translations of the software!
Then the “translations” branch would need to be kept in sync and constantly rebased against the target branch; it’s considerably more work than a simple workflow like: […]
That would be quite fine. As far as I understand, the creation of the MR is currently still manual though, so the easier workflow does not currently exist (hence this thread).
This means someone on every translation team needs to know git, and learn to clone and click around (and register a public ssh key?) in order to finish translating glib. Which is a whole order of magnitude more overall trouble than if D-L followed a special translation branch and maintainers occasionally synced with that, and achieving this requires no change of D-L.
This then requires maintainers of Glib (few people) to know about the ordeal and be bothered a little bit (so I understand), whereas right now it requires many people to know about the issue and do a lot of manual work that they don’t know well how to do. Remember translators often want to upload 20+ translations at a time, so being able to treat them the same has a very high value for us.
I am not sure why the translations branch would need to be rebased.
D-L would follow the translations branch the same way it follows any other branch, and maintainers could merge to/from it according to any criteria, as long as they (kindly) remember to, which I hope is good enough as long as it is only this one project that follows a special workflow.
Who is going to rebase the translations branch when new translatable files are added, or new localisations are available? Merging main back into a translation branch is going to make history a mess of merge forwards and backwards.
If the GLib maintainers are supposed to do that, then every localisation team will need to learn Git to delete the local branch and pull again from the remote—and somebody will inevitably forget, which will result in a mess when it gets pushed again. Incidentally, that cannot be automated by Vertimus anyway, so the “nothing changes in Vertimus” bit is not really true.
Finally, this doesn’t solve the issue of fixing/adding/changing translations in stable branches, unless you create a separate branch for every stable branch, and then merge backward and forward them separately.
Sorry, what I intended to say was that the workflow based on automatic MR creation was fine, but I delimited the block quote badly so that wasn’t clear.
However I still fail to understand how two coexisting branches occasionally being merged back and forth could be prohibitively messy given the trouble it saves elsewhere.
If the GLib maintainers are supposed to do that, then every localisation team will need to learn Git to delete the local branch and pull again from the remote
I don’t quite understand. D-L would track the translations branch instead of main. AFAIK that’s robust wrt. new commits that come into that branch via gitlab, and it’s robust wrt. commits from D-L, so I don’t understand these differences you mention. But I can follow that managing translation branches for releases too would indeed add more work, should they also be supported that way.
I’m quite late in this flow but want to answer on a few points.
Yes, I agree with this, but we also have ways to ensure the only data pushed to the main branch are PO files and located only in the po directory. I remember we had some try/error tests with Andrea a year ago I would say because he designed pre-receive hooks to strengthen the security of Damned Lies pushes.
Anyway, a flaw in Damned Lies or a comprimission of the host system cannot be excluded, even though we do our best to avoid them.
This is true, a little help would be appreciated, if someone reads this message and is fluent in Python. We also already have a dependency with GitLab so this is not a big deal. We will be able to track which projects use a Merge Request worklow and for the translators/coordinators, it’s nothing else than pushing a button like it is right now. The responsability to merge the translation will be in the developer’s hands.
My concern is to maintain the process for the translators as simple as it is now. The choice of using a merge request based worklflow is the developer’s responsability, and it’s, according to me, not a big deal to review translation merge requests from time to time, with more work 4 weeks in a year.
Also, there are things to do with GitLab CI to maybe check things automatically and - maybe - automatically merge these Merge Requests.
The rationale is not a concern that damned-lies or its translations user may be an attack vector. It’s the concern that (roughly) any GNOME member with push access to any repository can push to another repository (such as GLib), bypassing review and CI. By relaxing the repository permissions for GLib to allow the translations user to push (vetted) translation changes, we open the doors to other users pushing unvetted changes.
The way that damned-lies works is unfortunate collateral damage here. The change was not made specifically because of a problem with the old damned-lies workflow or how it puts together or checks translation commits.
Hope these will be merged before the packaging of new versions.
On a side note - can someone advise me how to generate the pot file within a branch? I am not sure whether the glib-2-82 translation will reach the main branch and want to prepare a merge request just in case. I need to generate the pot file in order to do the update.
No, you don’t. You if you want to merge your stable branch work with the development branch update, you just need to upload the stable branch translation in a development branch workflow and Damned Lies will do the merge for you.
I am really sorry. I do not understand what your suggestion is and I really miss the reason to not point me to documentation how one generates pot file using (or not) the meson build system.
I am neither a committer for glib nor have any rights to configure Damned Lies. I just want to be able whenever I checkout the repo of glib or another module - to generate the pot-file.
I only tried instructions here Localisation coupled with what I found in CONTRIBUTING.md · main · GNOME / GLib · GitLab but probably I lack enough knowledge. Pointers very welcome.
.