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.
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. > > -- Ken Gaillot <kgail...@redhat.com> _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/developers ClusterLabs home: https://www.clusterlabs.org/
