llvm dev - Jul 2020 - LLVM Incubator + new projects draft

On Wed, Jul 1, 2020 at 11:12 PM Chris Lattner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> > I'm not sure I agree with the no-code standard.  I agree with
minimal code, but I think an incubator should be established enough to be
discussed concretely (e.g. "what is" vs "ideals").
>
> I hear what you’re saying, but I think we can handle this as part of the
approval process.  We can bounce of things that qualitatively don’t feel
credible and give guidance there, but can still be receptive if something seems
like a promising direction.
I have to say that I agree with Philip here, and saying "we can handle
this as part of the process" feels like a cop-out to me. Part of the
point of writing up a document like this is to establish and document
expectations, and this is an important expectation to establish.

To clarify, the key underlying issue here is that there is no reason
to make incubation a free-for-all (people can always create repos on
GitHub), but if it's not a free-for-all, then a decision must be made
somehow. The question is: what grounds is that decision going to be
made on?

The fewer concrete artefacts we have to make a decision, the more
people will form their opinions based on soft, clique-ish factors such
as whether they like the person making the proposal, whether they
consider them to "already be part of the community", what company or
university they work for (if any), and so on. Clique-ishness is the
opposite of inclusivity, so I feel very strongly that the expectation
should be having at least _some_ basic artefacts here. There might be
the rare legitimate exception to this rule, but that is nicely
captured by making it a "Should" rule.

Along similar lines, having some sort of manifesto / development plan
/ whatever really should be a Must. Writing something like that up is
an incredibly low bar, and if people can't even be bothered to do
*that*, well... Having that Must next to "there Should be a prototype"
also helps clarify the expectations.

> > As I mentioned before, I'd advocate for the notion of a sponsor
(an existing LLVM contributor) for each incubator.  I'd have that a must on
the incubator list.
>
> Yes, this is a good idea.  The problem here is “how do we decide who
qualifies as a sponsor?”.  I don’t know a good way to say that - someone with N
years of LLVM experience, M patches, …?  How does this get explained?
Do we really need that? It feels to me like this is much more
something that could be handled as part of the approval process. If
nobody from "the community" (whatever that means) is in favor of the
incubation, then it's not going to happen. So kind of by definition
you need at least one person speaking in favor :)

Cheers,
Nicolai

-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.

On 7/2/20 9:40 AM, Nicolai Hähnle via llvm-dev wrote:
> On Wed, Jul 1, 2020 at 11:12 PM Chris Lattner via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>> I'm not sure I agree with the no-code standard.  I agree with
minimal code, but I think an incubator should be established enough to be
discussed concretely (e.g. "what is" vs "ideals").
>> I hear what you’re saying, but I think we can handle this as part of
the approval process.  We can bounce of things that qualitatively don’t feel
credible and give guidance there, but can still be receptive if something seems
like a promising direction.
> I have to say that I agree with Philip here, and saying "we can handle
> this as part of the process" feels like a cop-out to me. Part of the
> point of writing up a document like this is to establish and document
> expectations, and this is an important expectation to establish.
>
> To clarify, the key underlying issue here is that there is no reason
> to make incubation a free-for-all (people can always create repos on
> GitHub), but if it's not a free-for-all, then a decision must be made
> somehow. The question is: what grounds is that decision going to be
> made on?
>
> The fewer concrete artefacts we have to make a decision, the more
> people will form their opinions based on soft, clique-ish factors such
> as whether they like the person making the proposal, whether they
> consider them to "already be part of the community", what company
or
> university they work for (if any), and so on. Clique-ishness is the
> opposite of inclusivity, so I feel very strongly that the expectation
> should be having at least _some_ basic artefacts here. There might be
> the rare legitimate exception to this rule, but that is nicely
> captured by making it a "Should" rule.
>
> Along similar lines, having some sort of manifesto / development plan
> / whatever really should be a Must. Writing something like that up is
> an incredibly low bar, and if people can't even be bothered to do
> *that*, well... Having that Must next to "there Should be a
prototype"
> also helps clarify the expectations.
>
>
>>> As I mentioned before, I'd advocate for the notion of a sponsor
(an existing LLVM contributor) for each incubator.  I'd have that a must on
the incubator list.
>> Yes, this is a good idea.  The problem here is “how do we decide who
qualifies as a sponsor?”.  I don’t know a good way to say that - someone with N
years of LLVM experience, M patches, …?  How does this get explained?
> Do we really need that? It feels to me like this is much more
> something that could be handled as part of the approval process. If
> nobody from "the community" (whatever that means) is in favor of
the
> incubation, then it's not going to happen. So kind of by definition
> you need at least one person speaking in favor :)

Do we want to specifically say some member of the community (i.e., 
someone with commit access?) not associated with the proposed incubator 
project? Are we looking for some kind of community consensus, lack of 
broad concern, etc.?

  -Hal

>
> Cheers,
> Nicolai
>
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

