Philip Reames via llvm-dev
2020-Jul-01 17:11 UTC
[llvm-dev] LLVM Incubator + new projects draft
This looks to be a reasonable starting point.
A couple of nit picks, none are blockers.
1. I'd hold off on handing out the sub-domain for the moment. This
feels more official than we probably want for a random incubator. I
reserve the right to change my mind here, but maybe we should delay
this part until we see what actual incubators look like? As an
alternative, maybe have a common incubator.llvm.org page which links
to the docs defining the process and lists all active incubators
with links to docs in their own repo?
2. The must/should terminology should probably be factored out once and
referenced. As written, it takes a little effort to be sure the
definitions are the same between the two uses.
3. 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").
4. 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.
Philip
On 6/30/20 8:29 PM, Mehdi AMINI via llvm-dev wrote:> Looks like a good proposal to me as-is! Thanks for putting this
> together to both of you :)
>
> --
> Mehdi
>
>
> On Tue, Jun 30, 2020 at 1:49 PM Chris Lattner via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
> Hah, whoops, sorry about that. This is the correct link:
>
https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit
>
> -Chris
>
>> On Jun 30, 2020, at 1:41 PM, Thomas Lively <tlively at
google.com
>> <mailto:tlively at google.com>> wrote:
>>
>> Hi Chris,
>>
>> I'm also seeing an access denied error on the first link you
>> shared, and although I can access the second document, it
doesn't
>> look like the document you meant to share. It looks like a one
>> pager on ML in Swift.
>>
>> Thomas
>>
>> On Tue, Jun 30, 2020 at 1:05 PM Chris Lattner via llvm-dev
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>
>>
>>
>>> On Jun 30, 2020, at 11:52 AM, Roman Lebedev
>>> <lebedev.ri at gmail.com <mailto:lebedev.ri at
gmail.com>> wrote:
>>>
>>> On Tue, Jun 30, 2020 at 9:44 PM Chris Lattner via llvm-dev
>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>
>>> wrote:
>>>>
>>>> The idea of adding an “incubation” stage to projects in
the
>>>> LLVM world seems to be positively received. I also
noticed
>>>> that we don’t really document the new project policy in
>>>> general in the LLVM Developer Policy. To help with
both of
>>>> these Stella and I worked together to draft up a new
>>>> section for the LLVM developer policy (incorporating
the
>>>> existing “New Targets” section).
>>>>
>>>> Ahead of proposing a Phabricator patch, we put it into
this
>>>> google doc, I’d love to get feedback on it from anyone
who
>>>> is interested in this:
>>>>
https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit
>>> Currently it doesn't open, "You need access",
sanity check:
>>> is viewing
>>> allowed for everybody?
>>
>> It says that “anyone on the internet is allowed to comment”,
>> maybe this link will work better?:
>>
https://docs.google.com/document/d/1lC7cOJ2Iiqdx62o81J5YP7RzFHi8k2Rkt0zla-Kh6no/edit?usp=sharing
>>
>> In any case, if google docs isn’t cooperating, then you can
>> check it out when it gets to Phabricator.
>>
>> -Chris
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200701/2e962a22/attachment.html>
Philip Reames via llvm-dev
2020-Jul-01 17:22 UTC
[llvm-dev] LLVM Incubator + new projects draft
One other thought, since it came up on the apple branch thread. I think we need to be very specific about the fact that code in an incubator has been contributed to LLVM. I think this is implicit in the statements about license and policy, but having this be made explicit seems worthwhile. This would, for instance, make it obvious that code could be moved between repository without further involvement of the original authors. Again, I think this is covered by the existing text, but leaving no room for ambiguity here seems worthwhile. :) Philip On 7/1/20 10:11 AM, Philip Reames wrote:> > This looks to be a reasonable starting point. > > A couple of nit picks, none are blockers. > > 1. I'd hold off on handing out the sub-domain for the moment. This > feels more official than we probably want for a random incubator. > I reserve the right to change my mind here, but maybe we should > delay this part until we see what actual incubators look like? As > an alternative, maybe have a common incubator.llvm.org page which > links to the docs defining the process and lists all active > incubators with links to docs in their own repo? > 2. The must/should terminology should probably be factored out once > and referenced. As written, it takes a little effort to be sure > the definitions are the same between the two uses. > 3. 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"). > 4. 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. > > Philip > > On 6/30/20 8:29 PM, Mehdi AMINI via llvm-dev wrote: >> Looks like a good proposal to me as-is! Thanks for putting this >> together to both of you :) >> >> -- >> Mehdi >> >> >> On Tue, Jun 30, 2020 at 1:49 PM Chris Lattner via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hah, whoops, sorry about that. This is the correct link: >> https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit >> >> -Chris >> >>> On Jun 30, 2020, at 1:41 PM, Thomas Lively <tlively at google.com >>> <mailto:tlively at google.com>> wrote: >>> >>> Hi Chris, >>> >>> I'm also seeing an access denied error on the first link you >>> shared, and although I can access the second document, it >>> doesn't look like the document you meant to share. It looks like >>> a one pager on ML in Swift. >>> >>> Thomas >>> >>> On Tue, Jun 30, 2020 at 1:05 PM Chris Lattner via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> >>> >>>> On Jun 30, 2020, at 11:52 AM, Roman Lebedev >>>> <lebedev.ri at gmail.com <mailto:lebedev.ri at gmail.com>> wrote: >>>> >>>> On Tue, Jun 30, 2020 at 9:44 PM Chris Lattner via llvm-dev >>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> >>>> wrote: >>>>> >>>>> The idea of adding an “incubation” stage to projects in >>>>> the LLVM world seems to be positively received. I also >>>>> noticed that we don’t really document the new project >>>>> policy in general in the LLVM Developer Policy. To help >>>>> with both of these Stella and I worked together to draft >>>>> up a new section for the LLVM developer policy >>>>> (incorporating the existing “New Targets” section). >>>>> >>>>> Ahead of proposing a Phabricator patch, we put it into >>>>> this google doc, I’d love to get feedback on it from >>>>> anyone who is interested in this: >>>>> https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit >>>> Currently it doesn't open, "You need access", sanity check: >>>> is viewing >>>> allowed for everybody? >>> >>> It says that “anyone on the internet is allowed to comment”, >>> maybe this link will work better?: >>> https://docs.google.com/document/d/1lC7cOJ2Iiqdx62o81J5YP7RzFHi8k2Rkt0zla-Kh6no/edit?usp=sharing >>> >>> In any case, if google docs isn’t cooperating, then you can >>> check it out when it gets to Phabricator. >>> >>> -Chris >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200701/b8674a29/attachment.html>
Stella Laurenzo via llvm-dev
2020-Jul-01 19:30 UTC
[llvm-dev] LLVM Incubator + new projects draft
On Wed, Jul 1, 2020 at 10:22 AM Philip Reames <listmail at philipreames.com> wrote:> One other thought, since it came up on the apple branch thread. > > I think we need to be very specific about the fact that code in an > incubator has been contributed to LLVM. I think this is implicit in the > statements about license and policy, but having this be made explicit seems > worthwhile. This would, for instance, make it obvious that code could be > moved between repository without further involvement of the original > authors. > > Again, I think this is covered by the existing text, but leaving no room > for ambiguity here seems worthwhile. :) >+1 - This is actually a significant part of why I originally advocated for this approach. The reality is that many of us have various hurdles and ambiguities around collaborating with each other but are explicitly allowed/encouraged to do so in the context of contributions to LLVM and engaging in public as part of this community. Being explicit that a contribution to an incubator project is a contribution to LLVM is a bright line that is easy to point at (and hopefully understand). I'll leave the opinion of whether it is fine to leave this implicit vs explicit to those more knowledgeable about the vagaries of such things.> Philip > On 7/1/20 10:11 AM, Philip Reames wrote: > > This looks to be a reasonable starting point. > > A couple of nit picks, none are blockers. > > 1. I'd hold off on handing out the sub-domain for the moment. This > feels more official than we probably want for a random incubator. I > reserve the right to change my mind here, but maybe we should delay this > part until we see what actual incubators look like? As an alternative, > maybe have a common incubator.llvm.org page which links to the docs > defining the process and lists all active incubators with links to docs in > their own repo? > 2. The must/should terminology should probably be factored out once > and referenced. As written, it takes a little effort to be sure the > definitions are the same between the two uses. > 3. 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"). > 4. 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. > > Philip > On 6/30/20 8:29 PM, Mehdi AMINI via llvm-dev wrote: > > Looks like a good proposal to me as-is! Thanks for putting this together > to both of you :) > > -- > Mehdi > > > On Tue, Jun 30, 2020 at 1:49 PM Chris Lattner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hah, whoops, sorry about that. This is the correct link: >> >> https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit >> >> -Chris >> >> On Jun 30, 2020, at 1:41 PM, Thomas Lively <tlively at google.com> wrote: >> >> Hi Chris, >> >> I'm also seeing an access denied error on the first link you shared, and >> although I can access the second document, it doesn't look like the >> document you meant to share. It looks like a one pager on ML in Swift. >> >> Thomas >> >> On Tue, Jun 30, 2020 at 1:05 PM Chris Lattner via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Jun 30, 2020, at 11:52 AM, Roman Lebedev <lebedev.ri at gmail.com> >>> wrote: >>> >>> On Tue, Jun 30, 2020 at 9:44 PM Chris Lattner via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> >>> >>> The idea of adding an “incubation” stage to projects in the LLVM world >>> seems to be positively received. I also noticed that we don’t really >>> document the new project policy in general in the LLVM Developer Policy. >>> To help with both of these Stella and I worked together to draft up a new >>> section for the LLVM developer policy (incorporating the existing “New >>> Targets” section). >>> >>> Ahead of proposing a Phabricator patch, we put it into this google doc, >>> I’d love to get feedback on it from anyone who is interested in this: >>> >>> https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit >>> >>> Currently it doesn't open, "You need access", sanity check: is viewing >>> allowed for everybody? >>> >>> >>> It says that “anyone on the internet is allowed to comment”, maybe this >>> link will work better?: >>> >>> https://docs.google.com/document/d/1lC7cOJ2Iiqdx62o81J5YP7RzFHi8k2Rkt0zla-Kh6no/edit?usp=sharing >>> >>> In any case, if google docs isn’t cooperating, then you can check it out >>> when it gets to Phabricator. >>> >>> -Chris >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-- - Stella -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200701/bed957b0/attachment.html>
Stella Laurenzo via llvm-dev
2020-Jul-01 19:31 UTC
[llvm-dev] LLVM Incubator + new projects draft
On Wed, Jul 1, 2020 at 10:22 AM Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote:> One other thought, since it came up on the apple branch thread. > > I think we need to be very specific about the fact that code in an > incubator has been contributed to LLVM. I think this is implicit in the > statements about license and policy, but having this be made explicit seems > worthwhile. This would, for instance, make it obvious that code could be > moved between repository without further involvement of the original > authors. > > Again, I think this is covered by the existing text, but leaving no room > for ambiguity here seems worthwhile. :) >+1 - This is actually a significant part of why I originally advocated for this approach. The reality is that many of us have various hurdles and ambiguities around collaborating with each other but are explicitly allowed/encouraged to do so in the context of contributions to LLVM and engaging in public as part of this community. Being explicit that a contribution to an incubator project is a contribution to LLVM is a bright line that is easy to point at (and hopefully understand). I'll leave the opinion of whether it is fine to leave this implicit vs explicit to those more knowledgeable about the vagaries of such things.> Philip > On 7/1/20 10:11 AM, Philip Reames wrote: > > This looks to be a reasonable starting point. > > A couple of nit picks, none are blockers. > > 1. I'd hold off on handing out the sub-domain for the moment. This > feels more official than we probably want for a random incubator. I > reserve the right to change my mind here, but maybe we should delay this > part until we see what actual incubators look like? As an alternative, > maybe have a common incubator.llvm.org page which links to the docs > defining the process and lists all active incubators with links to docs in > their own repo? > 2. The must/should terminology should probably be factored out once > and referenced. As written, it takes a little effort to be sure the > definitions are the same between the two uses. > 3. 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"). > 4. 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. > > Philip > On 6/30/20 8:29 PM, Mehdi AMINI via llvm-dev wrote: > > Looks like a good proposal to me as-is! Thanks for putting this together > to both of you :) > > -- > Mehdi > > > On Tue, Jun 30, 2020 at 1:49 PM Chris Lattner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hah, whoops, sorry about that. This is the correct link: >> >> https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit >> >> -Chris >> >> On Jun 30, 2020, at 1:41 PM, Thomas Lively <tlively at google.com> wrote: >> >> Hi Chris, >> >> I'm also seeing an access denied error on the first link you shared, and >> although I can access the second document, it doesn't look like the >> document you meant to share. It looks like a one pager on ML in Swift. >> >> Thomas >> >> On Tue, Jun 30, 2020 at 1:05 PM Chris Lattner via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Jun 30, 2020, at 11:52 AM, Roman Lebedev <lebedev.ri at gmail.com> >>> wrote: >>> >>> On Tue, Jun 30, 2020 at 9:44 PM Chris Lattner via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> >>> >>> The idea of adding an “incubation” stage to projects in the LLVM world >>> seems to be positively received. I also noticed that we don’t really >>> document the new project policy in general in the LLVM Developer Policy. >>> To help with both of these Stella and I worked together to draft up a new >>> section for the LLVM developer policy (incorporating the existing “New >>> Targets” section). >>> >>> Ahead of proposing a Phabricator patch, we put it into this google doc, >>> I’d love to get feedback on it from anyone who is interested in this: >>> >>> https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit >>> >>> Currently it doesn't open, "You need access", sanity check: is viewing >>> allowed for everybody? >>> >>> >>> It says that “anyone on the internet is allowed to comment”, maybe this >>> link will work better?: >>> >>> https://docs.google.com/document/d/1lC7cOJ2Iiqdx62o81J5YP7RzFHi8k2Rkt0zla-Kh6no/edit?usp=sharing >>> >>> In any case, if google docs isn’t cooperating, then you can check it out >>> when it gets to Phabricator. >>> >>> -Chris >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200701/74668d8d/attachment.html>
Chris Lattner via llvm-dev
2020-Jul-01 21:12 UTC
[llvm-dev] LLVM Incubator + new projects draft
> On Jul 1, 2020, at 10:11 AM, Philip Reames <listmail at philipreames.com> wrote: > > This looks to be a reasonable starting point. > > A couple of nit picks, none are blockers. > > I'd hold off on handing out the sub-domain for the moment. This feels more official than we probably want for a random incubator. I reserve the right to change my mind here, but maybe we should delay this part until we see what actual incubators look like? As an alternative, maybe have a common incubator.llvm.org page which links to the docs defining the process and lists all active incubators with links to docs in their own repo?Sounds great, I’m happy to take this out - this avoids “promising” it, but we can still discuss it on a case-by-case basis. I changed this to "Other infrastructure integration can be discussed on a case-by-case basis.”, because there are bug tracker and other things as well.> The must/should terminology should probably be factored out once and referenced. As written, it takes a little effort to be sure the definitions are the same between the two uses.I’m not sure what you mean here. Do you have a recommended approach?> 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.> 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? -Chris> Philip > > On 6/30/20 8:29 PM, Mehdi AMINI via llvm-dev wrote: >> Looks like a good proposal to me as-is! Thanks for putting this together to both of you :) >> >> -- >> Mehdi >> >> >> On Tue, Jun 30, 2020 at 1:49 PM Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> Hah, whoops, sorry about that. This is the correct link: >> https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit <https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit> >> >> -Chris >> >>> On Jun 30, 2020, at 1:41 PM, Thomas Lively <tlively at google.com <mailto:tlively at google.com>> wrote: >>> >>> Hi Chris, >>> >>> I'm also seeing an access denied error on the first link you shared, and although I can access the second document, it doesn't look like the document you meant to share. It looks like a one pager on ML in Swift. >>> >>> Thomas >>> >>> On Tue, Jun 30, 2020 at 1:05 PM Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> >>>> On Jun 30, 2020, at 11:52 AM, Roman Lebedev <lebedev.ri at gmail.com <mailto:lebedev.ri at gmail.com>> wrote: >>>> >>>> On Tue, Jun 30, 2020 at 9:44 PM Chris Lattner via llvm-dev >>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>>>> >>>>> The idea of adding an “incubation” stage to projects in the LLVM world seems to be positively received. I also noticed that we don’t really document the new project policy in general in the LLVM Developer Policy. To help with both of these Stella and I worked together to draft up a new section for the LLVM developer policy (incorporating the existing “New Targets” section). >>>>> >>>>> Ahead of proposing a Phabricator patch, we put it into this google doc, I’d love to get feedback on it from anyone who is interested in this: >>>>> https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit <https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit> >>>> Currently it doesn't open, "You need access", sanity check: is viewing >>>> allowed for everybody? >>> >>> It says that “anyone on the internet is allowed to comment”, maybe this link will work better?: >>> https://docs.google.com/document/d/1lC7cOJ2Iiqdx62o81J5YP7RzFHi8k2Rkt0zla-Kh6no/edit?usp=sharing <https://docs.google.com/document/d/1lC7cOJ2Iiqdx62o81J5YP7RzFHi8k2Rkt0zla-Kh6no/edit?usp=sharing> >>> >>> In any case, if google docs isn’t cooperating, then you can check it out when it gets to Phabricator. >>> >>> -Chris >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200701/248016f4/attachment.html>
Nicolai Hähnle via llvm-dev
2020-Jul-02 14:40 UTC
[llvm-dev] 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.
Philip Reames via llvm-dev
2020-Jul-06 17:32 UTC
[llvm-dev] LLVM Incubator + new projects draft
On 7/1/20 2:12 PM, Chris Lattner wrote:> > >> On Jul 1, 2020, at 10:11 AM, Philip Reames <listmail at philipreames.com >> <mailto:listmail at philipreames.com>> wrote: >> >> This looks to be a reasonable starting point. >> >> A couple of nit picks, none are blockers. >> >> 1. I'd hold off on handing out the sub-domain for the moment. This >> feels more official than we probably want for a random >> incubator. I reserve the right to change my mind here, but maybe >> we should delay this part until we see what actual incubators >> look like? As an alternative, maybe have a common >> incubator.llvm.org <http://incubator.llvm.org> page which links >> to the docs defining the process and lists all active incubators >> with links to docs in their own repo? >> > Sounds great, I’m happy to take this out - this avoids “promising” it, > but we can still discuss it on a case-by-case basis. I changed this > to "Other infrastructure integration can be discussed on a > case-by-case basis.”, because there are bug tracker and other things > as well. >> >> 2. The must/should terminology should probably be factored out once >> and referenced. As written, it takes a little effort to be sure >> the definitions are the same between the two uses. >> > I’m not sure what you mean here. Do you have a recommended approach?Land yours, and if I still care, I'll send a patch. :)>> >> 3. 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. >> >> 4. 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?You said elsewhere that we could let this evolve with experience. I would take that sentiment, and apply it here. I'm really more concerned about the expectations of the role (i.e. some human familiar with LLVM norms willing to invest non-trivial time), than I am the details of who is eligible. Since I don't want this to be blocking item, why don't we land what you have and I can draft something as a patch? It seems like there's some general agreement about a potential issue and we just need to find a way to address it.> > -Chris > >> Philip >> >> On 6/30/20 8:29 PM, Mehdi AMINI via llvm-dev wrote: >>> Looks like a good proposal to me as-is! Thanks for putting this >>> together to both of you :) >>> >>> -- >>> Mehdi >>> >>> >>> On Tue, Jun 30, 2020 at 1:49 PM Chris Lattner via llvm-dev >>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> Hah, whoops, sorry about that. This is the correct link: >>> https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit >>> >>> -Chris >>> >>>> On Jun 30, 2020, at 1:41 PM, Thomas Lively <tlively at google.com >>>> <mailto:tlively at google.com>> wrote: >>>> >>>> Hi Chris, >>>> >>>> I'm also seeing an access denied error on the first link you >>>> shared, and although I can access the second document, it >>>> doesn't look like the document you meant to share. It looks >>>> like a one pager on ML in Swift. >>>> >>>> Thomas >>>> >>>> On Tue, Jun 30, 2020 at 1:05 PM Chris Lattner via llvm-dev >>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>>> >>>> >>>> >>>>> On Jun 30, 2020, at 11:52 AM, Roman Lebedev >>>>> <lebedev.ri at gmail.com <mailto:lebedev.ri at gmail.com>> wrote: >>>>> >>>>> On Tue, Jun 30, 2020 at 9:44 PM Chris Lattner via llvm-dev >>>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> >>>>> wrote: >>>>>> >>>>>> The idea of adding an “incubation” stage to projects in >>>>>> the LLVM world seems to be positively received. I also >>>>>> noticed that we don’t really document the new project >>>>>> policy in general in the LLVM Developer Policy. To help >>>>>> with both of these Stella and I worked together to draft >>>>>> up a new section for the LLVM developer policy >>>>>> (incorporating the existing “New Targets” section). >>>>>> >>>>>> Ahead of proposing a Phabricator patch, we put it into >>>>>> this google doc, I’d love to get feedback on it from >>>>>> anyone who is interested in this: >>>>>> https://docs.google.com/document/d/1ss4jGHywL0Y2KW_l4LqTo5CgJxx3i0_4-FkbXiPQMus/edit >>>>> Currently it doesn't open, "You need access", sanity >>>>> check: is viewing >>>>> allowed for everybody? >>>> >>>> It says that “anyone on the internet is allowed to >>>> comment”, maybe this link will work better?: >>>> https://docs.google.com/document/d/1lC7cOJ2Iiqdx62o81J5YP7RzFHi8k2Rkt0zla-Kh6no/edit?usp=sharing >>>> >>>> In any case, if google docs isn’t cooperating, then you can >>>> check it out when it gets to Phabricator. >>>> >>>> -Chris >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200706/879c4a18/attachment.html>