<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Em qui, 9 de nov de 2017 às 03:42, Ted Kremenek <<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">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? </div></blockquote><div> </div><div><div>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. </div><div><br></div><div>Also is similar as other opensource projects.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">What does it mean for the “full community” to manage them, and provide the rough guarantees you suggest?</div></blockquote><div><br></div><div>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 ;)<br></div><div><br></div><div>So what i expect?</div><div><br></div><div>Lets make some assumptions here, just to play a little:<br></div><div><br></div><div>Let assume we build a Indexer like IBM Swift Package Catalog ( <a href="https://packagecatalog.com/">https://packagecatalog.com/</a> ) over Swift.org.<br></div><div><br></div><div>And like Swift Source Compatibility Suite to be "indexed" the author of the project needs to send the request to be accepted.</div><div><br></div><div>Lets assume the same rules as Compatibility Suite:</div><div><h3 style="box-sizing:border-box;margin-top:24px;margin-bottom:16px;font-size:1.25em;line-height:1.25;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol"">Acceptance Criteria</h3><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:16px">To be accepted into the Swift source compatibility test suite, a project must:</p><ol style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:16px"><li style="box-sizing:border-box">Target Linux, macOS, or iOS/tvOS/watchOS device</li><li style="box-sizing:border-box;margin-top:0.25em">Be an <em style="box-sizing:border-box">Xcode</em> or <em style="box-sizing:border-box">Swift Package Manager</em> project (Carthage and CocoaPods are currently unsupported but are being explored to be supported in the future)</li><li style="box-sizing:border-box;margin-top:0.25em">Support building on either Linux or macOS</li><li style="box-sizing:border-box;margin-top:0.25em">Be contained in a publicly accessible git repository</li><li style="box-sizing:border-box;margin-top:0.25em">Maintain a project branch that builds against Swift 3.0 compatibility mode and passes any unit tests</li><li style="box-sizing:border-box;margin-top:0.25em">Have maintainers who will commit to resolve issues in a timely manner</li><li style="box-sizing:border-box;margin-top:0.25em">Be compatible with the latest GM/Beta versions of <em style="box-sizing:border-box">Xcode</em> and <em style="box-sizing:border-box">swiftpm</em></li><li style="box-sizing:border-box;margin-top:0.25em">Add value not already included in the suite</li><li style="box-sizing:border-box;margin-top:0.25em">Be licensed with one of the following permissive licenses:<ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:0px"><li style="box-sizing:border-box">BSD</li><li style="box-sizing:border-box;margin-top:0.25em">MIT</li><li style="box-sizing:border-box;margin-top:0.25em">Apache License, version 2.0</li><li style="box-sizing:border-box;margin-top:0.25em">Eclipse Public License</li><li style="box-sizing:border-box;margin-top:0.25em">Mozilla Public License (MPL) 1.1</li><li style="box-sizing:border-box;margin-top:0.25em">MPL 2.0</li><li style="box-sizing:border-box;margin-top:0.25em">CDDL</li></ul></li></ol></div><div><br></div><div>And lets assume like GStreamer we have 4 categories of projects.</div><div><br></div><div>Base; Good; Bad; Unsupported. (just as exemple)</div><br><b>swift-extension-base </b><br>a small and fixed set of features, covering a small range of possible types of elements; these are continuously kept up-to-date with any core changes during the development series.</div><div class="gmail_quote"><ul><li>We believe distributors can safely ship these features<br></li><li>People writing elements should base their code on these elements<br></li><li>These elements come with examples, documentation, and regression tests</li></ul><b>swift-extension-good <br></b>a set of features that we consider to have good quality code, correct functionality, our preferred license (Swift Licence), and covering a wide range features.<br><ul><li>We believe distributors can safely ship these plug-ins<br></li><li>People writing elements should base their code on these elements</li></ul><b>swift-extension-bad </b><br>a set of features that have good quality and correct functionality, but distributing them might pose problems. The license on either the or the supporting libraries might not be how we'd like. The code might be widely known to present patent problems.<br><ul><li>Distributors should check if they want/can ship these plug-ins<br></li><li>People writing elements should base their code on these elements</li></ul><b>swift-extension-unsupported </b><br>a set of features that aren't up to par compared to the rest. They might be close to being good quality, but they're missing something - be it a good code review, some documentation, a set of tests, a real live maintainer, or some actual wide use.<br><ul><li>If the features break, you can't complain - instead, you can fix the problem and send us a patch, or bribe someone into fixing them for you<br></li><li>New contributors can start here for things to work on<br></li></ul><br><div>After request to be accepted is made, let's assume some area using forums or similar to make that request happen, the project will be classified in one of those categories, and will have people to look if projects accepted on "base"/"good"/"bad" have the minimum requirements to keep on those categories. Unsupported can be used for projects are not maintained any more, or does not follow all rules, but at least one of then.</div><div><br></div><div>How?</div><div><br></div><div>At base/good level wee need only a few projects? 10-100? I don't know, but a sane number to according to the number of people who are available to monitor them, a project on this level may even have no commit for a while. At "bad" level we can have much more projects and only rely to automatic checks like, number of downloads, starts, comments, commits etc to see if this project is maintened (packagecatalog give us a few metrics too). If the project owner believes that your project is relevant enough to be considered "good" needs to make a request.</div><div><br></div><div>In this cenário, you can have your project automatically downgraded to unsupported group, but to level-up you need to do a request and we will see if meet the requirement of that level.</div><div><br></div><div>SwiftPM should default only to base/good level:</div><div><br></div><div>$: SwiftPM install BigInt </div><div><br></div><div>for bad:</div><div><br></div><div>$: SwiftPM --enable-bad-projects install SomeCrazyLib</div><div><br></div><div><br></div><div>In this cenário we will not actually have a extremely big indexer, this is limited by definition, but the the community will "battle" to make relevant projects to be accept in this "oficial" indexer. And actually, we already have few of then now.</div><div><br></div><div>And... well, a BigInt, a Future Lib, of entire HTTP server can be indexed here, and because in this case "quality matter", this can be assumed to be a "non-standard" library in some way. Several projects, solving several problems, without the craziness of "npm/nuget"</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>I like the general premise here: support a library ecosystem for Swift, with possibly layers of expectations and guarantees on the quality of those libraries and the features they support.</div><div><br></div><div>A related question, what can we do to how the communication discussion via <a href="http://Swift.org" target="_blank">Swift.org</a> can be used to facilitate building such a library ecosystem? Kelvin Ma made a great point about shouting out on the mailing list for a project and getting no real response. I’m getting optimistic that we can move to a forum soon; could we use that forum in a way to help facilitate something like what you are proposing? <br></div></div></blockquote><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br><blockquote type="cite"></blockquote></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div>On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-6659677212814100891Apple-interchange-newline"></blockquote></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><div dir="ltr">@Félix Fischer<div><br>Yes, I wanted to say central index. I chose the wrong term.</div><div><br></div><div>Actually I could have summed it up like this:<br></div><div>- Central Index</div><div>- SwiftPM to download/search using this index like npm/nuget</div><div>- GStreamer organization Style.</div><div><br></div><div>I do not agree with Ted that only a few projects should be ranked, everyone, as it is in npm should be available. Only be graded according to recommendations.<br></div><div><br></div><div>For exemple this is what GStreamer do:</div><div><br></div><div><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Ubuntu,Arial,"libra sans",sans-serif;vertical-align:baseline;clear:both;color:rgb(17,17,17)"><strong style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline">gst-plugins-base</strong><br style="margin-bottom:0px">a small and fixed set of plug-ins, covering a wide range of possible types of elements; these are continuously kept up-to-date with any core changes during the development series.</p><ul style="margin:0px 0px 1em 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Ubuntu,Arial,"libra sans",sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(17,17,17)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">We believe distributors can safely ship these plug-ins</li><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">People writing elements should base their code on these elements</li><li style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">These elements come with examples, documentation, and regression tests</li></ul><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Ubuntu,Arial,"libra sans",sans-serif;vertical-align:baseline;clear:both;color:rgb(17,17,17)"><strong style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline">gst-plugins-good</strong><br style="margin-bottom:0px">a set of plug-ins that we consider to have good quality code, correct functionality, our preferred license (LGPL for the plug-in code, LGPL or LGPL-compatible for the supporting library).</p><ul style="margin:0px 0px 1em 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Ubuntu,Arial,"libra sans",sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(17,17,17)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">We believe distributors can safely ship these plug-ins</li><li style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">People writing elements should base their code on these elements</li></ul><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Ubuntu,Arial,"libra sans",sans-serif;vertical-align:baseline;clear:both;color:rgb(17,17,17)"><strong style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline">gst-plugins-ugly</strong><br style="margin-bottom:0px">a set of plug-ins that have good quality and correct functionality, but distributing them might pose problems. The license on either the plug-ins or the supporting libraries might not be how we'd like. The code might be widely known to present patent problems.</p><ul style="margin:0px 0px 1em 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Ubuntu,Arial,"libra sans",sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(17,17,17)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">Distributors should check if they want/can ship these plug-ins</li><li style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">People writing elements should base their code on these elements</li></ul><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Ubuntu,Arial,"libra sans",sans-serif;vertical-align:baseline;clear:both;color:rgb(17,17,17)"><strong style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline">gst-plugins-bad</strong><br style="margin-bottom:0px">a set of plug-ins that aren't up to par compared to the rest. They might be close to being good quality, but they're missing something - be it a good code review, some documentation, a set of tests, a real live maintainer, or some actual wide use. If the blanks are filled in they might be upgraded to become part of either gst-plugins-good or gst-plugins-ugly, depending on the other factors.</p><ul style="margin:0px 0px 0px 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Ubuntu,Arial,"libra sans",sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(17,17,17)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">If the plug-ins break, you can't complain - instead, you can fix the problem and send us a patch, or bribe someone into fixing them for you</li><li style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">New contributors can start here for things to work on</li></ul><div><font color="#111111" face="Ubuntu, Arial, libra sans, sans-serif"><span style="font-size:15px"><br></span></font></div></div><div><font color="#111111" face="Ubuntu, Arial, libra sans, sans-serif"><span style="font-size:15px">For example, let's say that the proposal on type Result <T> is not approved.</span><br></font></div><div><font color="#111111" face="Ubuntu, Arial, libra sans, sans-serif"><span style="font-size:15px"><br></span></font></div><div><font color="#111111" face="Ubuntu, Arial, libra sans, sans-serif"><span style="font-size:15px">The community cam build a Result<T> "project" ate "swift-extension-base" and everyone at "base" level must agree to use then (or improve then) to avoid one of the concerns at Result<T> proposal (several projects build the own)...</span></font><br></div><div><font color="#111111" face="Ubuntu, Arial, libra sans, sans-serif"><span style="font-size:15px"><br></span></font></div><div><font color="#111111" face="Ubuntu, Arial, libra sans, sans-serif"><span style="font-size:15px">So in Swift side maybe the indexer (and the community) can classify projects in this way:</span></font></div><div><font color="#111111" face="Ubuntu, Arial, libra sans, sans-serif"><span style="font-size:15px"><br></span></font></div><div><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;line-height:inherit;vertical-align:baseline;clear:both"><strong style="color:rgb(17,17,17);font-family:inherit;font-size:inherit;margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-stretch:inherit;line-height:inherit;vertical-align:baseline">swift-extension-base </strong>// (Swift Core Team maybe can manager this one)<br style="margin-bottom:0px"></p><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;line-height:inherit;vertical-align:baseline;clear:both"><font color="#111111" face="Ubuntu, Arial, libra sans, sans-serif"><span style="font-size:15px"><u>a small and fixed set of features, covering a small range of possible types of elements</u>; these are continuously kept up-to-date with any core changes during the development series.</span></font></p><ul style="margin:0px 0px 1em 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Ubuntu,Arial,"libra sans",sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(17,17,17)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">We believe distributors can safely ship these features</li><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">People writing elements should base their code on these elements</li><li style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">These elements come with examples, documentation, and regression tests</li></ul><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;line-height:inherit;vertical-align:baseline;clear:both;font-size:15px;font-family:Ubuntu,Arial,"libra sans",sans-serif;color:rgb(17,17,17)"><strong style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline"><strong style="font-family:inherit;font-size:inherit;font-style:inherit;font-variant:inherit;margin:0px;padding:0px;border:0px;font-stretch:inherit;line-height:inherit;vertical-align:baseline">swift-extension</strong>-good </strong><span style="font-family:sans-serif;font-size:13px">// (Community can manage this, and Swift Core Team can do some advices)</span> <br style="margin-bottom:0px">a set of <u>features </u>that we consider to have good quality code, correct functionality, our preferred license<u> (Swift Licence)</u>, and <u>covering a wide range features.</u></p><ul style="margin:0px 0px 1em 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Ubuntu,Arial,"libra sans",sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(17,17,17)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">We believe distributors can safely ship these plug-ins</li><li style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">People writing elements should base their code on these elements</li></ul><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;line-height:inherit;vertical-align:baseline;clear:both;font-size:15px;font-family:Ubuntu,Arial,"libra sans",sans-serif;color:rgb(17,17,17)"><strong style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline"><strong style="font-family:inherit;font-size:inherit;font-style:inherit;font-variant:inherit;margin:0px;padding:0px;border:0px;font-stretch:inherit;line-height:inherit;vertical-align:baseline">swift-extension</strong>-ugly </strong><span style="font-family:sans-serif;font-size:13px">// (Full Community)</span> <br style="margin-bottom:0px">a set of <u>features </u>that have good quality and correct functionality, but distributing them might pose problems. The license on either the or the supporting libraries might not be how we'd like. The code might be widely known to present patent problems.</p><ul style="margin:0px 0px 1em 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Ubuntu,Arial,"libra sans",sans-serif;vertical-align:baseline;list-style-position:initial;color:rgb(17,17,17)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">Distributors should check if they want/can ship these plug-ins</li><li style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">People writing elements should base their code on these elements</li></ul><p style="margin:0px 0px 1em;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;font-size:15px;line-height:inherit;font-family:Ubuntu,Arial,"libra sans",sans-serif;vertical-align:baseline;clear:both;color:rgb(17,17,17)"><strong style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline"><strong style="font-family:inherit;font-size:inherit;font-style:inherit;font-variant:inherit;margin:0px;padding:0px;border:0px;font-stretch:inherit;line-height:inherit;vertical-align:baseline">swift-extension</strong>-bad </strong><span style="font-family:sans-serif;font-size:13px">// (Full Community)</span> <br style="margin-bottom:0px">a set of <u>features </u>that aren't up to par compared to the rest. They might be close to being good quality, but they're missing something - be it a good code review, some documentation, a set of tests, a real live maintainer, or some actual wide use.</p><ul style="margin:0px 0px 0px 30px;padding:0px;border:0px;font-variant-numeric:inherit;font-stretch:inherit;line-height:inherit;vertical-align:baseline;list-style-position:initial;font-size:15px;font-family:Ubuntu,Arial,"libra sans",sans-serif;color:rgb(17,17,17)"><li style="margin:0px 0px 0.5em;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">If the <u>features </u>break, you can't complain - instead, you can fix the problem and send us a patch, or bribe someone into fixing them for you</li><li style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;font-size:inherit;line-height:inherit;font-family:inherit;vertical-align:baseline;word-wrap:break-word">New contributors can start here for things to work on</li></ul></div><div><font color="#111111" face="Ubuntu, Arial, libra sans, sans-serif"><span style="font-size:15px"><br></span></font></div>I just change plugins to feature to make more sense here... And at "base" level we can just drop very small projects, and make few guarantees that will always work. And at good level we can drop bigger projects like Alamofire, Perfect etc, because of the nature of those projects, we know that will get a good support but we cant guarantee that documentation and tests and language updates will always be pair with the rest.<br><br>And at "bad" level, will be like NPM is today... just a easy way to obtain some 3rd party code but no guarantees at all!<div><span style="color:rgb(17,17,17);font-family:Ubuntu,Arial,"libra sans",sans-serif;font-size:15px"><br></span></div>We heve IBM Swift Package Catalog (<a href="https://packagecatalog.com/" target="_blank">https://packagecatalog.com</a>) but i think we can do better.<div><br></div><div><div>Also, if we (and Apple) do nothing, the community someway will do! It's like Brew/Macports at some point people will build the tools to make the ecosystem easier. Is better make something oficial (like npm/nuget) of course.<br></div></div><div><br></div>A "Non-Standard Libraries" its a non start for me, but good indexer, a good integration with SwiftPM, a oficial help/support of the Swift Core Team, and a set of rules/patterns to rule this (and other) projects is a good feature to have.</div><br><div class="gmail_quote"><div dir="ltr">Em ter, 7 de nov de 2017 às 21:16, Alejandro Martinez via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">I’m with Ted on this one. <div>I would also love to see the Swift ecosystem grow but I think that it has to happen with SPM. With improvements on SPM (as discussed in other threads) and having a proper index (imho Cocoapods webpage is the best one out there, with stats about docs, unit testing, downloads...) that makes finding libraries easier. </div><div>But also a discussion forum where great libs can be shared and highlighted to the rest of the community and big community efforts coordinated. If you look at Rust is a great example, their forums attract the whole community (sadly not something the mailing list does) and big and important projects have come up from the community that have made a huge impact. With that in place and some libs out there maturing I’m sure that in the future the conversation to include battle tested code into an oficial distribution would be easier.<br><br><div id="m_-6659677212814100891m_6397394472239744289AppleMailSignature">Sent from my iPad</div></div></div><div dir="auto"><div><div><br>On 7 Nov 2017, at 21:58, Ted Kremenek via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>Hi Dave,<div><br></div><div>Thanks for bringing up this topic. This has been kicked around a little, and we’re still exploring different models on how to extend Swift.</div><div><br></div><div>The server APIs work group is one operational model for the community to build out a new set of core libraries. That work group was formed out of the observation that there were different implementations of the same thing being created by different Swift on server efforts, and that those different efforts should pool those resources together and standardize on some fundamentals.</div><div><br></div><div>That analogy could work here. However, it also has possible major downsides. It can be heavyweight, and also artificially raise the importance of certain people’s library efforts over others by creating a formal work group whose efforts are expected to eventually be incorporated into the core Swift distribution. It would also force a discussion up front of what even makes sense to incorporate into the core Swift distribution, which might be artificially constraining the exploration of the set of libraries to implement.</div><div><br></div><div>I need to think about your idea more, but my first reaction is that my preferred route is that the community builds these libraries, ideally using Swift Packages, and through trial and use we evaluate those libraries and then decide if they should be incorporated as part of the core distribution. There’s many factors involved in deciding if they can be incorporated into the core distribution, but all of those could be informed by actually building libraries and see them getting used.</div><div><br></div><div>We could also figure out a way to possibly highlight these efforts to the Swift community, maybe on swift-evolution or other means — but all with the expectation that these libraries are not *necessarily* going to be standardized as part of the core swift distribution. I don’t think that’s all that bad either; not every library will make sense to incorporate into the core Swift distribution (e.g., they are highly domain specific) but still supporting their development would be beneficial to the community.</div><div><br></div><div>Note that any change going into the Swift core distribution inevitably involves swift-evolution and the core team. Changes going into the core Swift distribution must meet a very high bar as far as implementation and design, the confidence we have into committing to specific APIs (especially since we’ll have ABI stability in Swift 5), and other factors. Thus this will not really alleviate much burden on the Core team or on the community — one of the core goals of your proposal. Further, incorporating all those concerns up front when building libraries might be counterproductive.</div><div><br></div><div>FWIW, Ben Cohen and I have been talking about possibly using Swift packages as a way to seed out experimental ideas for extensions to the Standard Library. This would allow ideas to be trialed by real usage (a complaint I’ve seen about some changes we’ve made to Swift in the past). Users could build things on top of those libraries, knowing they are available as packages, and if an API “graduates” to being part of the Standard Library the user can then depend upon it being available there. If it never graduates, however, the package remains around.</div><div><br></div><div>One thing that resonates me in what you propose is about having a “well-organized effort” whose aim is to make these libraries feel cohesive and implemented well. However, given that many of these naturally fall somewhere in the spectrum of responsibilities within the Standard Library and Foundation, I think it is self-misleading to think that the Core Team or others would not be involved in these efforts if the intention is to possibly incorporate these one day into the core Swift distribution. There also may be other ways to achieve that level of cohesion in API design, such as through community discussion (possibly via the <a href="http://swift.org/" target="_blank">Swift.org</a> mailing lists/forums). This discussion would not necessarily be the same as the path to “ratification” of a library into core Swift, but a step that could benefit many library authors (including considering ideas one day incorporated into the core swift). With such a mechanism many library authors could benefit even if they do not intend to have the library as part of the core distribution.</div><div><br></div><div>My apologies that these are all hand-wavy ideas, but I’m trying to paint a possible alternative way to achieve your goal of more library evolution for Swift without having such a formal work group that may be too heavy weight or too narrowly focused.</div><div><br></div><div>Ted<br><div><br><blockquote type="cite"><div>On Nov 7, 2017, at 9:54 AM, Dave DeLong via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-6659677212814100891m_6397394472239744289Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space">Hi Swift-Evolution,<br><br>The Standard Library's goal is to be small and targeted. However, many aspects of Apple-provided frameworks need or offer opportunities for improvement or wholesale replacement. These enhancements lie beyond the scope of the Standard Library.<br><br>To address this, we'd like to propose the idea of a "Non-Standard Library"; this would be a library that ships with a regular installation of Swift, but is not imported into .swift files by the compiler, unless explicitly requested by the developer.<br><br>We are proposing a well-organized effort to parallel the Standard Library without putting additional implementation responsibilities onto the core team. This effort would mitigate what we see as platform-independent requirements that provide native Swift implementations that aren't burdened by Apple history.<br><br><b>Mission Statement</b><br><br>We propose to create an open-sourced "Non-Standard Library" effort that coexists with, coordinates with, and is blessed by the open source Swift development community. The "Non-Standard Library" will offer a well-curated, high-value collection of routines, types, and documentation to support Swift development on all platforms.<br><br><b>Goals</b><br><br>The main goals of this effort would be:<br><div><ul><li>Alleviate pressure on the Core Team while providing the developer community with functionality that normally falls under Apple's internal development umbrella.</li><li>Deliver authoritative, reliable, and regularly updated libraries avoiding issues faced by third-party dependencies.</li><li>Provide oversight, organization, and full community involvement to ensure its components are worthy, maintained, and passing a bar of need and excellence.</li></ul></div><b>Suggested Libraries</b><br><br>There are several areas we think that are ripe for improvement and implementation as a non-standard library, such as (but not limited to):<br><div><ul><li>A BigNum library</li><li>A full-featured Random library</li><li>A simplified date/time library</li><li>A library for manipulating paths (that is not based on URL or String)</li><li>An expanded Swift-native Geometry library and so forth.</li></ul></div>The scope and extent of the sublibraries would be proposed and debated on a parallel Non-Standard Library Evolution development list.<br><br><b>Coordination</b><br><br>This effort would be fully coordinated with the Swift development team, respecting the team's existing commitments and responsibilities. We would request an Apple body to act as an official coordinator, enabling both oversight of this effort and to expose Apple-sourced suggestions to the Non-Standard community for action.<br><br><b>Next Steps</b><br><br>To proceed, we need a general community consensus that this effort is worth the significant overhead it would involve.<br><br>We must then:<br><div><ul><li>Select a project lead, who appoints technical leaders from the community.</li><li>Recruit a core team, a small group responsible for strategic direction, pulled from experienced members well versed in contributing to Swift-dev.</li><li>Establish a Non-Standard Swift Evolution process, based on the one that is currently followed by Swift Evolution. Following SE practices will guarantee a consistent and excellent language experience for those developers including the Non-Standard library into their projects.</li><li>Build a Non-Standard Swift Evolution repository home.</li><li>Adopt a code license, based on Swift's current licensing.</li><li>Define the community working group rules and code of conduct.</li><li>Establish a mailing list and/or forum.</li><li>Begin the selection of target sublibraries and populating them by recruiting committers and contributors.</li></ul></div><b>Alternative Names</b><br><br>Suggested names for this effort include the following.<br><div><ul><li>Extended-Standard Library</li><li>Community-Standard Library</li><li>Non-Standard Library</li></ul></div>We are not married to any of these names and welcome alternative suggestions.<br><br><b>Measures of Success</b><br><br>A successful Non-Standard Library will provide a stable and incrementally grown ecology of Swift frameworks that developers can depend upon with a minimum of turbulence and regret cycles. For that reason, the most successful content will be core functionality, with significant field testing prior to adoption. We recommend that NSSE follow a model of provisionary adoption and refinement before deployment to ensure any adopting code base will not be affected by later module changes.<div><br></div><div>Thanks,</div><div><br></div><div>Dave DeLong and Erica Sadun</div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div></div></div></blockquote></div></div>