Re: Problems commiting damned-lies package
Le 23.06.20 à 19:44, Emmanuele Bassi via gnome-i18n a écrit : > That would be great. As I said, GitLab even has that baked into the `git > push` workflow through push options. If Damned Lies is just calling > `git`, it can move to a merge-request based workflow today, with minimal > cost. Wow, didn't know that. Thanks Emmanuele for pointing us to that Gitlab functionality. I'll try to experiment with that idea in coming days. Claude -- www.2xlibre.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Problems commiting damned-lies package
Hi Alexandre; thanks for the reply. On Tue, 23 Jun 2020 at 18:30, Alexandre Franke wrote: > Hi Emmanuele, > > As I mentioned in the other thread this conversation has become quite > dense and it would be hard for me to address everything that has been > said, but I thought you should know that the people pushing for Damned > lies to be kept are in line with your position. > I'm glad that there's at least a rough consensus on that. I appreciate the work that has been put into making DL work across the whole GNOME project, and if that's the best approach to translating GNOME components, I'm all for it. > On Mon, Jun 22, 2020 at 1:13 PM Emmanuele Bassi via gnome-i18n > > The fact that DL pushes to the main development branch *also* irks me to > no end; > > Agreed. In a better world once the “Ready to commit” state is reached > on DL, the “Submit to repository” action would instead open a merge > request and display it’s state in the DL workflow. That MR would allow > for CI to run. Once CI passed, I suppose the MR could be automatically > merged and the DL workflow archived? > > That would be great. As I said, GitLab even has that baked into the `git push` workflow through push options. If Damned Lies is just calling `git`, it can move to a merge-request based workflow today, with minimal cost. > > If people spent time improving Damned Lies instead of working around it > with their own scripts, > > we would probably have a better tool already. > > I somewhat agree, although poor translators who DIY their own scripts > doesn’t necessarily make developers that can extend something like > Damned lies (or Weblate, or whatever other platform). It is a > recurring issue that translators are not developers and we fail to > attract developers to tackle our issues. > Development is a part of the improvement process, but it's completely understandable. The infrastructure in GNOME is generally under-resourced—which is another reason why we moved to a "turn key" solution like GitLab. > > Or, maybe, a better tool already exists, and we should move to it. > > DL is the better tool in the bigger picture of i18n platforms, and I’m > pretty sure no other tool is able to do what we were talking about > above (regardless of other features like online translations). > That's good to know. Now while I can’t commit right now to addressing all the other points > made in this thread, I do have a proposal. GUADEC is in a few weeks. I > can prepare a BoF session around planning improvements to the GNOME > translation experience. The translation BoF at GUADEC is a regular > event but sadly it is usually always the same participants and > content, which mostly consists of making wish lists or rehashing the > same issues. I have been one of these participants and I’m not blaming > any of them for not making significant progress. > > Emmanuele, would you be able and willing to attend this session? As a > developer, CI caretaker and maybe even Foundation representative, your > insights would be greatly appreciated. > I'd be happy to attend, and expand on what a modern workflow for GNOME project entails. My main concern is trying to get translations of UI and documentation into the general trajectory that GNOME set upon; I don't have a horse in the race, and I don't really have any preference for localisation tools. What I want is to get my software in the hands of our users in a working state, and that requires changes not just in how developers and maintainers work, but also in how people translating and documenting GNOME work. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Problems commiting damned-lies package
Hi Emmanuele, As I mentioned in the other thread this conversation has become quite dense and it would be hard for me to address everything that has been said, but I thought you should know that the people pushing for Damned lies to be kept are in line with your position. On Mon, Jun 22, 2020 at 1:13 PM Emmanuele Bassi via gnome-i18n wrote: > 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. Yep. > The fact that DL pushes to the main development branch *also* irks me to no > end; Agreed. In a better world once the “Ready to commit” state is reached on DL, the “Submit to repository” action would instead open a merge request and display it’s state in the DL workflow. That MR would allow for CI to run. Once CI passed, I suppose the MR could be automatically merged and the DL workflow archived? > 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. Yes, we frown upon that too. > 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. Yeah, as I described above I share the same hope. > If people spent time improving Damned Lies instead of working around it with > their own scripts, > we would probably have a better tool already. I somewhat agree, although poor translators who DIY their own scripts doesn’t necessarily make developers that can extend something like Damned lies (or Weblate, or whatever other platform). It is a recurring issue that translators are not developers and we fail to attract developers to tackle our issues. > Or, maybe, a better tool already exists, and we should move to it. DL is the better tool in the bigger picture of i18n platforms, and I’m pretty sure no other tool is able to do what we were talking about above (regardless of other features like online translations). > Ciao, > Emmanuele. Thank you for your contribution to this conversation, Emmanuele. Now while I can’t commit right now to addressing all the other points made in this thread, I do have a proposal. GUADEC is in a few weeks. I can prepare a BoF session around planning improvements to the GNOME translation experience. The translation BoF at GUADEC is a regular event but sadly it is usually always the same participants and content, which mostly consists of making wish lists or rehashing the same issues. I have been one of these participants and I’m not blaming any of them for not making significant progress. Emmanuele, would you be able and willing to attend this session? As a developer, CI caretaker and maybe even Foundation representative, your insights would be greatly appreciated. -- Alexandre Franke GNOME i18n coordinator ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Problems commiting damned-lies package
Dear Fòram, and all, Am Mo., 22. Juni 2020 um 16:39 Uhr schrieb Fòram na Gàidhlig : > IMO the optimum workflow would be to pull weblate translations with a > scheduled GitLab CI job and let the CI commit them into a branch when > they're green. The master branch should be protected and nobody should > be allowed to push there directly. Even skilled and experienced project > maintainers will make mistakes, because nobody is perfect. What about this similar model: * We (translators) always commit to a fork of the central repo. D-L runs on top of this fork rather than the projects directly. Committers/coordinators have push access to all those forks. * Projects merge from this fork in some manner which is controlled by maintainers -- subject to CI pipelines etc. I suggest this because it might solve the most important immediate problems while it looks (to me) as a relatively small step. Introducing weblate could be an additional step. Best regards Ask ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Problems commiting damned-lies package
Speaking about Weblate, please consider back to this thread [1]. My question still not answered yet [2]. [1] https://mail.gnome.org/archives/gnome-i18n/2020-June/msg00016.html [2] https://mail.gnome.org/archives/gnome-i18n/2020-June/msg00036.html Regards On Mon, Jun 22, 2020 at 9:39 PM Fòram na Gàidhlig wrote: > I think WebLate would be a good pick. It has a glossary function too, > which teams will find handy to help with terminology consistency. And > you can download the files to translate too, in a long list of formats > of your choice. And it has some QA checks too, like punctuation, printf > placeholders etc. > > I only tried to translate a project once on Zanata and found the > experience frustrating enough that I decided to go off and translate > something else. > > And while I have become pretty skilled in using Git for programming work > and I love how powerful it is, I don't want to use Git directly while > translating. > > IMO the optimum workflow would be to pull weblate translations with a > scheduled GitLab CI job and let the CI commit them into a branch when > they're green. The master branch should be protected and nobody should > be allowed to push there directly. Even skilled and experienced project > maintainers will make mistakes, because nobody is perfect. > > > > Sgrìobh Carlos Soriano na leanas 22/06/2020 aig 13:47: > > Hey Daniel, > > > > First of all, I want to say that I see your POV, and you cannot change > > the whole thing by yourself and I'm glad you are pushing to address > > these translators' pain points in your time. I do agree on the technical > > side with Emannuelle, but I also understand it's not something that will > > happen unless some developer with the right skillset invests the time to > > do it, and that might be harder to find on the gnome-i18n group. > > > > I believe the issue is limited to certain groups, since you have access > > already for the GNOME group right? If so, it's a bit tricky, as those > > projects are not necessarily fully tied to GNOME. We don't support them > > in the same way we support the GNOME group, that is by design and as a > > result of having a more open infrastructure than we had before - now > > everyone can create their own personal project in GNOME's GitLab, even > > if they don't have commit rights to GNOME projects. > > > > Now, I don't see why we wouldn't make it easy for translators of GNOME > > to provide translations in other projects in our infra if desired, as > > long as we make the difference between GNOME projects and the rest clear > > in DL. We also have to acknowledge that certain projects might want to > > handle their permissions and workflow differently - they might block the > > master branch to anyone but maintainers. It's a reality that MR + CI is > > becoming the de facto approach, and the longer we take to transition to > > something else, the more painful is going to be for gnome-i18n. > > > > For a possible short term solution, could you file a GitLab ticket > > at https://gitlab.gnome.org/Infrastructure/GitLab detailing which groups > > or projects you would like to have access to, and the requirements and > > use cases that the gnome-i18n has for having commit right access? That > > way, it is not blocked on me or our own private communication. > > > > As a long term solution, did gnome-i18n investigate if there are other > > tools available (Zanata, WebLate, etc.) that would fit what we need > > here? I understand DL was created with certain features and workflows > > that fit well GNOME, but I have the feeling times are changing faster > > than we can adapt and we cannot find the developer resources to do so. > > Adopting one of those external tools might open new possibilities > > too, and bring a new type of contributors. > > > > Let me know if you have any other comments. > > > > On Mon, 22 Jun 2020 at 13:29, Daniel Mustieles García > > mailto:daniel.mustie...@gmail.com>> wrote: > > > > 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 > > (mailto:eba...@gmail.com>>) escribió: > > > > On Mon, 22 Jun 2020 at 11:44, Daniel Mustieles García > >
Re: Problems commiting damned-lies package
I think WebLate would be a good pick. It has a glossary function too, which teams will find handy to help with terminology consistency. And you can download the files to translate too, in a long list of formats of your choice. And it has some QA checks too, like punctuation, printf placeholders etc. I only tried to translate a project once on Zanata and found the experience frustrating enough that I decided to go off and translate something else. And while I have become pretty skilled in using Git for programming work and I love how powerful it is, I don't want to use Git directly while translating. IMO the optimum workflow would be to pull weblate translations with a scheduled GitLab CI job and let the CI commit them into a branch when they're green. The master branch should be protected and nobody should be allowed to push there directly. Even skilled and experienced project maintainers will make mistakes, because nobody is perfect. Sgrìobh Carlos Soriano na leanas 22/06/2020 aig 13:47: > Hey Daniel, > > First of all, I want to say that I see your POV, and you cannot change > the whole thing by yourself and I'm glad you are pushing to address > these translators' pain points in your time. I do agree on the technical > side with Emannuelle, but I also understand it's not something that will > happen unless some developer with the right skillset invests the time to > do it, and that might be harder to find on the gnome-i18n group. > > I believe the issue is limited to certain groups, since you have access > already for the GNOME group right? If so, it's a bit tricky, as those > projects are not necessarily fully tied to GNOME. We don't support them > in the same way we support the GNOME group, that is by design and as a > result of having a more open infrastructure than we had before - now > everyone can create their own personal project in GNOME's GitLab, even > if they don't have commit rights to GNOME projects. > > Now, I don't see why we wouldn't make it easy for translators of GNOME > to provide translations in other projects in our infra if desired, as > long as we make the difference between GNOME projects and the rest clear > in DL. We also have to acknowledge that certain projects might want to > handle their permissions and workflow differently - they might block the > master branch to anyone but maintainers. It's a reality that MR + CI is > becoming the de facto approach, and the longer we take to transition to > something else, the more painful is going to be for gnome-i18n. > > For a possible short term solution, could you file a GitLab ticket > at https://gitlab.gnome.org/Infrastructure/GitLab detailing which groups > or projects you would like to have access to, and the requirements and > use cases that the gnome-i18n has for having commit right access? That > way, it is not blocked on me or our own private communication. > > As a long term solution, did gnome-i18n investigate if there are other > tools available (Zanata, WebLate, etc.) that would fit what we need > here? I understand DL was created with certain features and workflows > that fit well GNOME, but I have the feeling times are changing faster > than we can adapt and we cannot find the developer resources to do so. > Adopting one of those external tools might open new possibilities > too, and bring a new type of contributors. > > Let me know if you have any other comments. > > On Mon, 22 Jun 2020 at 13:29, Daniel Mustieles García > mailto:daniel.mustie...@gmail.com>> wrote: > > 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 > (mailto:eba...@gmail.com>>) escribió: > > On Mon, 22 Jun 2020 at 11:44, Daniel Mustieles García > mailto: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
Re: Problems commiting damned-lies package
Hello, I am coming from another thread and second the adoption of Weblate. If someone prefers to work directly on PO files, those can be downloaded, translated and uploaded back to Weblate. It has checks for PO files. It has teams, permissions, terminology, translation memory, machine translation etc. It helps *a lot* while translating. Fedora has switched from Zanata to Weblate, and LibreOffice switched from Pootle to Weblate too. Currently it is the best choice we have. Please, please consider adopting it. Best regards, On Mon, Jun 22, 2020 at 5:48 PM Carlos Soriano wrote: > > Hey Daniel, > > First of all, I want to say that I see your POV, and you cannot change the > whole thing by yourself and I'm glad you are pushing to address these > translators' pain points in your time. I do agree on the technical side with > Emannuelle, but I also understand it's not something that will happen unless > some developer with the right skillset invests the time to do it, and that > might be harder to find on the gnome-i18n group. > > I believe the issue is limited to certain groups, since you have access > already for the GNOME group right? If so, it's a bit tricky, as those > projects are not necessarily fully tied to GNOME. We don't support them in > the same way we support the GNOME group, that is by design and as a result of > having a more open infrastructure than we had before - now everyone can > create their own personal project in GNOME's GitLab, even if they don't have > commit rights to GNOME projects. > > Now, I don't see why we wouldn't make it easy for translators of GNOME to > provide translations in other projects in our infra if desired, as long as we > make the difference between GNOME projects and the rest clear in DL. We also > have to acknowledge that certain projects might want to handle their > permissions and workflow differently - they might block the master branch to > anyone but maintainers. It's a reality that MR + CI is becoming the de facto > approach, and the longer we take to transition to something else, the more > painful is going to be for gnome-i18n. > > For a possible short term solution, could you file a GitLab ticket at > https://gitlab.gnome.org/Infrastructure/GitLab detailing which groups or > projects you would like to have access to, and the requirements and use cases > that the gnome-i18n has for having commit right access? That way, it is not > blocked on me or our own private communication. > > As a long term solution, did gnome-i18n investigate if there are other tools > available (Zanata, WebLate, etc.) that would fit what we need here? I > understand DL was created with certain features and workflows that fit well > GNOME, but I have the feeling times are changing faster than we can adapt and > we cannot find the developer resources to do so. Adopting one of those > external tools might open new possibilities too, and bring a new type of > contributors. > > Let me know if you have any other comments. > > On Mon, 22 Jun 2020 at 13:29, Daniel Mustieles García > wrote: >> >> 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 () >> escribió: >>> >>> On Mon, 22 Jun 2020 at 11:44, Daniel Mustieles García >>> 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
Re: Problems commiting damned-lies package
Hey Daniel, First of all, I want to say that I see your POV, and you cannot change the whole thing by yourself and I'm glad you are pushing to address these translators' pain points in your time. I do agree on the technical side with Emannuelle, but I also understand it's not something that will happen unless some developer with the right skillset invests the time to do it, and that might be harder to find on the gnome-i18n group. I believe the issue is limited to certain groups, since you have access already for the GNOME group right? If so, it's a bit tricky, as those projects are not necessarily fully tied to GNOME. We don't support them in the same way we support the GNOME group, that is by design and as a result of having a more open infrastructure than we had before - now everyone can create their own personal project in GNOME's GitLab, even if they don't have commit rights to GNOME projects. Now, I don't see why we wouldn't make it easy for translators of GNOME to provide translations in other projects in our infra if desired, as long as we make the difference between GNOME projects and the rest clear in DL. We also have to acknowledge that certain projects might want to handle their permissions and workflow differently - they might block the master branch to anyone but maintainers. It's a reality that MR + CI is becoming the de facto approach, and the longer we take to transition to something else, the more painful is going to be for gnome-i18n. For a possible short term solution, could you file a GitLab ticket at https://gitlab.gnome.org/Infrastructure/GitLab detailing which groups or projects you would like to have access to, and the requirements and use cases that the gnome-i18n has for having commit right access? That way, it is not blocked on me or our own private communication. As a long term solution, did gnome-i18n investigate if there are other tools available (Zanata, WebLate, etc.) that would fit what we need here? I understand DL was created with certain features and workflows that fit well GNOME, but I have the feeling times are changing faster than we can adapt and we cannot find the developer resources to do so. Adopting one of those external tools might open new possibilities too, and bring a new type of contributors. Let me know if you have any other comments. On Mon, 22 Jun 2020 at 13:29, Daniel Mustieles García < daniel.mustie...@gmail.com> wrote: > 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 () > 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
Re: Problems commiting damned-lies package
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 () 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
Re: Problems commiting damned-lies package
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 () > escribió: > >> Hi; >> >> to be brutally honest, as a maintainer I
Re: Problems commiting damned-lies package
Hi Emmanuele, Just a quick question: which is the difference between commiting directly into Git and commiting through DL? 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. 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. Of course, having a tool or a feature in DL to upload a bunch of PO files and commit them directly would be the best option, but we currently don no have it. 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... We don't want special snowflakes, we just want to be able to do our work in the best way. Regards El lun., 22 jun. 2020 a las 12:30, Emmanuele Bassi () 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 >> . 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,
Re: Problems commiting damned-lies package
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 > . 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] ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Problems commiting damned-lies package
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. [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
Re: Problems commiting damned-lies package
U, I have absolutely NO IDEA, what you're asking me ;). I will get into it. M! On Sun, Jun 21, 2020 at 9:12 PM Rafael Fontenelle wrote: > Hello Matej, > > Em dom., 21 de jun. de 2020 às 15:43, Matej Urban via gnome-i18n > escreveu: > > > > 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 > > > > Are all the modules that report wrong access rights from the "World" > namespace in GNOME GitLab? Asking this because those who are members > of the default namespace "GNOME" not necessarily are members in > "GNOME" as well. > > By the way, by namespace I mean the "World" in > https://gitlab.gnome.org/World/Authenticator > > Regards, > Rafael Fontenelle > ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Problems commiting damned-lies package
Hello Matej, Em dom., 21 de jun. de 2020 às 15:43, Matej Urban via gnome-i18n escreveu: > > 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 > Are all the modules that report wrong access rights from the "World" namespace in GNOME GitLab? Asking this because those who are members of the default namespace "GNOME" not necessarily are members in "GNOME" as well. By the way, by namespace I mean the "World" in https://gitlab.gnome.org/World/Authenticator Regards, Rafael Fontenelle ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Problems commiting damned-lies package
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
