Re: Problems commiting damned-lies package

[Alexandre Franke <afranke gnome org>]

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
<gnome-i18n gnome org> 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