llvm dev - Sep 2019 - [RFC] changing variable naming rules

Hypothetically assume that we have an LLVM release X and want to rename
variables in the next major release Y. In order to backport patches from Y
to X.1 smoothly, I think we could first apply the automated renaming tool
to X and then cherry-pick patches from Y. The obvious issue of doing this
is, even though X.1 is a dot release, a very large number of lines would be
changed from X, though.

On Mon, Sep 9, 2019 at 10:21 PM Hans Wennborg <hans at chromium.org>
wrote:
> On Mon, Sep 9, 2019 at 3:03 PM Rui Ueyama <ruiu at google.com> wrote:
> >
> > On Mon, Sep 9, 2019 at 8:25 PM Hans Wennborg <hans at
chromium.org> wrote:
> >>
> >> On Fri, Sep 6, 2019 at 6:17 PM Björn Pettersson A via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >> > I'm a little bit curious to hear more about the
experiences from the
> changes in LLD.
> >> > I’m thinking about things like:
> >> [..]
> >> > - merging of bugfixes to older release branches (I doubt that
the
> script supports doing the reverse rewrite as well)
> >>
> >> As someone who does a lot of these merges, this is the aspect that
> >> worries me the most.
> >
> >
> > How large is a typical patch to merge that is backported from the next
> major release to a previous dot release?
>
> The diffs are usually fairly small, but there can be many. For 8.0.1
> there were about 60 patches merged (git log
> llvmorg-8.0.0..llvmorg-8.0.1 --oneline | wc -l). (For 9.0.0 I think
> we're approaching 200 merges.)
>
> Depending on when the rename happens, I guess it could affect merges
> either for a major release or for a dot release, and it would mean a
> lot of extra work unless there was some tool available to help. Maybe
> if the rename happens after a dot release ships and before the next
> major release process begins, it would not affect any merges at all,
> but that's a pretty slim window, and downstream users might have other
> release processes.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/a6ca05e9/attachment.html>

The even bigger issue is that X.1 is supposed to be API and ABI
compatible with X.0.

On Mon, Sep 9, 2019 at 3:35 PM Rui Ueyama <ruiu at google.com>
wrote:
>
> Hypothetically assume that we have an LLVM release X and want to rename
variables in the next major release Y. In order to backport patches from Y to
X.1 smoothly, I think we could first apply the automated renaming tool to X and
then cherry-pick patches from Y. The obvious issue of doing this is, even though
X.1 is a dot release, a very large number of lines would be changed from X,
though.
>
> On Mon, Sep 9, 2019 at 10:21 PM Hans Wennborg <hans at chromium.org>
wrote:
>>
>> On Mon, Sep 9, 2019 at 3:03 PM Rui Ueyama <ruiu at google.com>
wrote:
>> >
>> > On Mon, Sep 9, 2019 at 8:25 PM Hans Wennborg <hans at
chromium.org> wrote:
>> >>
>> >> On Fri, Sep 6, 2019 at 6:17 PM Björn Pettersson A via llvm-dev
>> >> <llvm-dev at lists.llvm.org> wrote:
>> >> > I'm a little bit curious to hear more about the
experiences from the changes in LLD.
>> >> > I’m thinking about things like:
>> >> [..]
>> >> > - merging of bugfixes to older release branches (I doubt
that the script supports doing the reverse rewrite as well)
>> >>
>> >> As someone who does a lot of these merges, this is the aspect
that
>> >> worries me the most.
>> >
>> >
>> > How large is a typical patch to merge that is backported from the
next major release to a previous dot release?
>>
>> The diffs are usually fairly small, but there can be many. For 8.0.1
>> there were about 60 patches merged (git log
>> llvmorg-8.0.0..llvmorg-8.0.1 --oneline | wc -l). (For 9.0.0 I think
>> we're approaching 200 merges.)
>>
>> Depending on when the rename happens, I guess it could affect merges
>> either for a major release or for a dot release, and it would mean a
>> lot of extra work unless there was some tool available to help. Maybe
>> if the rename happens after a dot release ships and before the next
>> major release process begins, it would not affect any merges at all,
>> but that's a pretty slim window, and downstream users might have
other
>> release processes.

Ah, that is true. Thank you for pointing that out. I'm not pushing this
idea too much, but in theory, if there's a tool that does the reverse
conversion, we might be able to backport patches from a newer tree to an
old tree without breaking the API and ABI, but I can see that that can be
tricky.

On Mon, Sep 9, 2019 at 10:42 PM Hans Wennborg <hans at chromium.org>
wrote:
> The even bigger issue is that X.1 is supposed to be API and ABI
> compatible with X.0.
>
> On Mon, Sep 9, 2019 at 3:35 PM Rui Ueyama <ruiu at google.com> wrote:
> >
> > Hypothetically assume that we have an LLVM release X and want to
rename
> variables in the next major release Y. In order to backport patches from Y
> to X.1 smoothly, I think we could first apply the automated renaming tool
> to X and then cherry-pick patches from Y. The obvious issue of doing this
> is, even though X.1 is a dot release, a very large number of lines would be
> changed from X, though.
> >
> > On Mon, Sep 9, 2019 at 10:21 PM Hans Wennborg <hans at
chromium.org> wrote:
> >>
> >> On Mon, Sep 9, 2019 at 3:03 PM Rui Ueyama <ruiu at
google.com> wrote:
> >> >
> >> > On Mon, Sep 9, 2019 at 8:25 PM Hans Wennborg <hans at
chromium.org>
> wrote:
> >> >>
> >> >> On Fri, Sep 6, 2019 at 6:17 PM Björn Pettersson A via
llvm-dev
> >> >> <llvm-dev at lists.llvm.org> wrote:
> >> >> > I'm a little bit curious to hear more about the
experiences from
> the changes in LLD.
> >> >> > I’m thinking about things like:
> >> >> [..]
> >> >> > - merging of bugfixes to older release branches (I
doubt that the
> script supports doing the reverse rewrite as well)
> >> >>
> >> >> As someone who does a lot of these merges, this is the
aspect that
> >> >> worries me the most.
> >> >
> >> >
> >> > How large is a typical patch to merge that is backported from
the
> next major release to a previous dot release?
> >>
> >> The diffs are usually fairly small, but there can be many. For
8.0.1
> >> there were about 60 patches merged (git log
> >> llvmorg-8.0.0..llvmorg-8.0.1 --oneline | wc -l). (For 9.0.0 I
think
> >> we're approaching 200 merges.)
> >>
> >> Depending on when the rename happens, I guess it could affect
merges
> >> either for a major release or for a dot release, and it would mean
a
> >> lot of extra work unless there was some tool available to help.
Maybe
> >> if the rename happens after a dot release ships and before the
next
> >> major release process begins, it would not affect any merges at
all,
> >> but that's a pretty slim window, and downstream users might
have other
> >> release processes.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/0ef6f84e/attachment.html>