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 (<eba...@gmail.com>) escribió: > On Mon, 22 Jun 2020 at 11:44, Daniel Mustieles García < > daniel.mustie...@gmail.com> wrote: > >> 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 > > when pushing to the remote repository: > https://docs.gitlab.com/ee/user/project/push_options.html > > 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. > > Regards >> >> El lun., 22 jun. 2020 a las 12:30, Emmanuele Bassi (<eba...@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. >>> >>> On Mon, 22 Jun 2020 at 11:03, Daniel Mustieles García via gnome-i18n < >>> gnome-i18n@gnome.org> wrote: >>> >>>> Some time ago I talked about this with +Carlos Soriano >>>> <csori...@gnome.org> . 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. >>>> >>>> [1]https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh >>>> >>>> El dom., 21 jun. 2020 a las 20:43, Matej Urban via gnome-i18n (< >>>> gnome-i18n@gnome.org>) escribió: >>>> >>>>> 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 >>>> >>> >>> >>> -- >>> https://www.bassi.io >>> [@] ebassi [@gmail.com] >>> >> > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] >
_______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
