On 10/21/2020 7:25 PM, Ken Gaillot wrote:
Maybe we should wait until github finishes putting its plans in place.
Especially if we want to do all projects at once, there's no need to
tie it to a particular Pacemaker release.
Right, I don´t see any reason to tie releases with branch changes.
Let´s keep operations as-is till github has all the infra in place and
that will make the change much more smooth. It might give me time to
start changing CI to handle main and master as if they were the same in
the meantime.
Cheers
Fabio
On Wed, 2020-10-21 at 06:10 +0200, Fabio M. Di Nitto wrote:
On 10/20/2020 7:26 PM, Andrew Price wrote:
[CC+ cluster-devel]
On 19/10/2020 23:59, Ken Gaillot wrote:
On Mon, 2020-10-19 at 07:19 +0200, Fabio M. Di Nitto wrote:
Hi Ken,
On 10/2/2020 8:02 PM, Digimer wrote:
On 2020-10-02 1:12 p.m., Ken Gaillot wrote:
Hi all,
I sent a message to the us...@clusterlabs.org list about
releasing
Pacemaker 2.1.0 next year.
Coincidentally, there is a plan in the git and Github
communities
to
change the default git branch from "master" to "main":
https://github.com/github/renaming
The rationale for the change is not the specific meaning as
used
in
branching, but rather to avoid any possibility of fostering
an
exclusionary environment, and to replace generic metaphors
with
something more obvious (especially to non-native English
speakers).
No objections to the change, but please let´s coordinate the
change
across all HA projects at once, or CI is going to break badly
as the
concept of master branch is embedded everywhere and not per-
project.
Presumably this would be all the projects built by jenkins?
correct.
booth
corosync
fence-agents
fence-virt
knet
libqb
pacemaker
pcs
qdevice
resource-agents
sbd
Maintainers, do you think that's practical and desirable?
I think I have super powers all repos to do the switch when github
is
ready to make us the switch. Practical no, there will be
disruptions...
desirable no, it´s extra work, but the point is that it is doable.
If the ClusterLabs projects switch together I might take the
opportunity
to make the switch in gfs2-utils.git at the same time, for
consistency.
Is there a single name that makes sense for all projects? "next",
"development" or "unstable" captures how pacemaker uses master,
not
sure about other projects. "main" is generic enough for all
projects,
but so generic it doesn't give an idea of how it's used. Or we
could go
for something distinctive like fedora's "rawhide" or suse's
"tumbleweed".
"main" works for me, it seems to be the most widely adopted
alternative
thanks to Github, so its purpose will be clear by convention. That
said,
it doesn't matter too much as long as the remote HEAD is set to the
new
branch.
I would go for main and follow github recommendations. They are
putting
automatic redirects in place to smooth the transition and we can
avoid
spending time finding a name that won´t offend some delicate soul
over
the internet.
Another question is how to do the switch without causing confusion
the
next time someone pulls. It might be safest to simply create the
main
branch and delete the master branch (rather than, say, replacing
all of
the content in master with an explanatory note). That way a 'git
pull'
gives a hint of the change and no messy conflicts:
$ git pull
From /tmp/gittest/upstream
* [new branch] main -> origin/main
Your configuration specifies to merge with the ref
'refs/heads/master'
from the remote, but no such ref was fetched.
Maybe also push a 'master_is_now_main' tag annotated with 'use git
branch -u origin/main to fix tracking branches'. Or maybe that's
excessive :)
Let´s wait for github to put those in place for us. No point to
re-invent the wheel. Last blog I read they were working to do it at
infrastructure level and that would save us a lot of headaches and
complications.
IIRC they will add main branch automatically to new projects and
transition old ones. the master branch will be an automatic redirect
to
main. Basically will solve 99% of our issues. git pull won´t break
etc.
Cheers
Fabio
Cheers,
Andy
Since we are admin of all repositories, we can do it in one
shot
without
too much pain and suffering in CI. It will require probably a
day or
two
of CI downtime to rebuild the world as well.
Fabio
The change would not affect existing repositories/projects.
However I
am wondering if we should take the opportunity of the
minor-
version
bump to do the same for Pacemaker. The impact on developers
would
be a
one-time process for each checkout/fork:
https://wiki.clusterlabs.org/wiki/Pacemaker_2.1_Changes#Development_changes
In my opinion, this is a minor usage that many existing
projects
will
not bother changing, but I do think that since all new
projects
will
default to "main", sometime in the future any project still
using
"master" will appear outdated to young developers.
We could use "main" or something else. Some projects are
switching to
names like "release", "stable", or "next" depending on how
they're
actually using the branch ("next" would be appropriate in
Pacemaker's
case).
This will probably go on for years, so I am fine with
either
changing
it with 2.1.0 (since it has bigger changes than usual, and
we can
get
ahead of the curve) or waiting until the dust settles and
future
conventions are clearer.
Opinions?
I support this change whole heatedly. I'll leave it to others
to
decide
what new word is best (though 'main' makes sense to me), but
the
goal of
moving away from 'master/slave' is well worthwhile and
appreciated.
_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/developers
ClusterLabs home: https://www.clusterlabs.org/
