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

[Renato Golin via Phabricator via llvm-commits]

rengolin marked an inline comment as done.
rengolin added inline comments.


================
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
----------------
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.


================
Comment at: llvm/docs/SupportPolicy.rst:110
+ * Be actively maintained by such sub-community and have its problems addressed
+   in a timely manner, even if concerns come from outside of the sub-community.
+
----------------
ctetreau wrote:
> The way I read this, I as a user of a peripheral tier component can open a bug against said component on bugs.llvm.org, and that this bug is valid and is expected to be addressed.
> 
> Is this correct? If so, maybe this should be explicitly codified here.
Not just a user for component X, but developers on core tier stuff as well as developers of component Y.

It is the responsibility of the sub-communities to maintain their code so that their quality is at the very least "invisible" to other users, but optimally it should behave well not "negatively affect" others.


================
Comment at: llvm/docs/SupportPolicy.rst:147-148
+
+But for code to remain in the tiers above, they must not impose degradation in
+their own support but also in other parts of the code.
+
----------------
GMNGeoffrey wrote:
> Wording is a bit weird here. I'm not quite sure what you're trying to say.
I'm trying to say that we're not all looking hard to destroy other people's work, and this document is mostly to allow us to do so when it's affecting the rest of the community. I have removed the weird paragraph and have simplified the last one. I hope that's clearer.


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

https://reviews.llvm.org/D90761