llvm dev - Jun 2020 - Inclusive language in LLVM: can we rename `master` branch?

> On Jun 19, 2020, at 15:38, Mehdi AMINI via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I'm interested to hear more about the actual problem Matt perceives
with respect to the release actually: why should the release have any impact
with the development branch?
> 
That was just an example of a concrete time. Other transitions requiring wide
coordination have had some release-associated timeframe (like minimum
toolchain/cmake upgrades), so I thought it would just be a logical
semi-arbitrary point in time.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200619/cab2b577/attachment.html>

On Fri, Jun 19, 2020 at 12:43 PM Matt Arsenault <arsenm2 at gmail.com>
wrote:
>
>
> On Jun 19, 2020, at 15:38, Mehdi AMINI via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> I'm interested to hear more about the actual problem Matt perceives
with
> respect to the release actually: why should the release have any impact
> with the development branch?
>
>
> That was just an example of a concrete time. Other transitions requiring
> wide coordination have had some release-associated timeframe (like minimum
> toolchain/cmake upgrades), so I thought it would just be a logical
> semi-arbitrary point in time.
>
I saw using release in the past as a good sync point for toolchain/cmake
upgrade before it as very practical effects: as such changes are very
visible to folks consuming the release and we can include a heads up in the
release notes or a warning when they execute CMake.
Hopefully we have more freedom with the development branch: a few weeks
head up for the bot infrastructure and the folks downstream having
automation pulling from upstream continuously.
Ultimately this is just a "simple" renaming: there shouldn't be
deep
configuration changes or infrastructure to rewire.

Note that even for a casual user it would go unnoticed: cloning the repo
from GitHub automatically pull the default branch which is a configurable
name.

(Note: We also need to reconfigure Phabricator at the same time).

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200619/78b84c59/attachment.html>

(generally in favor, don't much care what the new name is -
consistency with git and github seems valuable - don't think I
personally care if it's one rename or two, but I agree with others
that we should discuss/have a plan & know the costs of that plan
before we make the change (whether we do it once or twice))

On Fri, Jun 19, 2020 at 12:55 PM Mehdi AMINI via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Fri, Jun 19, 2020 at 12:43 PM Matt Arsenault <arsenm2 at
gmail.com> wrote:
>>
>>
>>
>> On Jun 19, 2020, at 15:38, Mehdi AMINI via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> I'm interested to hear more about the actual problem Matt perceives
with respect to the release actually: why should the release have any impact
with the development branch?
>>
>>
>> That was just an example of a concrete time. Other transitions
requiring wide coordination have had some release-associated timeframe (like
minimum toolchain/cmake upgrades), so I thought it would just be a logical
semi-arbitrary point in time.
>
>
> I saw using release in the past as a good sync point for toolchain/cmake
upgrade before it as very practical effects: as such changes are very visible to
folks consuming the release and we can include a heads up in the release notes
or a warning when they execute CMake.
> Hopefully we have more freedom with the development branch: a few weeks
head up for the bot infrastructure and the folks downstream having automation
pulling from upstream continuously.
> Ultimately this is just a "simple" renaming: there shouldn't
be deep configuration changes or infrastructure to rewire.
>
> Note that even for a casual user it would go unnoticed: cloning the repo
from GitHub automatically pull the default branch which is a configurable name.
Speaking of which - how many things do actually need to know the
branch name - if the casual user can pull/checkout the code without
specifying a branch name, do the buildbots need to do anything
different? If they do specify the branch name today, perhaps we could
change their configurations so the don't need to do that & can rely on
the default.

When the change is made, will existing git checkouts (& possibly
buildbots) just keep working? (will all my local branches now be
branches on main instead of master?) Or will all developers have to do
some manual step(s) to update?
>
> (Note: We also need to reconfigure Phabricator at the same time).
>
> --
> Mehdi
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 19/06/2020 20:43, Matt Arsenault via llvm-dev wrote:
> 
> 
>> On Jun 19, 2020, at 15:38, Mehdi AMINI via llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>
>> I'm interested to hear more about the actual problem Matt perceives
>> with respect to the release actually: why should the release have any 
>> impact with the development branch?
>>
> 
> That was just an example of a concrete time. Other transitions requiring 
> wide coordination have had some release-associated timeframe (like 
> minimum toolchain/cmake upgrades), so I thought it would just be a 
> logical semi-arbitrary point in time.
> 
Would it make sense to pick that semi-arbitrary point in time as being 
the next release? So master is renamed for the next release.

Cheers,
Wol

On Fri, Jun 19, 2020 at 4:55 PM antlists via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 19/06/2020 20:43, Matt Arsenault via llvm-dev wrote:
> >
> >
> >> On Jun 19, 2020, at 15:38, Mehdi AMINI via llvm-dev
> >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
> >>
> >> I'm interested to hear more about the actual problem Matt
perceives
> >> with respect to the release actually: why should the release have
any
> >> impact with the development branch?
> >>
> >
> > That was just an example of a concrete time. Other transitions
requiring
> > wide coordination have had some release-associated timeframe (like
> > minimum toolchain/cmake upgrades), so I thought it would just be a
> > logical semi-arbitrary point in time.
> >
> Would it make sense to pick that semi-arbitrary point in time as being
> the next release? So master is renamed for the next release.
>
Well you wrote in another email: `please do things for sound *technical*
reason`, what is the technical reason here?
We *can* pick this point in time, but I haven't seen the reason to do so
(and actually since we're already making branch/tag changes at that time it
may even be a reason to avoid it).

>
> Cheers,
> Wol
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200619/387ab7ec/attachment.html>