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

[Geoffrey Martin-Noble via Phabricator via llvm-commits]

GMNGeoffrey 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
----------------
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




================
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.
+
----------------
rengolin wrote:
> 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.
I think you kept the paragraph I find confusing. Maybe my issue is with the phrasing "impose degradation" which sounds odd to me. It seems like mostly this is covered by the "must nots" above, but maybe you think it still is useful to include in this section as well? I took a swing at rewording

> For code to remain in the repository, its presence must not impose an undue burden on maintaining other components (core or peripheral).


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

https://reviews.llvm.org/D90761