[llvm-foundation] On Subprojects and the boundaries of authority (was: Voting)

[Tanya Lattner via llvm-foundation]

> On Jun 30, 2016, at 11:53 AM, Robinson, Paul <paul.robinson at sony.com> wrote:
> 
>> -----Original Message-----
>> From: llvm-foundation [mailto:llvm-foundation-bounces at lists.llvm.org] On
>> Behalf Of Tanya Lattner via llvm-foundation
>> Sent: Thursday, June 30, 2016 10:28 AM
>> To: David Chisnall
>> Cc: llvm-foundation at lists.llvm.org
>> Subject: Re: [llvm-foundation] Voting
>> 
>> 
>>> On Jun 30, 2016, at 1:51 AM, David Chisnall via llvm-foundation <llvm-
>> foundation at lists.llvm.org> wrote:
>>> ... describing FreeBSD Foundation ...
>>> It’s worth noting that, while certain individuals are on both Core and
>> the Foundation Board, their responsibilities are very different in these
>> two capacities.  The Foundation has a lot more flexibility, because it is
>> decoupled from the project and not directly responsible, whereas the Core
>> Team has far greater authority within the project as a result of their
>> elected status.  The relationship between the FreeBSD Foundation and the
>> FreeBSD Project is very carefully managed.  By spending money on things,
>> the Foundation can direct development to a degree (though no more than any
>> other company that is investing in FreeBSD - a dozen or so companies
>> routinely spend more on FreeBSD development than the Foundation), but its
>> role must be (and must be seen to be) supporting and facilitating, not
>> driving.
>>> 
>>> The LLVM Foundation is currently in a place somewhere between these.
>> Some of the minutes from the early LLVM Foundation meetings discussed
>> technical issues (inclusion of subprojects) that should be LLVM-the-
>> project decisions, not Foundation issues (though the same people would
>> likely have been making the decisions in both cases).  It’s still not
>> clear within the LLVM project (or from outside) where the LLVM
>> Foundation’s authority starts and ends.  There is no equivalent of an
>> elected Core Team that serves as an obvious project-side balance for the
>> Foundation.
>> 
>> Regarding sub projects, it was discussed as to what criteria would be used
>> to accept sub projects from the perspective of supporting the sub-project
>> with resources paid for and administered by the LLVM Foundation. In
>> addition to hosting and infrastructure support, I see the LLVM Foundation
>> supporting official sub-projects in educational services realm as well
>> (workshops, conferences, etc). I do not feel this is a technical issue but
>> an administrative and legal issue. Obviously projects are proposed on the
>> list first (like the parallel-libs project).
>> 
>> As I have said many times before we are supporting the LLVM Project
>> through legal, financial, administrative, and infrastructure. We don’t
>> control the LLVM project in any technical way. We have code owners to
>> handle technical decisions.
>> 
>> -Tanya
> 
> I think the LLVM Foundation is still figuring out what are the correct
> boundaries for its authority. This is not a surprise.
> 
> The discussion of the llgo sub-project in particular was a mix of 
> technical and non-technical aspects.  There may be some difference of
> opinion about what is a "technical" aspect so I will spend some time
> laying out my opinion here.  The 25 Nov 2014 minutes say:
> 
>    We want to encourage new sub-projects, but have specific guidelines
>    such as: following the LLVM Developer Policy, code structured similar
>    to other LLVM projects, licenses should follow the UIUC/MIT licenses
>    as appropriate to the project. Exceptions to these rules will be
>    considered on a case by case basis by the board.
> 
> I think it's entirely appropriate for the Foundation to state copyright,
> licensing and patent requirements for software sub-projects hosted with
> equipment/services provided by the Foundation. This is legal stuff that 
> clearly falls under the Foundation's purview.
> 
> But, it's equally *not* appropriate for the Foundation to impose technical
> requirements, and I include the following as "technical" points.
> - Code structure is a technical point, to be decided by the community.
> - Adhering to Developer Policy (besides the legal stuff) is a technical
>  point, ditto.
> 

Paul,

We aren’t defining anything new. This is already stated in the Developer Policy:
http://llvm.org/docs/DeveloperPolicy.html <http://llvm.org/docs/DeveloperPolicy.html>

First paragraph “.... This policy covers all llvm.org subprojects, including Clang, LLDB, libc++, etc.”

Anyone who gets commit access to the llvm repository has access to everything, so thats why one policy is used. I don’t disagree that the Developer Policy does include technical points such as code structure, but its not something new.

> I should be clear that I think all these requirements are appropriate,
> just that it's absolutely not the Foundation's job to impose them.  
> Although, as David suggests, exactly the same people participating on the 
> Dev lists (instead of a Foundation board meeting) absolutely should make 
> sure these requirements were imposed.  Understanding how these roles are
> (and should be) separate is a bit of a learning curve.
> If the community decides a new software sub-project is appropriate, and
> the new subproject adheres to the Foundation's legal requirements, then
> it should Just Happen; the community should not have to go to the
> Foundation to get *approval* for the new sub-project.  The Foundation
> provides equipment/services to support the software deemed appropriate
> by the community; having the Foundation approve new sub-projects would
> be putting the cart before the horse.  Nobody's IT department decides
> what products to produce.

The Foundation is only approving a project in the sense of providing it resources (hosting, mailing lists, svn) if it meets the requirements. Everything else is already in the developer policy. I think it could be made more clear though which is why it says a policy would be written.

> 
> Conversely, if the Foundation wants to host non-software subprojects
> using the same equipment/services (to support workshops, conferences, 
> other educational services) that's entirely up to the Foundation, of 
> course.  And for those subprojects, there is no reason for the Foundation 
> to go to the *community* for approval.
> 
> Given that essentially all of the LLVM Foundation board members are
> people who are used to writing software, it's no real surprise that
> it's hard to correctly separate the legal/operational policy concerns
> that are properly in the domain of the Foundation from the technical
> policy concerns that are properly the domain of the community.  Yes
> they are all "policy" but no, they are not all Foundation concerns.


I feel like there is a lot of concern over what might happen versus whats actually happening. We haven’t told any project they couldn’t be created. We haven’t imposed any new technical decisions.  Has the LLVM Foundation done something actively harmful to the community? If so, then lets talk about the specifics of those decisions and work to a better solution.

-Tanya

> 
> HTH,
> --paulr
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-foundation/attachments/20160630/606aaade/attachment.html>