[swift-corelibs-dev] Looking at corelibs-foundation
james at jelee.co.uk
Fri May 13 12:26:38 CDT 2016
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?
Sent from my iPhone
> On 13 May 2016, at 18:01, Tony Parker via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> Hi David,
>> On May 11, 2016, at 4:02 PM, David Hart via swift-corelibs-dev <swift-corelibs-dev at 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:
>> 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,
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev at swift.org
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-corelibs-dev