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

[Ask Hjorth Larsen via gnome-i18n]

Dear all,

Am Fr., 26. Apr. 2019 um 10:43 Uhr schrieb Mathieu Bridon
:
>
> 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
>
> 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/.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
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n

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

[Niels De Graef via gnome-i18n]

On Fri, Apr 26, 2019 at 10:14 AM Ask Hjorth Larsen via
desktop-devel-list  wrote:
>
> Am Mi., 24. Apr. 2019 um 13:57 Uhr schrieb Michael Gratton :
> >
> > On Wed, Apr 24, 2019 at 13:31, Daniel Mustieles García
> >  wrote:
> > > So hardcoding the name "mainline" to the list of branches that Damned
> > > Lies' looks up resolves the problem for you... and tomorrow another
> > > maintainer decides to rename it's master branch to
> > > whatever_non_offensive_name and DL breaks again until a patch is
> > > submited... no, sorry but this is not a solution for this.
> >
> > I agree, which is why I have been working to fix it places where it's
> > hard coded.
>
> When actually working on the project, you probably type the branch
> name now and then.  This means you need to be aware of it - it is a
> piece of information which must reside within your short-term memory.
> This is not a problem if you work on one project.  It is a problem if
> you work on hundreds of projects.  Then you need to run things like
> git branch and git status, read the output, and decide what to type
> based on that.  A good workflow seeks to minimize the risk that humans
> make mistakes, and that means making things as simple as possible.
> Please do not remove this particular piece of simplicity from our
> lives.

Hi Ask,

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

# 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 -

Also note that cloning Geary will immediately take you to the default
branch of the remote (so no need to specify 'mainline' or anything).

> I can also script my way out of this for most of the tasks I need to
> do.  But inconsistencies have never made life easier in computing, and
> this is an inconsistency which we could simply choose not to deal
> with.

We _could_, but if we want to (which is still Mike's decision as
maintainer of Geary), we can. Every change has its trade-offs, and
given the work Mike has put into this to make it a smooth(er)
transition, I'd say there is little inconsistency left to care about.
At least it would take less time then all the mails I (in hindsight
regrettably) read on d-d-l.

Kind regards,
Niels


> Best regards
> Ask
>
> >
> > //Mike
> >
> > --
> > ⊨ Michael Gratton, Percept Wrangler.
> > ⚙ 
> >
> >
> > ___
> > gnome-i18n mailing list
> > gnome-i18n@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gnome-i18n
> ___
> desktop-devel-list mailing list
> desktop-devel-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n