Re: Problems commiting damned-lies package
- From: Daniel Mustieles García <daniel mustieles gmail com>
- To: Emmanuele Bassi <ebassi gmail com>
- Cc: Matej Urban <matej urban gmail com>, Carlos Soriano <csoriano gnome org>, GNOME i18n list <gnome-i18n gnome org>
- Subject: Re: Problems commiting damned-lies package
- Date: Mon, 22 Jun 2020 13:29:08 +0200
Again this is David against Goliat, and I'm tired of fighting...
I have no skills to improve DL, I only developed a script and made it available to everyone who wants use/read/whatever with it. If if can be a start point to improve DL great! but I'm not going to keep fighting against something that I cannot change.
I don't know which features Gitlab offers, sorry if I still think like in 2009. Maybe someone with better knowledge than me could show us the proper way or even help with a tool or a patch for DL. I made a bash script because I don't know Python. I'm a translator, not a developer, sorry.
I'm leaving here the discussion/thread, but thanks for your comments and your point of view.
Regards
El lun., 22 jun. 2020 a las 13:13, Emmanuele Bassi (<
ebassi gmail com>) escribió:
Hi Emmanuele,
Just a quick question: which is the difference between commiting directly into Git and commiting through DL?
DL can, at least, centralise the place where tests are executed to ensure that things don't utterly break. Of course, it's not really a solution: now that we use GitLab, we already have a centralised place to run builds and tests.
The fact that DL pushes to the main development branch *also* irks me to no end; at least DL acts as a filter, and ensures that *some* validation is actually performed.
PO file checks are the same (or should be), so commiting directly is not more dangerous than using DL. the same checks DL makes into a PO file are done in my script, for example. If a PO file breaks your module's building it doesn't matter if I committed it directly into git or usind DL.
Your script is your own script. Unless everybody uses your script—in which case, it should be moved to a remote environment so that people don't have to have Git access—then it's pointless.
But my point is that I don't want translators to have "scripts". I don't want translators to do anything more than translating. We have infrastructure to verify that things pushed to the repository do not break the main development branch of a project: it's called the continuous integration pipeline, and we have a process for it to run on topic branches. We even have API in GitLab to:
- automatically create a merge request
- set the target branch
- automatically merge code once the CI pipeline passes
- automatically remove the source branch when merged
I do hope your script uses it. I'd hope for DL to do the same.
Also, note that not all translators will have commit rights: only a reduced group of them. Breaking things in git is possible for both translators and developers: that's one of the reasons we use Git, to be able to revert commits and even revoke commit access to a person who breaks things several times.
I don't want to manually revert stuff that's broken and got pushed to the main development branch. I don't want broken stuff to land *in the first place*.
Git having easy revert operations is good for things that are *discovered* to be broken later on; that doesn't mean people should push broken localisations of the application documentation, with broken tags that do not close properly, and get only discovered when trying to release something. That's sacrificing maintenance time—*my* time—because you want to save your time. Your time isn't any more precious than mine.
Additionally, we have whole run times that get built every day; if a translation breaks a library, or an application, the whole pipeline gets stalled until the problem is solved. The amount of lost person time is staggering.
This is not a question of being 20 years o 20 days in the project: this is a question of helping us with our work, because that work is as valid as yours, and we all are responsible with it. pre-commit hooks can be implemented (they are already, but we could study if are enough or not) to avoid breaking things, but its really discouraging to follow DL's workflow to commit a 1-modified string in a PO file. Multiply it by 20...
If people spent time improving Damned Lies instead of working around it with their own scripts, we would probably have a better tool already.
Or, maybe, a better tool already exists, and we should move to it.
In any case, my point is that even people that can commit to Git *should not* push to the main development branch. *Ever*. The mere fact that you reference "commit hooks" makes me think you're basically thinking that we're using Git by itself, like this is still 2009. We don't. We switched to GitLab because it offers us a lot more tools that "hooks". We have CI pipelines that run on branches; merge requests; an entire API to construct tools on top of our infrastructure.
We don't want special snowflakes, we just want to be able to do our work in the best way.
Your "best way" has a high chance to make me waste my time, when we have perfectly functional tools to avoid that.
I'm grateful for the work done by localisation teams; lowering the bar of contribution makes it better for everyone, but that should never come at the cost of the stability of the platform.
The solution to making GNOME software better is not to make everyone expert developers, but to make sure our infrastructure is automated and safe to contribute to—and "safe" doesn't mean "I can revert broken stuff after the fact". That principle has been one of the driving force of a lot of the changes in our infrastructure over the years.
Ciao,
Emmanuele.
El lun., 22 jun. 2020 a las 12:30, Emmanuele Bassi (<
ebassi gmail com>) escribió:
Hi;
to be brutally honest, as a maintainer I don't want any translator to commit directly to Git—unless it's done to a separate branch and/or through merge requests.
Translators do not build the projects they translate, and they don't (or cannot) know when they break things. The only way maintainers know that a broken translation happened is that suddenly the CI mails us, and then we have to hunt down what happened behind out backs. This is even worse when you realise something has broken a long time ago because the release process is now impossible.
I'd rather have an automated, web UI tool that pushed changes to a branch and opened a merge request that ran the CI pipeline (and maybe the dist process), than allowing translators to commit to Git directly. I don't really care if some translator is an old hand that was around when GNOME used CVS and scripted their way to push to dozens of repositories at once; we started using a lot of tooling to ensure things don't break, and even developers have started pushing things to development branches instead of committing directly to master. I don't see why translators have to be the special snowflakes of the whole GNOME project, and break stuff for everyone else just because of their 20 years old workflow.
Ciao,
Emmanuele.
Some time ago I talked about this with
+Carlos Soriano . I asked him about the possibility of creating a user's group in Gitlab, formed by some team coordinators, which will have commit rights to be able to commit a bunch of translations due to the heavy clickwork must be done in DL. Still waiting...
Me (and some other team coordinators) got Git access before migration to Gitlab, and it was not a problem. Having such rights will help us a lot to be more agile maintaining and commiting translations. Yes, I currently have those rights and can use an automated script [1] to ease my life, but I don't have commit rights in some new modules (app-icon-preview, shortwave...). I'd like to formerly request this feature/rigths. If we found any problem with a wrong commit or something like that is quick and easy to revert that commit; if a user with rights uses them for other things that translations is quick and easy to revoke those privileges. Advantages for us to maintain and keep translations up-to-date are huge.
Please consider this request and let's work together to make it possible in the best way.
Best regards.
Hello,
some time ago I complained about inability to commit damned-lies package due to wrong access rights. Ok, I can live with that, but lately I get this error on many, many packages, especially new ones, like:
app-icon-preview, authenticator, fractal, fragments, gnome-keysign, obfuscate, shortwave ... list goes on
Is there any special reason why not even coordinators are able to do that the usual way? Yes, I know, there is another way to do it, but it is cumbersome and takes a lot, lot, lot time to do it and what is more important, each project has some specifics. For this reasons I do not push these ...
Please advise or better, please bend at least for coordinators these rules.
Thank you,
Matej
gnome-i18n mailing list
gnome-i18n gnome org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
gnome-i18n mailing list
gnome-i18n gnome org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
--
--
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
