[Cluster-devel] [ClusterLabs Developers] Pacemaker 2.1.0: Should we rename the master branch?

[Cluster-devel] [ClusterLabs Developers] Pacemaker 2.1.0: Should we rename the master branch?

[Andrew Price]

[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 users at 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?
> 
>   booth
>   corosync
>   fence-agents
>   fence-virt
>   knet
>   libqb
>   pacemaker
>   pcs
>   qdevice
>   resource-agents
>   sbd
> 
> Maintainers, do you think that's practical and desirable?

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.

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 :)

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.

[Cluster-devel] [ClusterLabs Developers] Pacemaker 2.1.0: Should we rename the master branch?

[Fabio M. Di Nitto]

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 users at 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.
> 

[Cluster-devel] [ClusterLabs Developers] Pacemaker 2.1.0: Should we rename the master branch?

[Ken Gaillot]

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 users at 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 <kgaillot@redhat.com>

[Cluster-devel] [ClusterLabs Developers] Pacemaker 2.1.0: Should we rename the master branch?

[Fabio M. Di Nitto]

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 users at 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.
>>
>>