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

[Rui Ueyama via llvm-dev]

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>