[swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma]

On Thu, Nov 9, 2017 at 12:37 PM, Wallacy via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> Em qui, 9 de nov de 2017 às 03:42, Ted Kremenek <kremenek at apple.com>
> escreveu:
>
>> These are some really interesting analogies.  How would you imagine the
>> community “governance” of these “plugins” (which I assume would be
>> libraries or packages) to be managed?
>>
>
> Pretty much like a TV/Games/etc community forums. The owner (In this case
> Apple/Core Team) invite some people to help (Moderators etc) to maintain
> the main project, look if everyone is follow the rules, etc.
>
> Also is similar as other opensource projects.
>
>
>> What does it mean for the “full community” to manage them, and provide
>> the rough guarantees you suggest?
>>
>
> NPM has thousands of projects, is impossible to check all of then. And
> besides be a good reference, here we have the opportunity do to something
> better... Because...Because...Because I believe we can ;)
>
> So what i expect?
>
> Lets make some assumptions here, just to play a little:
>
> Let assume we build a Indexer like IBM Swift Package Catalog (
> https://packagecatalog.com/ ) over Swift.org.
>
> And like Swift Source Compatibility Suite to be "indexed" the author of
> the project needs to send the request to be accepted.
>
> Lets assume the same rules as Compatibility Suite:
> Acceptance Criteria
>
> To be accepted into the Swift source compatibility test suite, a project
> must:
>
>    1. Target Linux, macOS, or iOS/tvOS/watchOS device
>    2. Be an *Xcode* or *Swift Package Manager* project (Carthage and
>    CocoaPods are currently unsupported but are being explored to be supported
>    in the future)
>    3. Support building on either Linux or macOS
>    4. Be contained in a publicly accessible git repository
>    5. Maintain a project branch that builds against Swift 3.0
>    compatibility mode and passes any unit tests
>    6. Have maintainers who will commit to resolve issues in a timely
>    manner
>    7. Be compatible with the latest GM/Beta versions of *Xcode* and
>    *swiftpm*
>    8. Add value not already included in the suite
>    9. Be licensed with one of the following permissive licenses:
>       - BSD
>       - MIT
>       - Apache License, version 2.0
>       - Eclipse Public License
>       - Mozilla Public License (MPL) 1.1
>       - MPL 2.0
>       - CDDL
>
> i’m okay with this as long as point 9 is changed to accept copyleft
licenses like GPL. currently this is a huge hole in the SSCS which i am
sure will cause issues down the road
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171109/3449e74a/attachment.html>