<div><div dir="auto">On Tue, Nov 7, 2017 at 5:24 PM Wallacy <<a href="mailto:wallacyf@gmail.com">wallacyf@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style="color:rgb(33,33,33)">The Compatibility Suite</span> is a good start, but I agree that something a bit more centralized has its benefits. <br><div><br></div><div>To be perfect, Compatibility Suite and Swift Package Manager need to work "together" to offer something simple like nodejs npm and a friendly (and central) interface to not only find these projects. Something more similar to nuget too.<br></div><div><br></div><div>The only thing I miss using npm and nuget is some kind of "compromise" with maintenance. And also some commitment to (avoid) rework. Several projects remake something that another does also without explaining well the differences between them.<br></div><div><br></div><div>Maybe we don't need to code any "Non-Standard Libraries"! Only a opt-in project like Compatibility Suite with steroids. Not only to track those projects, but in some level help defining some standards, documentations, versioning etc. This can be done entirely within the community.<br></div><div><br></div><div><div>Not so similar, however the gstreamer keeps a list of "base", "good", "ugly" and "bad" plugins for similar reasons.</div><div><br></div><div>We can do something in this line of reasoning:</div><div>- A central repository for projects (like Compatibility Suite)</div><div>- A tool to find and add each project (like SwiftPM)</div><div>- Rules for joining (like Compatibility Suite)</div><div>- A classification for each repository (like gstreamer)</div><div>- A good way to make each project as small and direct as possible (to take advantage of cross-module inlining / specialization)</div><div>- A list of discussion (or a forum?) for people that maintain (or have an interest in maintain) projects in this "official" list.</div></div><div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">I like this approach much more. Feels more natural. And a forum (piggybacking on the eventual Discourse perhaps). I’d only change two things and extend one:</div><div dir="auto"><br></div><div dir="auto">- Instead of “central repository”, a “central index”. It makes it more transparent, more distributed, and closer to the current reality.</div><div dir="auto"><br></div><div dir="auto">- Here:</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div>I vote for empowering SwiftPM and Compatibility Suite instead a "Non-Standard Libraries".</div><div><br></div><div></div></div></blockquote><div dir="auto"><br></div><div dir="auto"><div dir="auto">I agree with a central index, but as Kelvin says, we shouldn’t be using the Compat Suite directly because of GPL issues.</div><div dir="auto"><br></div><div dir="auto">- I’d extend on the “Rules for Joining” point: they should be as clear and explicit as possible, to avoid drama like the one episode that happened last year on the JS repositories with that string-padding library. That thing broke half of the internet for some hours, and it was all about something unclear in the rules, if I remember the case correctly.</div><div dir="auto"><br></div><div dir="auto">That’s all I’d add to Wallace’s list.</div><div dir="auto"><br></div><div dir="auto">On another line, the licenses point brought up by Kelvin made me thought of this: </div><div dir="auto">There could be an integration in SPM or similar, that checked your license. That way:</div><div dir="auto">- It can tell you which projects you can import (that fit with your license). That way, if you’re using the BSD license, this integration doesn’t offer to import GPL projects because that’d make your license inconsistent.</div><div dir="auto">- It can tell you if you need to change your license or remove a package, in order to make your license consistent again. That way, maybe you change to GPL because you realised that the tool you wanted to use is worth it.</div><div dir="auto"><br></div><div dir="auto">This would be important from the perspective of ergonomics and (license-consistent) discovery. It’s a detail, yes. But would be very nice.</div></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div></div><br><div class="gmail_quote"></div><div class="gmail_quote"><div>Em ter, 7 de nov de 2017 às 17:19, Kelvin Ma via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> escreveu:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 7, 2017 at 1:11 PM, Félix Fischer <span><<a href="mailto:felix91gr@gmail.com" target="_blank">felix91gr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br><div class="gmail_quote"></div></div></blockquote></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><span><div dir="auto">On Tue, Nov 7, 2017 at 4:01 PM Kelvin Ma <<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution <span><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Hmm. I kind of like the idea, but not really. I think it has a fundamental flaw: centralization.</div><div dir="auto"><br></div><div dir="auto">You see, the StdLib can be commanded by a central authority (the core team) and hear the needs of the general community (through swift-evolution and such) because, among other things, it’s small. The StdLib solves common and well-understood problems. Most of the solutions it provides are optimal for all use cases.</div><div dir="auto"><br></div><div dir="auto">This is fundamentally different from a non-StdLib. If I understood your idea correctly, it would be the complement of StdLib; it will be big and it will attend problems that are not well-understood or whose solutions have many differrying approaches depending on the users’ neccessities (think Geometry). Therefore, a correct and complete approach would inevitably have to:</div><div dir="auto">- Know the needs of all the relevant user groups and balance their priorities.</div><div dir="auto">- Contain all the important and complementary solutions.</div><div dir="auto"><br></div><div dir="auto">This is very hard to achieve in a centralized system. Not impossible, but very resource-intensive.</div><div dir="auto"><br></div><div dir="auto">You can achieve something similar by letting the community grow and by encouraging a good environment. People will the build the tools they need, and the important voices will index the tools people use the most. That makes them good, as well as easily findable. It’s not perfect either, but it’s more efficient in my opinion.</div><div dir="auto"><br></div><div dir="auto">— Félix Fischer</div></blockquote><div><br></div></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><div>People tend to build the tools they need, but not what other people need. </div></div></div></div></blockquote><div dir="auto"><br></div></span></div></div></blockquote></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div dir="auto">Fair point. Dog-feeding might be an issue, but not necessarily.</div></div></div></blockquote></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><span><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"><div>And there are many many examples from other languages of what can go wrong when non-standard libraries compete.</div></div></div></div></blockquote><div dir="auto"><br></div></span></div></div></blockquote></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div dir="auto">Hmm. Okay, yes. But what about healthy competition? Isn’t that good as well? In which context you get bad results? Can you change the system s.t. you encourage good competition?</div></div></div></blockquote><div><br></div><div>i think in open source, competition is mostly beneficial when you have one old monopoly that’s become lethargic and a new more energetic project upends it, i.e. gcc vs clang. You get a new improved tool, and the old project also gets a wakeup call, which is why you’ve seen such a big improvement in recent versions of gcc. Where there is no such incumbent, and everyone is starting from scratch, it becomes counterproductive.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"></div></div></blockquote></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><span><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"><div> As for important voices indexing the tools people use the most, I don’t see that happening.<br></div></div></div></div></blockquote><div dir="auto"><br></div></span></div></div></blockquote></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div dir="auto">This is easier than it seems. The Compatibility Suite is already an index of important libraries.</div><div dir="auto"><br></div><div dir="auto">Regarding the other problems I see with this proposal: how will you attend the necessities of so many diverse groups? You’d need a whole... consortium, of sorts. You can’t have just a leader: no one knows the context of all the users.</div><div dir="auto"><div dir="auto"><br></div></div></div></div></blockquote><div> </div></div></div><div class="gmail_extra">The Compatibility Suite suffers from licensing issues which prevents a lot of important libraries from being listed in it. GPL libraries are effectively excluded from it.<br></div></div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<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>
</blockquote></div></div>