<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi David,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello people,<div class=""><br class=""></div><div class="">I wanted to start giving a hand on corelibs-foundation but hit two obstacles I’d like to discuss:</div><div class=""><br class=""></div><div class="">It feels difficult to know where help is needed because the <b class="">ReleaseNotes</b>, <b class="">Status</b> and <b class="">Know Issues</b> docs have not been updated in a very long time, as if abandoned. Hopefully we can update hem, but perhaps a rule should be put in place so that no pull request is merged without the corresponding update in the documentation?</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>Sounds good to me. I don't want to start rejecting PRs because they miss a bit of documentation but hopefully we can encourage it or update it after we merge.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I tried downloading the master branch of corelibs-foundation and running the tests before starting any work, but several of them crashed or failed. I am on OS X, Xcode 7.3.1, up to date on the master branches of corelibs-foundation and corelibs-xctest and am using the latest development snapshot. For reference, the failing tests are:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">TestNSString.test_initializeWithFormat3</li><li class="">TestNSTask.test_pipe_stderr</li><li class="">TestNSTask.test_pipe_stdout_and_stderr_same_pipe</li><li class="">TestNSTask.test_passthrough_environment</li></ul><div class=""><ul class="MailOutline"><li class="">TestNSTask.test_no_environment</li><li class="">TestNSTask.test_custom_environment</li><li class="">TestNSUserDefaults.test_createUserDefaults</li><li class="">TestNSUserDefaults.test_getRegisteredDefaultItem</li><li class="">TestNSXMLDocument.test_xpath</li></ul><div class=""><br class=""></div><div class="">Any ideas? Perhaps I’m doing something wrong.</div></div></div></div></div></blockquote><div><br class=""></div>Our CI system only builds and tests corelibs-foundation on Linux, so perhaps some regressions have snuck in on OS X only (which is interesting if true).</div><div><br class=""></div><div>NSTask in particular has been under a lot of changes for Linux recently.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><br class=""></div></div></div><div class="">I was surprised to see fairly little tests for certain classes NSIndexPath, NSUserDefaults, NSScanner. Is that because the code was written before the Open Source project started? What are the rules on test quality and how are they applied?</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>We’d like to see tests with all new code, for sure. Some of this was written fairly quickly in the run up to the launch, so we probably don’t have as many tests as we would like there. I do have a task on my plate somewhere to figure out how we can integrate more of our internal unit tests into the open source project to help with compatibility.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">More generally, I feel worried at how much work is still left, especially with the 3.0 beta branches starting. Am I imagining things or does it not look very good? What can we do to rally the troops?</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>I totally understand. The Foundation team itself has been focused on the value type changes, naming changes, etc that are coming as part of Swift 3. We haven’t had nearly as much time as I would have liked to dedicate to bringing this project up to parity with Swift 2.2 functionality. We are still hoping to accept as many contributions as possible. That is why I went through and accepted a bunch of PRs last week.</div><div><br class=""></div><div>We have had a few contributions that felt like one-offs; when changes were requested we received no response and so I had to close them, which makes me pretty sad. I haven’t really seen any true ownership of a particular area. I understand it’s asking a lot for someone to come in and help us implement a pre-set API, but I believe in a bright future for this project if we can pick up the pace a bit.</div><div><br class=""></div>- Tony</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">A well meaning developer,</div><div class="">David.</div></div>_______________________________________________<br class="">swift-corelibs-dev mailing list<br class=""><a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev<br class=""></div></blockquote></div><br class=""></div></body></html>