On Jul 2, 2020, at 7:40 AM, Nicolai Hähnle <nhaehnle at gmail.com>
wrote:
> 
> On Wed, Jul 1, 2020 at 11:12 PM Chris Lattner via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>> I'm not sure I agree with the no-code standard.  I agree with
minimal code, but I think an incubator should be established enough to be
discussed concretely (e.g. "what is" vs "ideals").
>> 
>> I hear what you’re saying, but I think we can handle this as part of
the approval process.  We can bounce of things that qualitatively don’t feel
credible and give guidance there, but can still be receptive if something seems
like a promising direction.
> 
> I have to say that I agree with Philip here, and saying "we can handle
> this as part of the process" feels like a cop-out to me. Part of the
> point of writing up a document like this is to establish and document
> expectations, and this is an important expectation to establish.
Sure, I can see that concern.  The document does exactly this, by laying out
requirements like "Must be generally aligned with the mission of the LLVM
project to advance compilers, languages, tools, runtimes, etc.”

Anything in a policy has to be written to have the right level of rigidity.  Too
rigid and you bounce of potentially good ideas that could be molded into
something workable with community discussion and coaching.  Too loose and there
is no value.  The major problem of being too loose is that you can create scale
problems: When we have hundreds of requests, each needs to be discussed
individually.  Writing things down in a more rigid way reduces the cost of that.

In this case, I don’t expect to have hundreds of requests or for scalability to
be a problem.  Furthermore, we don’t have a lot of experience here.  Once we get
a few requests and if we hit scale problems, we can codify the best practices we
discover along the way into a more rigid description over time.
> To clarify, the key underlying issue here is that there is no reason
> to make incubation a free-for-all (people can always create repos on
> GitHub), but if it's not a free-for-all, then a decision must be made
> somehow. The question is: what grounds is that decision going to be
> made on?
RFC’s as described in the writing.  This is generally how the LLVM community
makes decisions for all the things.
> The fewer concrete artefacts we have to make a decision, the more
> people will form their opinions based on soft, clique-ish factors such
> as whether they like the person making the proposal, whether they
> consider them to "already be part of the community", what company
or
> university they work for (if any), and so on. Clique-ishness is the
> opposite of inclusivity, so I feel very strongly that the expectation
> should be having at least _some_ basic artefacts here. There might be
> the rare legitimate exception to this rule, but that is nicely
> captured by making it a "Should" rule.
You seem very afraid of “abuse” here.  Given the way the LLVM community dynamics
work, I see no reason to design around the possibility of abuse.  If a problem
arises in practice, we can revise our approach.
> Along similar lines, having some sort of manifesto / development plan
> / whatever really should be a Must. Writing something like that up is
> an incredibly low bar, and if people can't even be bothered to do
> *that*, well... Having that Must next to "there Should be a
prototype"
> also helps clarify the expectations.
I agree, upgraded to ‘must’ thanks!
> 
> 
>>> As I mentioned before, I'd advocate for the notion of a sponsor
(an existing LLVM contributor) for each incubator.  I'd have that a must on
the incubator list.
>> 
>> Yes, this is a good idea.  The problem here is “how do we decide who
qualifies as a sponsor?”.  I don’t know a good way to say that - someone with N
years of LLVM experience, M patches, …?  How does this get explained?
> 
> Do we really need that? It feels to me like this is much more
> something that could be handled as part of the approval process. If
> nobody from "the community" (whatever that means) is in favor of
the
> incubation, then it's not going to happen. So kind of by definition
> you need at least one person speaking in favor :)
Yes, I don’t think this should be a requirement.  It is too difficult to nail
down as I tried to convey.

Thank you for the feedback Nicolai!

-Chris

On Jul 5, 2020, at 8:12 AM, Hal Finkel <hfinkel at anl.gov>
wrote:
>>>> As I mentioned before, I'd advocate for the notion of a
sponsor (an existing LLVM contributor) for each incubator.  I'd have that a
must on the incubator list.
>>> Yes, this is a good idea.  The problem here is “how do we decide
who qualifies as a sponsor?”.  I don’t know a good way to say that - someone
with N years of LLVM experience, M patches, …?  How does this get explained?
>> Do we really need that? It feels to me like this is much more
>> something that could be handled as part of the approval process. If
>> nobody from "the community" (whatever that means) is in favor
of the
>> incubation, then it's not going to happen. So kind of by definition
>> you need at least one person speaking in favor :)
> 
> 
> Do we want to specifically say some member of the community (i.e., someone
with commit access?) not associated with the proposed incubator project? Are we
looking for some kind of community consensus, lack of broad concern, etc.?
In practice, commit access is pretty easy to get.  I really think we can cross
this bridge when we come to it.  The two proposed projects so far already
include experienced LLVM project contributors.  If someone proposes a new
project that is out of the blue, this concern can be addressed through
qualitative concerns brought up in the discussion - it doesn’t have to be
codified in the developer policy in my opinion.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200705/707595d7/attachment.html>