Re: [PATCH 1/1] ci: new github-action for git-l10n code review

On Wed, Aug 25, 2021 at 02:14:43PM +0200, Johannes Schindelin wrote:

quoted

Yes, this is a solution I also want to try at the very beginning. But
some l10n team leaders may fork their repositories directly from
git/git, and name their repo as "{OWNER}/git".  I want to try another
solution: check existence of file "ci/config/allow-l10n" in branch
"ci-config" using a GitHub API, instead of cloning the ci-config
branch and execute the shell script "ci/config/allow-l10n".

I understood that you were trying to imitate what git/git does.

The problem, in git/git as well as in your patch, is that this is highly
cumbersome to use. Yes, it would be better if there was an easier UI to do
what you want to do, but the current reality is: there isn't.

The main reason why it is so cumbersome to use is that your chosen
strategy scatters the CI configuration so much that it puts a mental
burden on the users. I, for one, have no idea what is currently in my
`ci-config` branch. And new users will be forced to struggle to set up
their fork in such a way that the configuration does what they want it to
do.

And in this instance, there is not even any good reason to make it hard on
the users because most will likely not need that new workflow at all. That
workflow is primarily interesting for the l10n maintainers.

Just adding my two cents as the person who created the "ci-config"
mechanism: yes, it's absolutely horrible, and should be avoided if at
all possible. :)

Your repo-name solution seems like a quite reasonable alternative.

(I'd still love for there to be a way to selectively disable CI on
certain branches, but I didn't find another one, short of enforcing
branch-naming conventions that the whole project must agree on).

-Peff