[llvm-commits] RFC: LLVM incubation, or requirements for committing new backends

[Tom Stellard]

On Mon, Jul 16, 2012 at 11:44:25AM -0700, Owen Anderson wrote:
> Tom,
> 
> I think it might be productive to fork this thread to discuss making the requirements for upstreaming a new LLVM target more explicit and open.  I'd also like to gauge interest in an idea I've discussed privately with a few community members, namely the concept of having a semi-official "incubation" system whereby proposed backends could get a trial run before becoming part of LLVM mainline.
> 
> The proposed system would be something like this: a proposed contribution would receive a branch on llvm.org, and have six months (or some other predetermined length of time) to demonstrate that it and its developers are ready for mainline integration.  At the end of their term, incubated projects would be evaluated on the following criteria, and either integrated to mainline, judged to be more appropriate as an external project, or given an extension and "needs improvement" feedback on specific criteria.
> 
> * Active maintainership - Backends bit rot quickly, and unmaintained backends are large maintenance burden on everyone else.  We need a core of developers who are going to actively maintain any candidate backend on mainline.  That last point is critical: a code drop every six months is not an acceptable level of maintenance for a mainline target.
> 
> * Contributions to core - Mainlining a new backend adds the expectation that mainline LLVM developers will invest the time and energy to keep your backend building and working (see test plan, below).  However, that expectation of extra work doesn't come for nothing: we expect you to contribute back fixes and improvements that you find, and to work with other community members to coordinate projects as appropriate.  When looking at a new backend, I should expect to see few-to-no diffs outside of lib/Target/YourBackend, and a few other places (Triple.cpp, for example).  All other changes should already be upstreamed.
> 
> * Test plan - If you're going to expect us to maintain and fix your code, then you need to have a good answer to how to test it.  This includes, but is not limited to, a good set of regression tests that are comprehensible to normal developers (so we can fix them when they fail due to mainline change), and continuous testing in the form of buildbots or other infrastructure (so we can know when a patch breaks your backend).
> 
> * Up to date with mainline - All mainline backends must work with top-of-tree LLVM, all of the time.  A candidate for inclusion must be developed at, or close to, mainline.  In practice, that probably means updating at least once a week, possibly more.
> 
> * LLVM coding standards - While small deviations can be fixed after mainlining, gross violations of the LLVM code standards and conventions must be fixed prior to integration.
> 
> ---
> 
> So, what would the community think of implementing such a system?
> 
> --Owen
> 

Hi Owen,

I am in favor of this.  I think having specific criteria and time lines
will be beneficial for both maintainers and reviewers.

However, instead of having a separate branch, what do you think about
adding the backend to the main tree, but not building it by default.
This would make it easier for the backend maintainer to keep it up to
date and also make it easier for users to test it.  At the same time,
the backend maintainer would still be responsible for updating it for
changes to the LLVM core API, so other developers wouldn't need to worry
about breaking the "backend-in-training".

-Tom