----- Original Message -----> From: "Renato Golin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Mehdi Amini" <mehdi.amini at apple.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, July 26, 2016 12:40:58 PM > Subject: Re: [llvm-dev] Target Acceptance Policy > > On 26 July 2016 at 18:33, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> This gives them time > >> to address all comments with our help. We want targets as much as > >> they > >> want to be in LLVM. It's a cooperation and acting inflexibly won't > >> help anyone. > > > > I believe that it helps everyone on the opposite. > > I'm sorry, but I'll never subscribe to inflexibility, no matter the > argument.I think there are different kinds of inflexibility. We will use our collective professional judgment. There are some large-scale design changes that we might decide can happen over time. Whatever we decide to accept, however, needs to be in good shape for what it is and follow our coding conventions. -Hal> > I think we have reached the point where the conversation is less > useful because the assumptions are radically opposing. > > I want to hear other people's opinions, too, so we can reach a > consensus, not just the opinions of two loud guys talking. :) > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
On 26 July 2016 at 20:07, Hal Finkel <hfinkel at anl.gov> wrote:> I think there are different kinds of inflexibility. We will use our collective professional judgment. There are some large-scale design changes that we might decide can happen over time. Whatever we decide to accept, however, needs to be in good shape for what it is and follow our coding conventions.Absolutely. There is a large range of solutions, and we have been most successful on the ones we picked over the years. I think we should continue with the trend. What (I think) I have proposed is nothing different than what we've been doing (ie. I'm not trying to change the status quo). So, if that's not what's coming out, my wording is wrong, please advise. If it is, than I don't think we should argue *now*. I just want to encode what is, and then, once we have something in, working and actively helping people add their targets, we can discuss (in separate) the merits of our current policies. Maybe I should have said that from the beginning. Oh well, hind sight and all. --renato
> On Jul 26, 2016, at 12:16 PM, Renato Golin <renato.golin at linaro.org> wrote: > > On 26 July 2016 at 20:07, Hal Finkel <hfinkel at anl.gov> wrote: >> I think there are different kinds of inflexibility. We will use our collective professional judgment. There are some large-scale design changes that we might decide can happen over time. Whatever we decide to accept, however, needs to be in good shape for what it is and follow our coding conventions. > > Absolutely. There is a large range of solutions, and we have been most > successful on the ones we picked over the years. I think we should > continue with the trend. > > What (I think) I have proposed is nothing different than what we've > been doing (ie. I'm not trying to change the status quo). > > So, if that's not what's coming out, my wording is wrong, please > advise. If it is, than I don't think we should argue *now*. > > I just want to encode what is, and then, once we have something in, > working and actively helping people add their targets, we can discuss > (in separate) the merits of our current policies.IIUC you are writing specifically that an experimental backend can be integrated without conforming to http://llvm.org/docs/DeveloperPolicy.html#quality <http://llvm.org/docs/DeveloperPolicy.html#quality> ; I don’t think this is a current “policy” but your writing is making it a policy AFAICT. — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160726/e89d0fbb/attachment.html>
> On Jul 26, 2016, at 12:16 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 26 July 2016 at 20:07, Hal Finkel <hfinkel at anl.gov> wrote: >> I think there are different kinds of inflexibility. We will use our collective professional judgment. There are some large-scale design changes that we might decide can happen over time. Whatever we decide to accept, however, needs to be in good shape for what it is and follow our coding conventions. > > Absolutely. There is a large range of solutions, and we have been most > successful on the ones we picked over the years. I think we should > continue with the trend. > > What (I think) I have proposed is nothing different than what we've > been doing (ie. I'm not trying to change the status quo).All this is really good. Do you also have thoughts on guidelines for accessibility to bots and debugging support? When a patch causes failures on bots testing a backend, what support do you expect to help root cause the issue? This can be a big burden on developers not familiar with an architecture.> > So, if that's not what's coming out, my wording is wrong, please > advise. If it is, than I don't think we should argue *now*. > > I just want to encode what is, and then, once we have something in, > working and actively helping people add their targets, we can discuss > (in separate) the merits of our current policies. > > Maybe I should have said that from the beginning. Oh well, hind sight and all. > > --renato > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hi Gerolf, This is more the third stage, "how to be good target maintainers". I think we could add a few guidelines somewhere, as I agree this is really important, but maybe not in this section. I imagined this as a minimum requirements section, not as a guidelines. Though, we could think as public CI maintenance as a minimum requirement for target maintainers,too. I'm open to suggestions... Cheers, Renato On 26 Jul 2016 11:41 p.m., "Gerolf Hoflehner" <ghoflehner at apple.com> wrote:> On Jul 26, 2016, at 12:16 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On 26 July 2016 at 20:07, Hal Finkel <hfinkel at anl.gov> wrote: >> I think there are different kinds of inflexibility. We will use ourcollective professional judgment. There are some large-scale design changes that we might decide can happen over time. Whatever we decide to accept, however, needs to be in good shape for what it is and follow our coding conventions.> > Absolutely. There is a large range of solutions, and we have been most > successful on the ones we picked over the years. I think we should > continue with the trend. > > What (I think) I have proposed is nothing different than what we've > been doing (ie. I'm not trying to change the status quo).All this is really good. Do you also have thoughts on guidelines for accessibility to bots and debugging support? When a patch causes failures on bots testing a backend, what support do you expect to help root cause the issue? This can be a big burden on developers not familiar with an architecture.> > So, if that's not what's coming out, my wording is wrong, please > advise. If it is, than I don't think we should argue *now*. > > I just want to encode what is, and then, once we have something in, > working and actively helping people add their targets, we can discuss > (in separate) the merits of our current policies. > > Maybe I should have said that from the beginning. Oh well, hind sight andall.> > --renato > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://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/20160727/5c12905c/attachment.html>
----- Original Message -----> From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org>, "Mehdi Amini" <mehdi.amini at apple.com> > Sent: Tuesday, July 26, 2016 2:16:51 PM > Subject: Re: [llvm-dev] Target Acceptance Policy > > On 26 July 2016 at 20:07, Hal Finkel <hfinkel at anl.gov> wrote: > > I think there are different kinds of inflexibility. We will use our > > collective professional judgment. There are some large-scale > > design changes that we might decide can happen over time. Whatever > > we decide to accept, however, needs to be in good shape for what > > it is and follow our coding conventions. > > Absolutely. There is a large range of solutions, and we have been > most > successful on the ones we picked over the years. I think we should > continue with the trend. > > What (I think) I have proposed is nothing different than what we've > been doing (ie. I'm not trying to change the status quo).Sure; have we accepted backends in the recent past which contained code that did not meet our coding conventions? -Hal> > So, if that's not what's coming out, my wording is wrong, please > advise. If it is, than I don't think we should argue *now*. > > I just want to encode what is, and then, once we have something in, > working and actively helping people add their targets, we can discuss > (in separate) the merits of our current policies. > > Maybe I should have said that from the beginning. Oh well, hind sight > and all. > > --renato >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
> On Jul 26, 2016, at 4:40 PM, Renato Golin <renato.golin at linaro.org> wrote: > > Hi Gerolf, > > This is more the third stage, "how to be good target maintainers". I think we could add a few guidelines somewhere, as I agree this is really important, but maybe not in this section. > > I imagined this as a minimum requirements section, not as a guidelines. Though, we could think as public CI maintenance as a minimum requirement for target maintainers,too. > > I'm open to suggestions… >I could see the expectation for future maintenance as part to the requirements. I understand this would expand your intent to cover (aspects) of the entire backend lifecycle. But I feel that this is important to be explicit about and have it documented.> Cheers, > Renato > > > On 26 Jul 2016 11:41 p.m., "Gerolf Hoflehner" <ghoflehner at apple.com <mailto:ghoflehner at apple.com>> wrote: > > > On Jul 26, 2016, at 12:16 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On 26 July 2016 at 20:07, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: > >> I think there are different kinds of inflexibility. We will use our collective professional judgment. There are some large-scale design changes that we might decide can happen over time. Whatever we decide to accept, however, needs to be in good shape for what it is and follow our coding conventions. > > > > Absolutely. There is a large range of solutions, and we have been most > > successful on the ones we picked over the years. I think we should > > continue with the trend. > > > > What (I think) I have proposed is nothing different than what we've > > been doing (ie. I'm not trying to change the status quo). > > All this is really good. Do you also have thoughts on guidelines for accessibility to bots and debugging support? When a patch causes failures on bots testing a backend, what support do you expect to help root cause the issue? This can be a big burden on developers not familiar with an architecture. > > > > So, if that's not what's coming out, my wording is wrong, please > > advise. If it is, than I don't think we should argue *now*. > > > > I just want to encode what is, and then, once we have something in, > > working and actively helping people add their targets, we can discuss > > (in separate) the merits of our current policies. > > > > Maybe I should have said that from the beginning. Oh well, hind sight and all. > > > > --renato > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://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/20160726/14867b12/attachment.html>