[llvm-dev] Target Acceptance Policy
Gerolf Hoflehner via llvm-dev
llvm-dev at lists.llvm.org
Tue Jul 26 17:21:14 PDT 2016
> 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.
> 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...
More information about the llvm-dev