[PATCH] D90761: [docs] Adding a Support Policy

Fri Nov 6 02:41:08 PST 2020

rengolin marked 2 inline comments as done.
rengolin added a comment.

In D90761#2374520 <https://reviews.llvm.org/D90761#2374520>, @GMNGeoffrey wrote:

> Overall LGTM, with some wording nits. One thing I think is missing is guidance for how a peripheral component gets added. Experimental targets already have their own documentation, and my impression is that editor bindings are just a matter of sending a patch (which seems reasonable to me). What about something like:
>
>> To add a new peripheral component not covered under an existing policy, send an RFC to the appropriate dev list proposing its addition and explaining how it will meet the support requirements listed here.

Sorry I missed this. I have now added a whole new "Inclusion Policy" section, which starts with your phrase, but adds a bit more of the mechanics to be clear what to expect.

================
Comment at: llvm/docs/SupportPolicy.rst:108
+ * Have a clear benefit for remaining in the main repository, catering to at
+   least one active sub-community (upstream or downstream).
+ * Be actively maintained by such sub-community and have its problems addressed
----------------
GMNGeoffrey wrote:
> rengolin wrote:
> > ctetreau wrote:
> > > GMNGeoffrey wrote:
> > > > ctetreau wrote:
> > > > > I'm not quite sure what the best way to express this is, but I feel like things in the peripheral tier must have at least one active subcommunity upstream or at least two disjoint active subcommunities downstream.
> > > > > 
> > > > > I.E. "somebody uses it in upstream" or "two separate downstreams use it"
> > > > How are we measuring *number* of communities? Wouldn't we always have one sub-community that is "the sub-community that cares about thing X"?
> > > > How are we measuring *number* of communities? Wouldn't we always have one sub-community that is "the sub-community that cares about thing X"?
> > > 
> > > This would be largely honor-system. In the RFC, part of the justification would be spelling out who the multiple subcommunities are. With the bazel example, the original RFC states "we use it internally at google, but tensorflow also has a parallel version of this". In this case "llvm devs at google" and "llvm devs for the tensorflow project" are the 2 subcommunities. I would think that a representative from each subcommunity should respond to the RFC stating that they agree to be maintainers (or at least that they care about it). For the bazel example, Google has clearly stated interest. A Tensorflow maintainer should respond to the RFC stating that they do in fact care (I don't know if this has happened).
> > > 
> > > The idea here being: "If only one org is using this thing in their downstream, and nobody else wants it, why would the community accept it?"
> > > 
> > > I guess perhaps the "one subcommunity upstream" requirement is kind of pointless. If it's not being used by a core-tier component, then by definition it's only used by downstreams or out of tree users of llvm. And if it were being used by a core-tier component, then I would think it should also be core-tier.
> > I think I consider "sub-community" as a set, so the union of two sub-communities is still a "sub-community". I also don't see how we could "count" them, as there is a lot of overlap. 
> > 
> > Worst case we'd be forcing people to create bogus splits to "increase the number of sub-communities" to pass a threshold.
> > 
> > I'm simplifying the second bullet to avoid confusion. In the end, the points I wanted to make are already there on the second (must not) bullet section.
> > I think I consider "sub-community" as a set, so the union of two sub-communities is still a "sub-community". I also don't see how we could "count" them, as there is a lot of overlap. 
> 
> Yes this was my reasoning as well
> 
> 

> The idea here being: "If only one org is using this thing in their downstream, and nobody else wants it, why would the community accept it?"

I think the main idea of the policy is to say that it's ok to have side-projects in the main repo if they follow the guidelines and don't break other people's stuff. Basically "be excellent to each other".

If only one downstream user is using it and that user always fixes stuff whenever it breaks and keeps it up-to-date, then this follows the spirit of the policy in two ways:

1. It is being "excellent" to all others.
2. It allows people that haven't used that component to experiment with it without having to pay the cost of downstream maintenance (and learning), which is often prohibitive.

Point 2 above encourages sub-community growth, and if/when the sub-community is large enough, we may even make it core.

Case 1: Autoconf vs. CMake.

When I started working on LLVM, the default was autoconf and CMake support was patchy. I had rarely used CMake until then, but when I did I wonder why the heck were we still using autoconf. After enough people gathered behind CMake, we moved official support to CMake (after fixing all its bugs).

This would be a typical tier-inversion, with autoconf moving down to peripheral tier, while CMake went up to core. 

Later on, when I was building Arm buildbots, I realised we were still supporting autoconf. Back then, most Arm developers were still using autoconf to build because CMake support on Arm was still patchy. So I fixed what I could and took the conscious decision to not create any autoconf Arm bot ever. Other bot maintainers have moved their existing autoconf bots to CMake and in due time, there were none.

That conscious decision by the community is what drove a lot of people to fix most CMake bugs and improve it considerably. This is when we decided to drop support for autoconf.

Case 2: GN

I had no idea it existed until George proposed to include Bazel. I still have no idea what it does or why it exists, but I still literally don't care. I don't know if the sub-community is one person or half of the developers, and that doesn't matter because I have never been affected by it.

It can continue to exist for as long as it does and I probably won't even notice. This means to me that either those files are so stable that no one ever changes and it never breaks (similar to most editor configuration) or the sub-community is extremely responsive. Either way, they're already following the policy we're trying to create.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90761/new/

https://reviews.llvm.org/D90761