Re: Heads up: Geary mainline development branch renamed to `mainline`

[Ask Hjorth Larsen <asklarsen gmail com>]

Dear all,

Am Fr., 26. Apr. 2019 um 10:43 Uhr schrieb Mathieu Bridon
<bochecha daitauha fr>:
> On Fri, 2019-04-26 at 10:38 +0200, Niels De Graef via desktop-devel-
> list wrote:
> > Note that you don't need to script this kind of stuff, if you use the
> > following tricks:
> >
> > # 1. This creates a symbolic link from master to mainline, which
> > solves your problem already.
> > $ git symbolic-ref refs/heads/master refs/heads/mainline

Unfortunately that is not sufficient to solve the problem.  The
problem was not how to update the default branch for one repository.
I have 250+ repositories checked out of GNOME.  Now maintainers start
renaming branches for no justified reason (moving to git was well
justified and everyone did so; moving to Gitlab likewise) so where
before it was always master, now it will be anyone's guess.  This is a
slippery slope.  Rule number one is keep it simple.

> > # 2. This worfklow doesn't even need you to specify a branch if you
> > start from mainline/master
> > $ git checkout -b feature/....
> > # work, work, work and commit
> > # If you no longer want to continue on this branch, you can go back
> > to the previous one with
> > $ git checkout -

So we need to change workflow for all of GNOME because one maintainer
decides that we must use a special name for one project.  That does
not sound like a good decision. The maintainers should keep in mind
that there are people whose work touches all the repositories, and
uniformity is a requirement for an efficient workflow.  If I only
needed to ever work on a single repository or a few repositories, I
would not care either.  So that is what the maintainer probably
thinks, but surprisingly, the devs don't belong to the set people whom
the change affects the most.

Typically we are interested in committing either to master, or to a
stable branch like gnome-3-32 and then also master (but now we need an
extra incantation to see the name of the branch), but for hundreds of
projects.  The appropriate branch names can often but not always be
inferred from the filename.  Often we have simultaneous changes across
large numbers of modules, like when GNOME started recommending unicode
punctuation (“” »« etc.).

> # 3. Tab completion works wonders:
> $ git checkout ma<tab>
>
> Mike said himself that choosing a new name starting with the same
> letters as "master" was a deliberate choice to further minimize the
> disruption.

I always use tab completion when working with git.

Both Damned-Lies and our own scripts/workflows rely on the fact that
there are certain common elements shared by the GNOME projects: Things
like everything being on GNOME's Gitlab instead of svn, consistent
naming of files and paths (po/<lang>.po, LINGUAS), and so on.  For any
particular change, we *can* deal with it, at the cost of needing to
invest more time, and making mistakes at a higher frequency because
that is what you get when things are not as simple as possible.

There are always a few repositories that don't work well, sometimes
D-L produces inconsistent filenames or something was moved to a
different Gitlab group, you need manually commit the documentation
within a certain class of project, and so on.  We can always deal with
these exceptions which are generally unintended or at least not the
product of willful deviation from the standard, but we don't /like/ to
do those things, and there is no reason why our scripts and
infrastructure should be made more complicated to satisfy everyone's
whims.

This is not even a UI change.  Years ago there was a discussion for
changing GNOME branding because the logo (a foot) is considered rude
in some cultures.  As I recall, such a change was not made.  Now we
compromise the simplicity of our infrastructure to satisfy political
standards that do not even affect users.

Please go back to master.

Best regards
Ask

> --
> Mathieu