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

[Villmow, Micah]

Owen,
 This sounds like a good idea, but really anything that allows code to progress forward towards
inclusion into the tree is in my view better than what we have right now. As Tom has stated,
 he has been trying to get his backend in for the past 3 and a half months, give or take a few weeks, and
it seemed like progress had stalled. 

What is the difference between the incubator approach and having a backend part of the tree, but disabled by default(i.e. not part of the high level cmake file)?

In my view, the biggest bottleneck to development is just getting the source public and in the tree in the first place.

Maybe something like this would be acceptable?

- Experimental/incubating backends are part of the tree(or a separate branch that can overlay onto mainline and build without issue similar to tests).
- The backends are not enabled by default nor can they be selected via cmake without editing the cmake files directly.
- Someone in the LLVM community is designated as the advisor to the backend to make sure it conforms to LLVM standards.
- Once the backend has been sufficiently vetted, it is enabled by default(or merged in from the experimental branch).

The good part that I see with this approach is that the first big bottleneck is dealt with, without putting extraneous demands
on the mainline developers. Since the backend is disabled by default and not tested, it is up to the backend maintainers
to fix any build related issues when they occur. It would then allow the community to see the developers who are interested in
properly maintaining their backends versus the ones that want to dump and forget.

It helps the people who want to push the backend out by giving them access to LLVM community/tree, but in a limited capacity.
It helps the people who want to use the backend by allowing them to relatively easily build the backend with only minor modifications to the tree.
It helps LLVM by giving a clearly defined method for moving forward when a new backend wants to be added.

Also I think there needs to be a process for deprecating/removing backends. Right now I believe it isn't set in stone when or how this is decided.

So, what do you think?
Micah

> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-
> bounces at cs.uiuc.edu] On Behalf Of Owen Anderson
> Sent: Tuesday, July 17, 2012 9:51 AM
> To: Duncan Sands
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: [llvm-commits] RFC: LLVM incubation, or requirements for
> committing new backends
> 
> Hi Duncan,
> 
> On Jul 17, 2012, at 1:00 AM, Duncan Sands <baldrick at free.fr> wrote:
> 
> > so this would be something like the linux kernel's "staging" tree?
> > Well, why not.  However another important thing which I think should
> > be extended is the notion of "code owners" (corresponding more or less
> > to the linux kernel's subsystem maintainers).  Who is the code owner
> > for backends in general?  Maybe Evan or Anton?  A new backend
> shouldn't go in unless OK'd by that code owner.
> > But who knows who the right person is?  I think we need to designate
> > code owners for all major subsystems, and list them in some easy to
> > find place.  One problem people have when they send in patches but
> > don't get any review is that they don't know who to turn to.  They
> > should turn to the code owner, and part of the code owner's
> > responsibility should be to take action in such cases (which may just
> > mean delegating the review work to someone else).  Currently they
> often turn to Chris, but Chris doesn't scale.
> 
> I'm not familiar with Linux's staging tree.  I had Apache Incubator in
> mind when I wrote the concept.
> 
> I have to admit, I'm somewhat skeptical of the how well our system of
> code ownership has work out in the past, and I'm not sure it will scale
> well into the future.  It seems like the code ownership scopes, as
> defined in the past, were so broad as to be meaningless, since those
> people designated owners could not realistically review every patch in
> their assigned part of the codebase.
> 
> An alternative idea that would integrate with my incubator proposal
> would be to have each incubation project "chaperoned" by established
> community members chosen at the start of the incubation who will be the
> gatekeepers on whether it gets to graduate to mainline.
> 
> --Owen
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits