I did this search to try and find some: https://github.com/apple/swift-corelibs-foundation/pulls?utf8=✓&q=is%3Apr+is%3Aclosed+is%3Aunmerged <https://github.com/apple/swift-corelibs-foundation/pulls?utf8=%E2%9C%93&q=is:pr+is:closed+is:unmerged>
Here’s one: https://github.com/apple/swift-corelibs-foundation/pull/226 <https://github.com/apple/swift-corelibs-foundation/pull/226> Here was another that we had difficulty getting through review on: https://github.com/apple/swift-corelibs-foundation/pull/248 <https://github.com/apple/swift-corelibs-foundation/pull/248> Here is an old one that had some hard to figure out merge conflicts: https://github.com/apple/swift-corelibs-foundation/pull/225 <https://github.com/apple/swift-corelibs-foundation/pull/225> There are probably more… Some of the root cause has been our own failure in getting these merged quickly, which I’m trying to improve on. - Tony > On May 13, 2016, at 10:26 AM, James Lee <ja...@jelee.co.uk> wrote: > > Wanted to chirp up and say I am in the same position as David, with that > said, if PR's have been rejected due to a lack of response, are there any > that have not been covered elsewhere and can be picked up? > > James > > Sent from my iPhone > > On 13 May 2016, at 18:01, Tony Parker via swift-corelibs-dev > <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: > >> Hi David, >> >>> On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev >>> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: >>> >>> Hello people, >>> >>> I wanted to start giving a hand on corelibs-foundation but hit two >>> obstacles I’d like to discuss: >>> >>> It feels difficult to know where help is needed because the ReleaseNotes, >>> Status and Know Issues 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? >>> >> >> 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. >> >>> 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: >>> >>> TestNSString.test_initializeWithFormat3 >>> TestNSTask.test_pipe_stderr >>> TestNSTask.test_pipe_stdout_and_stderr_same_pipe >>> TestNSTask.test_passthrough_environment >>> TestNSTask.test_no_environment >>> TestNSTask.test_custom_environment >>> TestNSUserDefaults.test_createUserDefaults >>> TestNSUserDefaults.test_getRegisteredDefaultItem >>> TestNSXMLDocument.test_xpath >>> >>> Any ideas? Perhaps I’m doing something wrong. >> >> 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). >> >> NSTask in particular has been under a lot of changes for Linux recently. >> >>> >>> 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? >>> >> >> 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. >> >>> 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? >>> >> >> 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. >> >> 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. >> >> - Tony >> >>> A well meaning developer, >>> David. >>> _______________________________________________ >>> swift-corelibs-dev mailing list >>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev> >> >> _______________________________________________ >> swift-corelibs-dev mailing list >> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
