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

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>

On 20/06/2020 01:00, Mehdi AMINI wrote:
> 
> 
> On Fri, Jun 19, 2020 at 4:55 PM antlists via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto: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>
>     <mailto: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).
> 
> 
I was thinking that, since the making of a new release is a fork (of 
sorts), in a very real sense you're kicking off a new master, and so 
kicking it off with a new name makes sense to me.

I would have thought a lot of people will stick the with the new release 
for a while (which would keep the "master" name if it's
appropriate) so
they can just carry on as nothing's changed.

But as people switch from the new release to the new development branch 
they also have to switch to the new name. The change may be a jolt to 
the project, but the developers will switch when they're ready, and any 
disruption to the project will be at a time when it impacts the fewest 
people and offers the maximum opportunity to fix any hiccups at a time 
of minimum impact.

Cheers,
Wol

On Fri, Jun 19, 2020 at 5:14 PM antlists <antlists at youngman.org.uk>
wrote:
> On 20/06/2020 01:00, Mehdi AMINI wrote:
> >
> >
> > On Fri, Jun 19, 2020 at 4:55 PM antlists via llvm-dev
> > <llvm-dev at lists.llvm.org <mailto: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>
> >     <mailto: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).
> >
> >
> I was thinking that, since the making of a new release is a fork (of
> sorts), in a very real sense you're kicking off a new master, and so
> kicking it off with a new name makes sense to me.
>
That is not how the branch management works unfortunately.

>
> I would have thought a lot of people will stick the with the new release
> for a while (which would keep the "master" name if it's
appropriate) so
> they can just carry on as nothing's changed.
>
> But as people switch from the new release to the new development branch
> they also have to switch to the new name. The change may be a jolt to
> the project, but the developers will switch when they're ready, and any
> disruption to the project will be at a time when it impacts the fewest
> people and offers the maximum opportunity to fix any hiccups at a time
> of minimum impact.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200619/db7c6ec5/attachment.html>