Eric Christopher via llvm-dev
2020-Feb-19 00:39 UTC
[llvm-dev] amount of camelCase refactoring causing some downstream overhead
Hi Philip, While it's true we don't I think Valentin is reasonable in saying "hey, when people do this let's try to combine them if it makes sense". It's just being polite to everyone, especially if it doesn't risk the patches or upstream stability. I don't think there's a policy change being proposed, just a "hey, let's see what we can do in the future". -eric On Tue, Feb 18, 2020 at 4:05 PM Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Valentin, > > You are proposing to change existing policy. Current policy is that we > don't consider downstream *at all*. Your proposal may seem reasonable - it > may even *be* reasonable - but it is definitely a change from historical > practice and must be considered as such. > > Philip > On 2/18/20 3:03 PM, Valentin Churavy wrote: > > I don't think anyone is arguing to change longstanding policy. From a > downstream perspective many small renaming changes do increase overhead for > us. > > One thing that happens to downstream projects is that they support more > than one LLVM version, we (JuliaLang) currently try to support latest > stable + master. > > So for me the question is more, are renaming changes worth downstream > projects not being able to test and provide feedback to upstream? One way > of mitigating that is to consciously schedule them just before a release > and do them all in short succession. > > -V > > > On Tue, Feb 18, 2020, 17:00 Philip Reames via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> As others have said, our long standing policy has been that downstream >> projects must fend for themselves. We're certainly not going to reverse >> that policy without careful discussion of the tradeoffs. >> >> I'm personally of the opinion that there could be a middle ground which >> allows upstream to move quickly while reducing headache for downstream >> projects. Given I wear both hats, I know I'd certainly appreciate such >> a state. However, it's important to state that such decisions would >> need to be carefully considered and would require some very careful >> drafting of proposal to balance the competing interests at hand. >> >> If anyone is curious, I'm happy to share some ideas offline on what >> starting points might be, but I have neither the time nor the interest >> to drive such a conversion on list. >> >> Philip >> >> On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote: >> > During that variable renaming debate, there was a discussion about >> discussion about doing things all at once, piecemeal or not at all. An >> issue that wasn't really resolved I think. I had the impression that the >> efforts fizzled out a bit, and I thought this renaming was maybe related to >> that, but I'm neutral on if we should do variable renaming. >> > >> > All I'm asking as a kindness if we could be kind on poor downstream >> maintainers not on the issue of variable renaming at large, but on the >> micro level of not pushing 5/6 patches of this kind covering closely >> related functionality in two days but collating them in 1. I don't think >> that would slow down development, and I wanted to highlight the issue, as >> people might not be aware that they could save some pain in a simple way. >> Especially if indeed there is going to be a big renaming push and this >> would be a continuous thing. >> > >> > Cheers, >> > /Ties >> > >> > ________________________________________ >> > From: Michael Kruse <llvmdev at meinersbur.de> >> > Sent: 17 February 2020 21:16 >> > To: Ties Stuij >> > Cc: llvm-dev >> > Subject: Re: [llvm-dev] amount of camelCase refactoring causing some >> downstream overhead >> > >> > My understanding is that LLVM's general policy is to not let >> > downstream slow down upstream development. The C++ API explicitly >> > unstable. >> > >> > Note that we are even considering renaming variables globally: >> > https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html >> > >> > Michael >> > >> > Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via llvm-dev >> > <llvm-dev at lists.llvm.org>: >> >> Hi there, >> >> >> >> At the end of last week we saw a number of commits go in that were >> camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions. >> >> >> >> For example: >> >> - https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 >> >> - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b >> >> - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 >> >> >> >> Unfortunately all these individual commits trigger the same merge >> conflicts over and over again with our downstream repo, which takes us some >> manual intervention every time. >> >> >> >> I understand uniformity is a nice to have, but: >> >> 1 - is it worth it to do this work right now? I can remember the >> casing debate a few months back, which seems unrelated to this work which >> seems manual, but I'm unsure of the outcome. >> >> 2 - If this work should be done, it would be nice if all of the work >> is done in one batch, to save us some of the downstream overhead. >> >> >> >> Thanks >> >> /Ties >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > 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/20200218/366f9568/attachment.html>
David Blaikie via llvm-dev
2020-Feb-19 02:21 UTC
[llvm-dev] amount of camelCase refactoring causing some downstream overhead
On Tue, Feb 18, 2020 at 4:39 PM Eric Christopher via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi Philip, > > While it's true we don't I think Valentin is reasonable in saying "hey, > when people do this let's try to combine them if it makes sense". It's just > being polite to everyone, especially if it doesn't risk the patches or > upstream stability. I don't think there's a policy change being proposed, > just a "hey, let's see what we can do in the future". >I think the somewhat unspoken change in LLVM social conventions (& somewhat policy, I think it's written down in some places) is the "keep patches as small as practically possible" - grouping unrelated renamings would be something I'd usually (without concern for downstream consumers) push back against for all the usual reasons: easier to review, easier to revert strategically if something goes wrong, etc. What I'm not clear on is why one big rename patch is easier for a downstream consumer than two smaller renames - I haven't fully understood the nature of this particular downstream consumer's approach makes this interesting. - Dave> > -eric > > On Tue, Feb 18, 2020 at 4:05 PM Philip Reames via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Valentin, >> >> You are proposing to change existing policy. Current policy is that we >> don't consider downstream *at all*. Your proposal may seem reasonable - it >> may even *be* reasonable - but it is definitely a change from historical >> practice and must be considered as such. >> >> Philip >> On 2/18/20 3:03 PM, Valentin Churavy wrote: >> >> I don't think anyone is arguing to change longstanding policy. From a >> downstream perspective many small renaming changes do increase overhead for >> us. >> >> One thing that happens to downstream projects is that they support more >> than one LLVM version, we (JuliaLang) currently try to support latest >> stable + master. >> >> So for me the question is more, are renaming changes worth downstream >> projects not being able to test and provide feedback to upstream? One way >> of mitigating that is to consciously schedule them just before a release >> and do them all in short succession. >> >> -V >> >> >> On Tue, Feb 18, 2020, 17:00 Philip Reames via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> As others have said, our long standing policy has been that downstream >>> projects must fend for themselves. We're certainly not going to reverse >>> that policy without careful discussion of the tradeoffs. >>> >>> I'm personally of the opinion that there could be a middle ground which >>> allows upstream to move quickly while reducing headache for downstream >>> projects. Given I wear both hats, I know I'd certainly appreciate such >>> a state. However, it's important to state that such decisions would >>> need to be carefully considered and would require some very careful >>> drafting of proposal to balance the competing interests at hand. >>> >>> If anyone is curious, I'm happy to share some ideas offline on what >>> starting points might be, but I have neither the time nor the interest >>> to drive such a conversion on list. >>> >>> Philip >>> >>> On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote: >>> > During that variable renaming debate, there was a discussion about >>> discussion about doing things all at once, piecemeal or not at all. An >>> issue that wasn't really resolved I think. I had the impression that the >>> efforts fizzled out a bit, and I thought this renaming was maybe related to >>> that, but I'm neutral on if we should do variable renaming. >>> > >>> > All I'm asking as a kindness if we could be kind on poor downstream >>> maintainers not on the issue of variable renaming at large, but on the >>> micro level of not pushing 5/6 patches of this kind covering closely >>> related functionality in two days but collating them in 1. I don't think >>> that would slow down development, and I wanted to highlight the issue, as >>> people might not be aware that they could save some pain in a simple way. >>> Especially if indeed there is going to be a big renaming push and this >>> would be a continuous thing. >>> > >>> > Cheers, >>> > /Ties >>> > >>> > ________________________________________ >>> > From: Michael Kruse <llvmdev at meinersbur.de> >>> > Sent: 17 February 2020 21:16 >>> > To: Ties Stuij >>> > Cc: llvm-dev >>> > Subject: Re: [llvm-dev] amount of camelCase refactoring causing some >>> downstream overhead >>> > >>> > My understanding is that LLVM's general policy is to not let >>> > downstream slow down upstream development. The C++ API explicitly >>> > unstable. >>> > >>> > Note that we are even considering renaming variables globally: >>> > https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html >>> > >>> > Michael >>> > >>> > Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via llvm-dev >>> > <llvm-dev at lists.llvm.org>: >>> >> Hi there, >>> >> >>> >> At the end of last week we saw a number of commits go in that were >>> camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions. >>> >> >>> >> For example: >>> >> - https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 >>> >> - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b >>> >> - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 >>> >> >>> >> Unfortunately all these individual commits trigger the same merge >>> conflicts over and over again with our downstream repo, which takes us some >>> manual intervention every time. >>> >> >>> >> I understand uniformity is a nice to have, but: >>> >> 1 - is it worth it to do this work right now? I can remember the >>> casing debate a few months back, which seems unrelated to this work which >>> seems manual, but I'm unsure of the outcome. >>> >> 2 - If this work should be done, it would be nice if all of the work >>> is done in one batch, to save us some of the downstream overhead. >>> >> >>> >> Thanks >>> >> /Ties >>> >> _______________________________________________ >>> >> LLVM Developers mailing list >>> >> llvm-dev at lists.llvm.org >>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> > _______________________________________________ >>> > LLVM Developers mailing list >>> > llvm-dev at lists.llvm.org >>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > 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/20200218/cc7e1144/attachment.html>
Eric Christopher via llvm-dev
2020-Feb-19 02:30 UTC
[llvm-dev] amount of camelCase refactoring causing some downstream overhead
On Tue, Feb 18, 2020 at 6:21 PM David Blaikie <dblaikie at gmail.com> wrote:> > > On Tue, Feb 18, 2020 at 4:39 PM Eric Christopher via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Philip, >> >> While it's true we don't I think Valentin is reasonable in saying "hey, >> when people do this let's try to combine them if it makes sense". It's just >> being polite to everyone, especially if it doesn't risk the patches or >> upstream stability. I don't think there's a policy change being proposed, >> just a "hey, let's see what we can do in the future". >> > > I think the somewhat unspoken change in LLVM social conventions (& > somewhat policy, I think it's written down in some places) is the "keep > patches as small as practically possible" - grouping unrelated renamings > would be something I'd usually (without concern for downstream consumers) > push back against for all the usual reasons: easier to review, easier to > revert strategically if something goes wrong, etc. > > What I'm not clear on is why one big rename patch is easier for a > downstream consumer than two smaller renames - I haven't fully understood > the nature of this particular downstream consumer's approach makes this > interesting. > >Mostly the range of "broken" revisions as an example. That said, I also very much want it to make sense rather than something else. :) I agree with everything you've said anyhow. -eric> - Dave > > >> >> -eric >> >> On Tue, Feb 18, 2020 at 4:05 PM Philip Reames via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Valentin, >>> >>> You are proposing to change existing policy. Current policy is that we >>> don't consider downstream *at all*. Your proposal may seem reasonable - it >>> may even *be* reasonable - but it is definitely a change from historical >>> practice and must be considered as such. >>> >>> Philip >>> On 2/18/20 3:03 PM, Valentin Churavy wrote: >>> >>> I don't think anyone is arguing to change longstanding policy. From a >>> downstream perspective many small renaming changes do increase overhead for >>> us. >>> >>> One thing that happens to downstream projects is that they support more >>> than one LLVM version, we (JuliaLang) currently try to support latest >>> stable + master. >>> >>> So for me the question is more, are renaming changes worth downstream >>> projects not being able to test and provide feedback to upstream? One way >>> of mitigating that is to consciously schedule them just before a release >>> and do them all in short succession. >>> >>> -V >>> >>> >>> On Tue, Feb 18, 2020, 17:00 Philip Reames via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> As others have said, our long standing policy has been that downstream >>>> projects must fend for themselves. We're certainly not going to >>>> reverse >>>> that policy without careful discussion of the tradeoffs. >>>> >>>> I'm personally of the opinion that there could be a middle ground which >>>> allows upstream to move quickly while reducing headache for downstream >>>> projects. Given I wear both hats, I know I'd certainly appreciate such >>>> a state. However, it's important to state that such decisions would >>>> need to be carefully considered and would require some very careful >>>> drafting of proposal to balance the competing interests at hand. >>>> >>>> If anyone is curious, I'm happy to share some ideas offline on what >>>> starting points might be, but I have neither the time nor the interest >>>> to drive such a conversion on list. >>>> >>>> Philip >>>> >>>> On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote: >>>> > During that variable renaming debate, there was a discussion about >>>> discussion about doing things all at once, piecemeal or not at all. An >>>> issue that wasn't really resolved I think. I had the impression that the >>>> efforts fizzled out a bit, and I thought this renaming was maybe related to >>>> that, but I'm neutral on if we should do variable renaming. >>>> > >>>> > All I'm asking as a kindness if we could be kind on poor downstream >>>> maintainers not on the issue of variable renaming at large, but on the >>>> micro level of not pushing 5/6 patches of this kind covering closely >>>> related functionality in two days but collating them in 1. I don't think >>>> that would slow down development, and I wanted to highlight the issue, as >>>> people might not be aware that they could save some pain in a simple way. >>>> Especially if indeed there is going to be a big renaming push and this >>>> would be a continuous thing. >>>> > >>>> > Cheers, >>>> > /Ties >>>> > >>>> > ________________________________________ >>>> > From: Michael Kruse <llvmdev at meinersbur.de> >>>> > Sent: 17 February 2020 21:16 >>>> > To: Ties Stuij >>>> > Cc: llvm-dev >>>> > Subject: Re: [llvm-dev] amount of camelCase refactoring causing some >>>> downstream overhead >>>> > >>>> > My understanding is that LLVM's general policy is to not let >>>> > downstream slow down upstream development. The C++ API explicitly >>>> > unstable. >>>> > >>>> > Note that we are even considering renaming variables globally: >>>> > https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html >>>> > >>>> > Michael >>>> > >>>> > Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via llvm-dev >>>> > <llvm-dev at lists.llvm.org>: >>>> >> Hi there, >>>> >> >>>> >> At the end of last week we saw a number of commits go in that were >>>> camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions. >>>> >> >>>> >> For example: >>>> >> - >>>> https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 >>>> >> - >>>> https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b >>>> >> - >>>> https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 >>>> >> >>>> >> Unfortunately all these individual commits trigger the same merge >>>> conflicts over and over again with our downstream repo, which takes us some >>>> manual intervention every time. >>>> >> >>>> >> I understand uniformity is a nice to have, but: >>>> >> 1 - is it worth it to do this work right now? I can remember the >>>> casing debate a few months back, which seems unrelated to this work which >>>> seems manual, but I'm unsure of the outcome. >>>> >> 2 - If this work should be done, it would be nice if all of the work >>>> is done in one batch, to save us some of the downstream overhead. >>>> >> >>>> >> Thanks >>>> >> /Ties >>>> >> _______________________________________________ >>>> >> LLVM Developers mailing list >>>> >> llvm-dev at lists.llvm.org >>>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> > _______________________________________________ >>>> > LLVM Developers mailing list >>>> > llvm-dev at lists.llvm.org >>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> 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/20200218/a3dd6d6e/attachment.html>
Nicolai Hähnle via llvm-dev
2020-Feb-19 03:07 UTC
[llvm-dev] amount of camelCase refactoring causing some downstream overhead
On Wed, Feb 19, 2020 at 3:22 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote:> I think the somewhat unspoken change in LLVM social conventions (& somewhat policy, I think it's written down in some places) is the "keep patches as small as practically possible" - grouping unrelated renamings would be something I'd usually (without concern for downstream consumers) push back against for all the usual reasons: easier to review, easier to revert strategically if something goes wrong, etc. > > What I'm not clear on is why one big rename patch is easier for a downstream consumer than two smaller renames - I haven't fully understood the nature of this particular downstream consumer's approach makes this interesting.The question that really matters is whether the rename is fully automatic or not. If the rename is done by an automatic script (e.g. clang-tidy based), then the same script can be run "downstream" ahead of merges to avoid virtually all of the conflicts. And if the rename is performed by an automatic script, it seems like it'd actually be simpler for everybody to do it in one big patch, or perhaps one C++ namespace at a time. The biggest remaining problem in this scenario is with *users* of LLVM that call into the C++ API and aim to maintain source-compatibility against multiple versions of LLVM. I currently cannot see how that would work. Full disclaimer about where I'm coming from: We (AMD's graphics compiler) are affected by the rename on two counts: 1) In llvm-project itself, we're upstream (AMDGPU backend), but we do have fairly long-lived internal branches for development against unreleased hardware that are still kept up-to-date with automatic merges multiple times per day. 2) Outside of llvm-project, the compiler frontend (llpc, which is also open-source) also tracks llvm-project master closely and calls into the C++ interface, so would also be affected. (We currently don't attempt to maintain compatibility with multiple versions of LLVM, though it's something that I'd like us to do at some point.) Cheers, Nicolai> > - Dave > >> >> >> -eric >> >> On Tue, Feb 18, 2020 at 4:05 PM Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Valentin, >>> >>> You are proposing to change existing policy. Current policy is that we don't consider downstream *at all*. Your proposal may seem reasonable - it may even *be* reasonable - but it is definitely a change from historical practice and must be considered as such. >>> >>> Philip >>> >>> On 2/18/20 3:03 PM, Valentin Churavy wrote: >>> >>> I don't think anyone is arguing to change longstanding policy. From a downstream perspective many small renaming changes do increase overhead for us. >>> >>> One thing that happens to downstream projects is that they support more than one LLVM version, we (JuliaLang) currently try to support latest stable + master. >>> >>> So for me the question is more, are renaming changes worth downstream projects not being able to test and provide feedback to upstream? One way of mitigating that is to consciously schedule them just before a release and do them all in short succession. >>> >>> -V >>> >>> >>> On Tue, Feb 18, 2020, 17:00 Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>>> >>>> As others have said, our long standing policy has been that downstream >>>> projects must fend for themselves. We're certainly not going to reverse >>>> that policy without careful discussion of the tradeoffs. >>>> >>>> I'm personally of the opinion that there could be a middle ground which >>>> allows upstream to move quickly while reducing headache for downstream >>>> projects. Given I wear both hats, I know I'd certainly appreciate such >>>> a state. However, it's important to state that such decisions would >>>> need to be carefully considered and would require some very careful >>>> drafting of proposal to balance the competing interests at hand. >>>> >>>> If anyone is curious, I'm happy to share some ideas offline on what >>>> starting points might be, but I have neither the time nor the interest >>>> to drive such a conversion on list. >>>> >>>> Philip >>>> >>>> On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote: >>>> > During that variable renaming debate, there was a discussion about discussion about doing things all at once, piecemeal or not at all. An issue that wasn't really resolved I think. I had the impression that the efforts fizzled out a bit, and I thought this renaming was maybe related to that, but I'm neutral on if we should do variable renaming. >>>> > >>>> > All I'm asking as a kindness if we could be kind on poor downstream maintainers not on the issue of variable renaming at large, but on the micro level of not pushing 5/6 patches of this kind covering closely related functionality in two days but collating them in 1. I don't think that would slow down development, and I wanted to highlight the issue, as people might not be aware that they could save some pain in a simple way. Especially if indeed there is going to be a big renaming push and this would be a continuous thing. >>>> > >>>> > Cheers, >>>> > /Ties >>>> > >>>> > ________________________________________ >>>> > From: Michael Kruse <llvmdev at meinersbur.de> >>>> > Sent: 17 February 2020 21:16 >>>> > To: Ties Stuij >>>> > Cc: llvm-dev >>>> > Subject: Re: [llvm-dev] amount of camelCase refactoring causing some downstream overhead >>>> > >>>> > My understanding is that LLVM's general policy is to not let >>>> > downstream slow down upstream development. The C++ API explicitly >>>> > unstable. >>>> > >>>> > Note that we are even considering renaming variables globally: >>>> > https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html >>>> > >>>> > Michael >>>> > >>>> > Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via llvm-dev >>>> > <llvm-dev at lists.llvm.org>: >>>> >> Hi there, >>>> >> >>>> >> At the end of last week we saw a number of commits go in that were camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions. >>>> >> >>>> >> For example: >>>> >> - https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 >>>> >> - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b >>>> >> - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 >>>> >> >>>> >> Unfortunately all these individual commits trigger the same merge conflicts over and over again with our downstream repo, which takes us some manual intervention every time. >>>> >> >>>> >> I understand uniformity is a nice to have, but: >>>> >> 1 - is it worth it to do this work right now? I can remember the casing debate a few months back, which seems unrelated to this work which seems manual, but I'm unsure of the outcome. >>>> >> 2 - If this work should be done, it would be nice if all of the work is done in one batch, to save us some of the downstream overhead. >>>> >> >>>> >> Thanks >>>> >> /Ties >>>> >> _______________________________________________ >>>> >> LLVM Developers mailing list >>>> >> llvm-dev at lists.llvm.org >>>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> > _______________________________________________ >>>> > LLVM Developers mailing list >>>> > llvm-dev at lists.llvm.org >>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.
Philip Reames via llvm-dev
2020-Feb-19 19:07 UTC
[llvm-dev] amount of camelCase refactoring causing some downstream overhead
Eric, I disagree. Strongly. I see the very fact we're engaging in the discussion of "just being polite" here as normalizing a proposed change in policy which has potentially profound negative consequences for the project long term. I do not want upstream developers "trying to be polite" if that delays otherwise worthwhile work. The current policy is "downstream is on their own". There was nothing even remotely unreasonable done in the patch series which triggered this discussion and I don't want any upstream contributor coming to believe there was. Again, I'm open to carefully weighted proposals to change current policy. I also have a downstream repo which is kept up to date and I understand the pain point being raised. I just want to be very careful to distinguish between existing status, and any proposed changes. I want the proposed changes to be carefully weighed before being put into effect. Philip On 2/18/20 4:39 PM, Eric Christopher wrote:> Hi Philip, > > While it's true we don't I think Valentin is reasonable in saying > "hey, when people do this let's try to combine them if it makes > sense". It's just being polite to everyone, especially if it doesn't > risk the patches or upstream stability. I don't think there's a policy > change being proposed, just a "hey, let's see what we can do in the > future". > > -eric > > On Tue, Feb 18, 2020 at 4:05 PM Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Valentin, > > You are proposing to change existing policy. Current policy is > that we don't consider downstream *at all*. Your proposal may seem > reasonable - it may even *be* reasonable - but it is definitely a > change from historical practice and must be considered as such. > > Philip > > On 2/18/20 3:03 PM, Valentin Churavy wrote: >> I don't think anyone is arguing to change longstanding policy. >> From a downstream perspective many small renaming changes do >> increase overhead for us. >> >> One thing that happens to downstream projects is that they >> support more than one LLVM version, we (JuliaLang) currently try >> to support latest stable + master. >> >> So for me the question is more, are renaming changes worth >> downstream projects not being able to test and provide feedback >> to upstream? One way of mitigating that is to consciously >> schedule them just before a release and do them all in short >> succession. >> >> -V >> >> >> On Tue, Feb 18, 2020, 17:00 Philip Reames via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> As others have said, our long standing policy has been that >> downstream >> projects must fend for themselves. We're certainly not going >> to reverse >> that policy without careful discussion of the tradeoffs. >> >> I'm personally of the opinion that there could be a middle >> ground which >> allows upstream to move quickly while reducing headache for >> downstream >> projects. Given I wear both hats, I know I'd certainly >> appreciate such >> a state. However, it's important to state that such >> decisions would >> need to be carefully considered and would require some very >> careful >> drafting of proposal to balance the competing interests at hand. >> >> If anyone is curious, I'm happy to share some ideas offline >> on what >> starting points might be, but I have neither the time nor the >> interest >> to drive such a conversion on list. >> >> Philip >> >> On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote: >> > During that variable renaming debate, there was a >> discussion about discussion about doing things all at once, >> piecemeal or not at all. An issue that wasn't really resolved >> I think. I had the impression that the efforts fizzled out a >> bit, and I thought this renaming was maybe related to that, >> but I'm neutral on if we should do variable renaming. >> > >> > All I'm asking as a kindness if we could be kind on poor >> downstream maintainers not on the issue of variable renaming >> at large, but on the micro level of not pushing 5/6 patches >> of this kind covering closely related functionality in two >> days but collating them in 1. I don't think that would slow >> down development, and I wanted to highlight the issue, as >> people might not be aware that they could save some pain in a >> simple way. Especially if indeed there is going to be a big >> renaming push and this would be a continuous thing. >> > >> > Cheers, >> > /Ties >> > >> > ________________________________________ >> > From: Michael Kruse <llvmdev at meinersbur.de >> <mailto:llvmdev at meinersbur.de>> >> > Sent: 17 February 2020 21:16 >> > To: Ties Stuij >> > Cc: llvm-dev >> > Subject: Re: [llvm-dev] amount of camelCase refactoring >> causing some downstream overhead >> > >> > My understanding is that LLVM's general policy is to not let >> > downstream slow down upstream development. The C++ API >> explicitly >> > unstable. >> > >> > Note that we are even considering renaming variables globally: >> > >> https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html >> > >> > Michael >> > >> > Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via >> llvm-dev >> > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: >> >> Hi there, >> >> >> >> At the end of last week we saw a number of commits go in >> that were camelCasing batches of MCStreamer::Emit* and >> AsmPrinter::Emit* functions. >> >> >> >> For example: >> >> - >> https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 >> >> - >> https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b >> >> - >> https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 >> >> >> >> Unfortunately all these individual commits trigger the >> same merge conflicts over and over again with our downstream >> repo, which takes us some manual intervention every time. >> >> >> >> I understand uniformity is a nice to have, but: >> >> 1 - is it worth it to do this work right now? I can >> remember the casing debate a few months back, which seems >> unrelated to this work which seems manual, but I'm unsure of >> the outcome. >> >> 2 - If this work should be done, it would be nice if all >> of the work is done in one batch, to save us some of the >> downstream overhead. >> >> >> >> Thanks >> >> /Ties >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ >> > LLVM Developers mailing list >> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto: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/20200219/acf5312f/attachment.html>
Eric Christopher via llvm-dev
2020-Feb-19 19:25 UTC
[llvm-dev] amount of camelCase refactoring causing some downstream overhead
Hi Philip, You and I are going to disagree then. Strongly and strenuously every time. As someone who has reiterated the same policy multiple times I don't see anything around "try to make it easy on downstream if you can without making it harder for upstream" that contradicts any policy or even tries to set anything. There is no policy under discussion, just a "hey, see if you can do this in a friendly way" next time is just fine. If you and I can't agree on that then I really see no point in discussing anything further with you. -eric On Wed, Feb 19, 2020 at 11:07 AM Philip Reames <listmail at philipreames.com> wrote:> Eric, > > I disagree. Strongly. I see the very fact we're engaging in the > discussion of "just being polite" here as normalizing a proposed change in > policy which has potentially profound negative consequences for the project > long term. I do not want upstream developers "trying to be polite" if that > delays otherwise worthwhile work. The current policy is "downstream is on > their own". There was nothing even remotely unreasonable done in the patch > series which triggered this discussion and I don't want any upstream > contributor coming to believe there was. > > Again, I'm open to carefully weighted proposals to change current policy. > I also have a downstream repo which is kept up to date and I understand the > pain point being raised. I just want to be very careful to distinguish > between existing status, and any proposed changes. I want the proposed > changes to be carefully weighed before being put into effect. > > Philip > On 2/18/20 4:39 PM, Eric Christopher wrote: > > Hi Philip, > > While it's true we don't I think Valentin is reasonable in saying "hey, > when people do this let's try to combine them if it makes sense". It's just > being polite to everyone, especially if it doesn't risk the patches or > upstream stability. I don't think there's a policy change being proposed, > just a "hey, let's see what we can do in the future". > > -eric > > On Tue, Feb 18, 2020 at 4:05 PM Philip Reames via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Valentin, >> >> You are proposing to change existing policy. Current policy is that we >> don't consider downstream *at all*. Your proposal may seem reasonable - it >> may even *be* reasonable - but it is definitely a change from historical >> practice and must be considered as such. >> >> Philip >> On 2/18/20 3:03 PM, Valentin Churavy wrote: >> >> I don't think anyone is arguing to change longstanding policy. From a >> downstream perspective many small renaming changes do increase overhead for >> us. >> >> One thing that happens to downstream projects is that they support more >> than one LLVM version, we (JuliaLang) currently try to support latest >> stable + master. >> >> So for me the question is more, are renaming changes worth downstream >> projects not being able to test and provide feedback to upstream? One way >> of mitigating that is to consciously schedule them just before a release >> and do them all in short succession. >> >> -V >> >> >> On Tue, Feb 18, 2020, 17:00 Philip Reames via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> As others have said, our long standing policy has been that downstream >>> projects must fend for themselves. We're certainly not going to reverse >>> that policy without careful discussion of the tradeoffs. >>> >>> I'm personally of the opinion that there could be a middle ground which >>> allows upstream to move quickly while reducing headache for downstream >>> projects. Given I wear both hats, I know I'd certainly appreciate such >>> a state. However, it's important to state that such decisions would >>> need to be carefully considered and would require some very careful >>> drafting of proposal to balance the competing interests at hand. >>> >>> If anyone is curious, I'm happy to share some ideas offline on what >>> starting points might be, but I have neither the time nor the interest >>> to drive such a conversion on list. >>> >>> Philip >>> >>> On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote: >>> > During that variable renaming debate, there was a discussion about >>> discussion about doing things all at once, piecemeal or not at all. An >>> issue that wasn't really resolved I think. I had the impression that the >>> efforts fizzled out a bit, and I thought this renaming was maybe related to >>> that, but I'm neutral on if we should do variable renaming. >>> > >>> > All I'm asking as a kindness if we could be kind on poor downstream >>> maintainers not on the issue of variable renaming at large, but on the >>> micro level of not pushing 5/6 patches of this kind covering closely >>> related functionality in two days but collating them in 1. I don't think >>> that would slow down development, and I wanted to highlight the issue, as >>> people might not be aware that they could save some pain in a simple way. >>> Especially if indeed there is going to be a big renaming push and this >>> would be a continuous thing. >>> > >>> > Cheers, >>> > /Ties >>> > >>> > ________________________________________ >>> > From: Michael Kruse <llvmdev at meinersbur.de> >>> > Sent: 17 February 2020 21:16 >>> > To: Ties Stuij >>> > Cc: llvm-dev >>> > Subject: Re: [llvm-dev] amount of camelCase refactoring causing some >>> downstream overhead >>> > >>> > My understanding is that LLVM's general policy is to not let >>> > downstream slow down upstream development. The C++ API explicitly >>> > unstable. >>> > >>> > Note that we are even considering renaming variables globally: >>> > https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html >>> > >>> > Michael >>> > >>> > Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via llvm-dev >>> > <llvm-dev at lists.llvm.org>: >>> >> Hi there, >>> >> >>> >> At the end of last week we saw a number of commits go in that were >>> camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions. >>> >> >>> >> For example: >>> >> - https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 >>> >> - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b >>> >> - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 >>> >> >>> >> Unfortunately all these individual commits trigger the same merge >>> conflicts over and over again with our downstream repo, which takes us some >>> manual intervention every time. >>> >> >>> >> I understand uniformity is a nice to have, but: >>> >> 1 - is it worth it to do this work right now? I can remember the >>> casing debate a few months back, which seems unrelated to this work which >>> seems manual, but I'm unsure of the outcome. >>> >> 2 - If this work should be done, it would be nice if all of the work >>> is done in one batch, to save us some of the downstream overhead. >>> >> >>> >> Thanks >>> >> /Ties >>> >> _______________________________________________ >>> >> LLVM Developers mailing list >>> >> llvm-dev at lists.llvm.org >>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> > _______________________________________________ >>> > LLVM Developers mailing list >>> > llvm-dev at lists.llvm.org >>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> 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/20200219/5f69b650/attachment.html>
Robinson, Paul via llvm-dev
2020-Feb-19 20:10 UTC
[llvm-dev] amount of camelCase refactoring causing some downstream overhead
Hi Philip, I think you might be reading more into the suggestion/discussion than is actually there. * I do not want upstream developers "trying to be polite" if that delays otherwise worthwhile work. Nobody suggested that. It’s perfectly possible to “be polite” and still not delay worthwhile work. * The current policy is "downstream is on their own". Nobody disputes that. * There was nothing even remotely unreasonable done in the patch series which triggered this discussion and I don't want any upstream contributor coming to believe there was. I disagree with you about “nothing even remotely unreasonable” in that I think it was done slightly unreasonably, and I think it’s worthwhile to have other upstream contributors acknowledge that feeling. What I’m aware of is a series of 5 separate patches, each of which re-capitalized a select subset of APIs in the same area. This fixing-up is *long overdue* and I’m very happy to see it done. But I will dispute the “reasonableness” of doing it in 5 separate stages (plus a few other related cleanups that were not simply re-capitalizing existing names). The notion of “reviewable size” is not relevant, because these patches were not reviewed (in accordance with current policy, that this kind of mechanical fixup is “obvious” and does not require pre-commit review). The patches were not really very distinct, with a HUGE overlap in the set of affected files. We do like to minimize churn; this kind of fixup clearly qualifies as churn, but I respectfully submit that the way it was done does not *minimize* the churn. And minimizing the churn is good for both the project and those of us who live downstream of it. --paulr From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Philip Reames via llvm-dev Sent: Wednesday, February 19, 2020 2:07 PM To: Eric Christopher <echristo at gmail.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Valentin Churavy <v.churavy at gmail.com> Subject: Re: [llvm-dev] amount of camelCase refactoring causing some downstream overhead Eric, I disagree. Strongly. I see the very fact we're engaging in the discussion of "just being polite" here as normalizing a proposed change in policy which has potentially profound negative consequences for the project long term. I do not want upstream developers "trying to be polite" if that delays otherwise worthwhile work. The current policy is "downstream is on their own". There was nothing even remotely unreasonable done in the patch series which triggered this discussion and I don't want any upstream contributor coming to believe there was. Again, I'm open to carefully weighted proposals to change current policy. I also have a downstream repo which is kept up to date and I understand the pain point being raised. I just want to be very careful to distinguish between existing status, and any proposed changes. I want the proposed changes to be carefully weighed before being put into effect. Philip On 2/18/20 4:39 PM, Eric Christopher wrote: Hi Philip, While it's true we don't I think Valentin is reasonable in saying "hey, when people do this let's try to combine them if it makes sense". It's just being polite to everyone, especially if it doesn't risk the patches or upstream stability. I don't think there's a policy change being proposed, just a "hey, let's see what we can do in the future". -eric On Tue, Feb 18, 2020 at 4:05 PM Philip Reames via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Valentin, You are proposing to change existing policy. Current policy is that we don't consider downstream *at all*. Your proposal may seem reasonable - it may even *be* reasonable - but it is definitely a change from historical practice and must be considered as such. Philip On 2/18/20 3:03 PM, Valentin Churavy wrote: I don't think anyone is arguing to change longstanding policy. From a downstream perspective many small renaming changes do increase overhead for us. One thing that happens to downstream projects is that they support more than one LLVM version, we (JuliaLang) currently try to support latest stable + master. So for me the question is more, are renaming changes worth downstream projects not being able to test and provide feedback to upstream? One way of mitigating that is to consciously schedule them just before a release and do them all in short succession. -V On Tue, Feb 18, 2020, 17:00 Philip Reames via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: As others have said, our long standing policy has been that downstream projects must fend for themselves. We're certainly not going to reverse that policy without careful discussion of the tradeoffs. I'm personally of the opinion that there could be a middle ground which allows upstream to move quickly while reducing headache for downstream projects. Given I wear both hats, I know I'd certainly appreciate such a state. However, it's important to state that such decisions would need to be carefully considered and would require some very careful drafting of proposal to balance the competing interests at hand. If anyone is curious, I'm happy to share some ideas offline on what starting points might be, but I have neither the time nor the interest to drive such a conversion on list. Philip On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote:> During that variable renaming debate, there was a discussion about discussion about doing things all at once, piecemeal or not at all. An issue that wasn't really resolved I think. I had the impression that the efforts fizzled out a bit, and I thought this renaming was maybe related to that, but I'm neutral on if we should do variable renaming. > > All I'm asking as a kindness if we could be kind on poor downstream maintainers not on the issue of variable renaming at large, but on the micro level of not pushing 5/6 patches of this kind covering closely related functionality in two days but collating them in 1. I don't think that would slow down development, and I wanted to highlight the issue, as people might not be aware that they could save some pain in a simple way. Especially if indeed there is going to be a big renaming push and this would be a continuous thing. > > Cheers, > /Ties > > ________________________________________ > From: Michael Kruse <llvmdev at meinersbur.de<mailto:llvmdev at meinersbur.de>> > Sent: 17 February 2020 21:16 > To: Ties Stuij > Cc: llvm-dev > Subject: Re: [llvm-dev] amount of camelCase refactoring causing some downstream overhead > > My understanding is that LLVM's general policy is to not let > downstream slow down upstream development. The C++ API explicitly > unstable. > > Note that we are even considering renaming variables globally: > https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html > > Michael > > Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via llvm-dev > <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>: >> Hi there, >> >> At the end of last week we saw a number of commits go in that were camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions. >> >> For example: >> - https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 >> - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b >> - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 >> >> Unfortunately all these individual commits trigger the same merge conflicts over and over again with our downstream repo, which takes us some manual intervention every time. >> >> I understand uniformity is a nice to have, but: >> 1 - is it worth it to do this work right now? I can remember the casing debate a few months back, which seems unrelated to this work which seems manual, but I'm unsure of the outcome. >> 2 - If this work should be done, it would be nice if all of the work is done in one batch, to save us some of the downstream overhead. >> >> Thanks >> /Ties >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev_______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto: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/20200219/c1043a92/attachment.html>
Neil Nelson via llvm-dev
2020-Feb-19 20:24 UTC
[llvm-dev] amount of camelCase refactoring causing some downstream overhead
Philip, This statement "The current policy is "downstream is on their own"." appears to have gotten out of hand. LLVM for this thread is a production line, a pipeline, a team operation. Of course each person in the team has their own responsibility but there is never a team member who is on their own. There is never a position on the production line that does not depend on all the other positions in order to keep the production line running. At some point all the members depend on and are responsible for all the other members and for the success of the team. This is not policy. It is merely a fact of life for this kind of organization. Neil Nelson On 2/19/20 12:07 PM, Philip Reames via llvm-dev wrote:> > Eric, > > I disagree. Strongly. I see the very fact we're engaging in the > discussion of "just being polite" here as normalizing a proposed > change in policy which has potentially profound negative consequences > for the project long term. I do not want upstream developers "trying > to be polite" if that delays otherwise worthwhile work. The current > policy is "downstream is on their own". There was nothing even > remotely unreasonable done in the patch series which triggered this > discussion and I don't want any upstream contributor coming to believe > there was. > > Again, I'm open to carefully weighted proposals to change current > policy. I also have a downstream repo which is kept up to date and I > understand the pain point being raised. I just want to be very > careful to distinguish between existing status, and any proposed > changes. I want the proposed changes to be carefully weighed before > being put into effect. > > Philip > > On 2/18/20 4:39 PM, Eric Christopher wrote: >> Hi Philip, >> >> While it's true we don't I think Valentin is reasonable in saying >> "hey, when people do this let's try to combine them if it makes >> sense". It's just being polite to everyone, especially if it doesn't >> risk the patches or upstream stability. I don't think there's a >> policy change being proposed, just a "hey, let's see what we can do >> in the future". >> >> -eric >> >> On Tue, Feb 18, 2020 at 4:05 PM Philip Reames via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Valentin, >> >> You are proposing to change existing policy. Current policy is >> that we don't consider downstream *at all*. Your proposal may >> seem reasonable - it may even *be* reasonable - but it is >> definitely a change from historical practice and must be >> considered as such. >> >> Philip >> >> On 2/18/20 3:03 PM, Valentin Churavy wrote: >>> I don't think anyone is arguing to change longstanding policy. >>> From a downstream perspective many small renaming changes do >>> increase overhead for us. >>> >>> One thing that happens to downstream projects is that they >>> support more than one LLVM version, we (JuliaLang) currently try >>> to support latest stable + master. >>> >>> So for me the question is more, are renaming changes worth >>> downstream projects not being able to test and provide feedback >>> to upstream? One way of mitigating that is to consciously >>> schedule them just before a release and do them all in short >>> succession. >>> >>> -V >>> >>> >>> On Tue, Feb 18, 2020, 17:00 Philip Reames via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> As others have said, our long standing policy has been that >>> downstream >>> projects must fend for themselves. We're certainly not >>> going to reverse >>> that policy without careful discussion of the tradeoffs. >>> >>> I'm personally of the opinion that there could be a middle >>> ground which >>> allows upstream to move quickly while reducing headache for >>> downstream >>> projects. Given I wear both hats, I know I'd certainly >>> appreciate such >>> a state. However, it's important to state that such >>> decisions would >>> need to be carefully considered and would require some very >>> careful >>> drafting of proposal to balance the competing interests at hand. >>> >>> If anyone is curious, I'm happy to share some ideas offline >>> on what >>> starting points might be, but I have neither the time nor >>> the interest >>> to drive such a conversion on list. >>> >>> Philip >>> >>> On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote: >>> > During that variable renaming debate, there was a >>> discussion about discussion about doing things all at once, >>> piecemeal or not at all. An issue that wasn't really >>> resolved I think. I had the impression that the efforts >>> fizzled out a bit, and I thought this renaming was maybe >>> related to that, but I'm neutral on if we should do variable >>> renaming. >>> > >>> > All I'm asking as a kindness if we could be kind on poor >>> downstream maintainers not on the issue of variable renaming >>> at large, but on the micro level of not pushing 5/6 patches >>> of this kind covering closely related functionality in two >>> days but collating them in 1. I don't think that would slow >>> down development, and I wanted to highlight the issue, as >>> people might not be aware that they could save some pain in >>> a simple way. Especially if indeed there is going to be a >>> big renaming push and this would be a continuous thing. >>> > >>> > Cheers, >>> > /Ties >>> > >>> > ________________________________________ >>> > From: Michael Kruse <llvmdev at meinersbur.de >>> <mailto:llvmdev at meinersbur.de>> >>> > Sent: 17 February 2020 21:16 >>> > To: Ties Stuij >>> > Cc: llvm-dev >>> > Subject: Re: [llvm-dev] amount of camelCase refactoring >>> causing some downstream overhead >>> > >>> > My understanding is that LLVM's general policy is to not let >>> > downstream slow down upstream development. The C++ API >>> explicitly >>> > unstable. >>> > >>> > Note that we are even considering renaming variables globally: >>> > >>> https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html >>> > >>> > Michael >>> > >>> > Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via >>> llvm-dev >>> > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: >>> >> Hi there, >>> >> >>> >> At the end of last week we saw a number of commits go in >>> that were camelCasing batches of MCStreamer::Emit* and >>> AsmPrinter::Emit* functions. >>> >> >>> >> For example: >>> >> - >>> https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 >>> >> - >>> https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b >>> >> - >>> https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 >>> >> >>> >> Unfortunately all these individual commits trigger the >>> same merge conflicts over and over again with our downstream >>> repo, which takes us some manual intervention every time. >>> >> >>> >> I understand uniformity is a nice to have, but: >>> >> 1 - is it worth it to do this work right now? I can >>> remember the casing debate a few months back, which seems >>> unrelated to this work which seems manual, but I'm unsure of >>> the outcome. >>> >> 2 - If this work should be done, it would be nice if all >>> of the work is done in one batch, to save us some of the >>> downstream overhead. >>> >> >>> >> Thanks >>> >> /Ties >>> >> _______________________________________________ >>> >> LLVM Developers mailing list >>> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> > _______________________________________________ >>> > LLVM Developers mailing list >>> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > _______________________________________________ > 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/20200219/6e051d5f/attachment.html>
Seemingly Similar Threads
- amount of camelCase refactoring causing some downstream overhead
- amount of camelCase refactoring causing some downstream overhead
- amount of camelCase refactoring causing some downstream overhead
- amount of camelCase refactoring causing some downstream overhead
- amount of camelCase refactoring causing some downstream overhead