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

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/bd331844/attachment.html>

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.

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>