Re: [swift-corelibs-dev] Objective-C Foundation vs CoreLibs Foundation

[Tony Parker via swift-corelibs-dev]

Hi David,

> On May 22, 2016, at 8:15 AM, David Hart via swift-corelibs-dev 
>  wrote:
> 
> Hello,
> 
> The discussion we had previously on this mailing list made it quite clear 
> that:
> 
> - Objective-C Foundation is the framework that is supposed to be used on all 
> Darwin platforms,
> - swift-corelibs-foundation will be the Foundation framework for all other 
> platforms,
> - Both frameworks will evolve slowly together.

Yup.

> 
> Therefore, it makes sense that for code written against Foundation to be 
> portable, the swift-corelibs-foundation APIs and behavior needs to be 
> identical to Darwin Foundation. Hence the following questions?
> 
> - Shouldn't we be writing tests in a way so that they can be run against 
> Darwin Foundation and have the CI Server run them? For example: while working 
> on NSProgress, I write a bunch of tests against Darwin Foundation, make sure 
> they pass, then copy-paste them in the CoreLibs project, and fix the 
> implementation until they pass. This makes sure that both APIs are consistent 
> with each other. I was thinking that we ought to automate this and have the 
> CI server test them.

That would be a great step. This is part of the reason we tried to set up the 
dependencies of Foundation on XCTest the way we did, and provide the Xcode 
project file; so we could share tests. I would welcome any help we can get on 
improving our automation story here.

> 
> - How are we planning to reconcile the API differences between both 
> frameworks? For examples, one of my tests will run against CoreLibs but not 
> against Darwin because NSThread.init takes a closure as argument in CoreLibs 
> but a target+selector in Darwin. This is just one example, but I guess they 
> are other inconsistencies elsewhere. This seems to be particularly the case 
> with APIs that rely on the Objective-C runtime.
> 

These should be marked as “experimental” in the documentation comments. If not, 
we should do that.

There are some areas where we just don’t know what to do yet, because of the 
lack of the ObjC runtime and implicit bridging on Linux. In some of those 
places we’ve tried to provide a replacement API and mark it as experimental 
until we can figure out the larger story.

> In general, I'm starting to worry about the state of Foundation from a 
> portability point of view. Once Swift 3 is released, I want to start writing 
> portable swift code that relies on Foundation. And it seems like this will 
> require a huge amount of #if os() everywhere to cope with the differences.
> 
> David
> 

Our long term goal is to enable developers to do this. I acknowledge that we 
have a ways to go to get there. I’ve seen an uptick in contributions recently, 
which gives me hope that we can get closer before the release of Swift 3.

- Tony

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] swift-corelibs-xctest JIRA dashboard

[Daniel Dunbar via swift-corelibs-dev]

Following up on Brian's JIRA dashboard for XCTest, I copied his model and 
created a dashboard for SwiftPM:
  https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10409
and defined several useful SwiftPM public filters:

 - Package Manager All Tasks: https://bugs.swift.org/issues/?filter=10477
 - Package Manager Open Tasks: https://bugs.swift.org/issues/?filter=10474
 - Package Manager Open 3.0 Tasks: https://bugs.swift.org/issues/?filter=10472
 - Package Manager Open Starter Tasks: 
https://bugs.swift.org/issues/?filter=10473

Thanks to Brian for the inspiration!

 - Daniel

> On May 22, 2016, at 12:47 PM, Brian Gesiak via swift-corelibs-dev 
>  wrote:
> 
> Hello all!
> 
> If you're like me, you might be curious how Core Libraries like 
> swift-corelibs-xctest are doing with regards to the looming Swift 3.0 
> release. Well, wonder no more -- this handy JIRA dashboard has the 
> information you need: 
> https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10408 
> 
> 
> The dashboard not only lists tasks that need to be resolved by Swift 3.0, but 
> also open starter tasks for new contributors.
> 
> Let me know if you find it useful! I personally think it'd be neat to have 
> one of these for all the swift-corelibs-* projects, what do you all think? :)
> 
> PS: For those interested, the dashboard is implemented using custom task 
> filters:
> 
> - corelibs-xctest Open Tasks: https://bugs.swift.org/issues/?filter=10469 
> 
> - corelibs-xctest Open 3.0 Tasks: https://bugs.swift.org/issues/?filter=10471 
> 
> - corelibs-xctest Open Starter Tasks: 
> https://bugs.swift.org/issues/?filter=10470 
> 
> 
> To track tasks related to Swift 3.0, I created a new "swift-3.0" label in 
> JIRA. I hope no one minds. (+cc Jordan Rose, I've seen him managing labels on 
> JIRA before.)
> 
> - Brian Gesiak
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> 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

Re: [swift-corelibs-dev] swift-corelibs-xctest JIRA dashboard

[Tony Parker via swift-corelibs-dev]

This is slick!

I would love to have one for Foundation too (although my understanding of JIRA 
is limited at best).

- Tony

> On May 22, 2016, at 12:47 PM, Brian Gesiak via swift-corelibs-dev 
>  wrote:
> 
> Hello all!
> 
> If you're like me, you might be curious how Core Libraries like 
> swift-corelibs-xctest are doing with regards to the looming Swift 3.0 
> release. Well, wonder no more -- this handy JIRA dashboard has the 
> information you need: 
> https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10408 
> 
> 
> The dashboard not only lists tasks that need to be resolved by Swift 3.0, but 
> also open starter tasks for new contributors.
> 
> Let me know if you find it useful! I personally think it'd be neat to have 
> one of these for all the swift-corelibs-* projects, what do you all think? :)
> 
> PS: For those interested, the dashboard is implemented using custom task 
> filters:
> 
> - corelibs-xctest Open Tasks: https://bugs.swift.org/issues/?filter=10469 
> 
> - corelibs-xctest Open 3.0 Tasks: https://bugs.swift.org/issues/?filter=10471 
> 
> - corelibs-xctest Open Starter Tasks: 
> https://bugs.swift.org/issues/?filter=10470 
> 
> 
> To track tasks related to Swift 3.0, I created a new "swift-3.0" label in 
> JIRA. I hope no one minds. (+cc Jordan Rose, I've seen him managing labels on 
> JIRA before.)
> 
> - Brian Gesiak
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> 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

Re: [swift-corelibs-dev] swift-corelibs-xctest JIRA dashboard

[David Hart via swift-corelibs-dev]

Brian Gesiak started started one for foundation. It seems it's only missing 
some trimming and labeling of issues:

> David,
> 
> I actually started on one! http://tinyurl.com/foundation-dashboard :)
> 
> Like you mentioned, I don't have a ton of context on the project, so I'm a 
> little hesitant to decide what should be tagged with "swift-3.0".
> 
> Still, one thing that stands out: swift-corelibs-foundation has only one task 
> with the StarterBug label! I wonder if some tasks can be cleaned up, given 
> clearer instructions, and labeled as a starter task...
> 
> - Brian Gesi


> On 23 May 2016, at 22:41, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> This is slick!
> 
> I would love to have one for Foundation too (although my understanding of 
> JIRA is limited at best).
> 
> - Tony
> 
>> On May 22, 2016, at 12:47 PM, Brian Gesiak via swift-corelibs-dev 
>>  wrote:
>> 
>> Hello all!
>> 
>> If you're like me, you might be curious how Core Libraries like 
>> swift-corelibs-xctest are doing with regards to the looming Swift 3.0 
>> release. Well, wonder no more -- this handy JIRA dashboard has the 
>> information you need: 
>> https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10408
>> 
>> The dashboard not only lists tasks that need to be resolved by Swift 3.0, 
>> but also open starter tasks for new contributors.
>> 
>> Let me know if you find it useful! I personally think it'd be neat to have 
>> one of these for all the swift-corelibs-* projects, what do you all think? :)
>> 
>> PS: For those interested, the dashboard is implemented using custom task 
>> filters:
>> 
>> - corelibs-xctest Open Tasks: https://bugs.swift.org/issues/?filter=10469
>> - corelibs-xctest Open 3.0 Tasks: https://bugs.swift.org/issues/?filter=10471
>> - corelibs-xctest Open Starter Tasks: 
>> https://bugs.swift.org/issues/?filter=10470
>> 
>> To track tasks related to Swift 3.0, I created a new "swift-3.0" label in 
>> JIRA. I hope no one minds. (+cc Jordan Rose, I've seen him managing labels 
>> on JIRA before.)
>> 
>> - Brian Gesiak
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> 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
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Objective-C Foundation vs CoreLibs Foundation

[David Hart via swift-corelibs-dev]

Would you agree that the first step should be to have the project as a SwiftPM 
package so that we have a more consistent way to run tests on all platforms? Do 
you know if SwiftPM is far enough to support swift-corelibs-foundation? I might 
have a go at it once I finish implementing NSProgress (about half way through I 
think).

> On 23 May 2016, at 17:59, Tony Parker via swift-corelibs-dev 
>  wrote:
> 
> Hi David,
> 
>> On May 22, 2016, at 8:15 AM, David Hart via swift-corelibs-dev 
>>  wrote:
>> 
>> Hello,
>> 
>> The discussion we had previously on this mailing list made it quite clear 
>> that:
>> 
>> - Objective-C Foundation is the framework that is supposed to be used on all 
>> Darwin platforms,
>> - swift-corelibs-foundation will be the Foundation framework for all other 
>> platforms,
>> - Both frameworks will evolve slowly together.
> 
> Yup.
> 
>> 
>> Therefore, it makes sense that for code written against Foundation to be 
>> portable, the swift-corelibs-foundation APIs and behavior needs to be 
>> identical to Darwin Foundation. Hence the following questions?
>> 
>> - Shouldn't we be writing tests in a way so that they can be run against 
>> Darwin Foundation and have the CI Server run them? For example: while 
>> working on NSProgress, I write a bunch of tests against Darwin Foundation, 
>> make sure they pass, then copy-paste them in the CoreLibs project, and fix 
>> the implementation until they pass. This makes sure that both APIs are 
>> consistent with each other. I was thinking that we ought to automate this 
>> and have the CI server test them.
> 
> That would be a great step. This is part of the reason we tried to set up the 
> dependencies of Foundation on XCTest the way we did, and provide the Xcode 
> project file; so we could share tests. I would welcome any help we can get on 
> improving our automation story here.
> 
>> 
>> - How are we planning to reconcile the API differences between both 
>> frameworks? For examples, one of my tests will run against CoreLibs but not 
>> against Darwin because NSThread.init takes a closure as argument in CoreLibs 
>> but a target+selector in Darwin. This is just one example, but I guess they 
>> are other inconsistencies elsewhere. This seems to be particularly the case 
>> with APIs that rely on the Objective-C runtime.
> 
> These should be marked as “experimental” in the documentation comments. If 
> not, we should do that.
> 
> There are some areas where we just don’t know what to do yet, because of the 
> lack of the ObjC runtime and implicit bridging on Linux. In some of those 
> places we’ve tried to provide a replacement API and mark it as experimental 
> until we can figure out the larger story.
> 
>> In general, I'm starting to worry about the state of Foundation from a 
>> portability point of view. Once Swift 3 is released, I want to start writing 
>> portable swift code that relies on Foundation. And it seems like this will 
>> require a huge amount of #if os() everywhere to cope with the differences.
>> 
>> David
> 
> Our long term goal is to enable developers to do this. I acknowledge that we 
> have a ways to go to get there. I’ve seen an uptick in contributions 
> recently, which gives me hope that we can get closer before the release of 
> Swift 3.
> 
> - Tony
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> 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

Re: [swift-corelibs-dev] Objective-C Foundation vs CoreLibs Foundation

[Philippe Hausler via swift-corelibs-dev]

There are a few considerations for the package manager: we may have circular 
build requirements, swift-corelibs-foundation does some squirrelly things with 
linking and compilation like linker scripts and tacked on assembly data 
segments. I am not certain those edge use cases are supported yet.

The Python config file is way too complex as it is and was only really designed 
as a stopgap measure. If we can simplify I think it would definitely improve 
the state of things: it is worth investigating.

Sent from my iPhone

> On May 23, 2016, at 3:03 PM, David Hart via swift-corelibs-dev 
>  wrote:
> 
> Would you agree that the first step should be to have the project as a 
> SwiftPM package so that we have a more consistent way to run tests on all 
> platforms? Do you know if SwiftPM is far enough to support 
> swift-corelibs-foundation? I might have a go at it once I finish implementing 
> NSProgress (about half way through I think).
> 
>> On 23 May 2016, at 17:59, Tony Parker via swift-corelibs-dev 
>>  wrote:
>> 
>> Hi David,
>> 
>>> On May 22, 2016, at 8:15 AM, David Hart via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> The discussion we had previously on this mailing list made it quite clear 
>>> that:
>>> 
>>> - Objective-C Foundation is the framework that is supposed to be used on 
>>> all Darwin platforms,
>>> - swift-corelibs-foundation will be the Foundation framework for all other 
>>> platforms,
>>> - Both frameworks will evolve slowly together.
>> 
>> Yup.
>> 
>>> 
>>> Therefore, it makes sense that for code written against Foundation to be 
>>> portable, the swift-corelibs-foundation APIs and behavior needs to be 
>>> identical to Darwin Foundation. Hence the following questions?
>>> 
>>> - Shouldn't we be writing tests in a way so that they can be run against 
>>> Darwin Foundation and have the CI Server run them? For example: while 
>>> working on NSProgress, I write a bunch of tests against Darwin Foundation, 
>>> make sure they pass, then copy-paste them in the CoreLibs project, and fix 
>>> the implementation until they pass. This makes sure that both APIs are 
>>> consistent with each other. I was thinking that we ought to automate this 
>>> and have the CI server test them.
>> 
>> That would be a great step. This is part of the reason we tried to set up 
>> the dependencies of Foundation on XCTest the way we did, and provide the 
>> Xcode project file; so we could share tests. I would welcome any help we can 
>> get on improving our automation story here.
>> 
>>> 
>>> - How are we planning to reconcile the API differences between both 
>>> frameworks? For examples, one of my tests will run against CoreLibs but not 
>>> against Darwin because NSThread.init takes a closure as argument in 
>>> CoreLibs but a target+selector in Darwin. This is just one example, but I 
>>> guess they are other inconsistencies elsewhere. This seems to be 
>>> particularly the case with APIs that rely on the Objective-C runtime.
>> 
>> These should be marked as “experimental” in the documentation comments. If 
>> not, we should do that.
>> 
>> There are some areas where we just don’t know what to do yet, because of the 
>> lack of the ObjC runtime and implicit bridging on Linux. In some of those 
>> places we’ve tried to provide a replacement API and mark it as experimental 
>> until we can figure out the larger story.
>> 
>>> In general, I'm starting to worry about the state of Foundation from a 
>>> portability point of view. Once Swift 3 is released, I want to start 
>>> writing portable swift code that relies on Foundation. And it seems like 
>>> this will require a huge amount of #if os() everywhere to cope with the 
>>> differences.
>>> 
>>> David
>> 
>> Our long term goal is to enable developers to do this. I acknowledge that we 
>> have a ways to go to get there. I’ve seen an uptick in contributions 
>> recently, which gives me hope that we can get closer before the release of 
>> Swift 3.
>> 
>> - Tony
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> 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
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Objective-C Foundation vs CoreLibs Foundation

[Daniel Dunbar via swift-corelibs-dev]

> On May 23, 2016, at 3:34 PM, Philippe Hausler via swift-corelibs-dev 
>  wrote:
> 
> There are a few considerations for the package manager: we may have circular 
> build requirements, swift-corelibs-foundation does some squirrelly things 
> with linking and compilation like linker scripts and tacked on assembly data 
> segments. I am not certain those edge use cases are supported yet.

They are not, and I would view them as a stretch for 3.0 at this point.

The combination of this and the circular build problem makes me think that we 
should probably expect to maintain a Foundation-specific build solution for the 
time being.

 - Daniel

> 
> The Python config file is way too complex as it is and was only really 
> designed as a stopgap measure. If we can simplify I think it would definitely 
> improve the state of things: it is worth investigating.
> 
> Sent from my iPhone
> 
>> On May 23, 2016, at 3:03 PM, David Hart via swift-corelibs-dev 
>>  wrote:
>> 
>> Would you agree that the first step should be to have the project as a 
>> SwiftPM package so that we have a more consistent way to run tests on all 
>> platforms? Do you know if SwiftPM is far enough to support 
>> swift-corelibs-foundation? I might have a go at it once I finish 
>> implementing NSProgress (about half way through I think).
>> 
>>> On 23 May 2016, at 17:59, Tony Parker via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> Hi David,
>>> 
 On May 22, 2016, at 8:15 AM, David Hart via swift-corelibs-dev 
  wrote:
 
 Hello,
 
 The discussion we had previously on this mailing list made it quite clear 
 that:
 
 - Objective-C Foundation is the framework that is supposed to be used on 
 all Darwin platforms,
 - swift-corelibs-foundation will be the Foundation framework for all other 
 platforms,
 - Both frameworks will evolve slowly together.
>>> 
>>> Yup.
>>> 
 
 Therefore, it makes sense that for code written against Foundation to be 
 portable, the swift-corelibs-foundation APIs and behavior needs to be 
 identical to Darwin Foundation. Hence the following questions?
 
 - Shouldn't we be writing tests in a way so that they can be run against 
 Darwin Foundation and have the CI Server run them? For example: while 
 working on NSProgress, I write a bunch of tests against Darwin Foundation, 
 make sure they pass, then copy-paste them in the CoreLibs project, and fix 
 the implementation until they pass. This makes sure that both APIs are 
 consistent with each other. I was thinking that we ought to automate this 
 and have the CI server test them.
>>> 
>>> That would be a great step. This is part of the reason we tried to set up 
>>> the dependencies of Foundation on XCTest the way we did, and provide the 
>>> Xcode project file; so we could share tests. I would welcome any help we 
>>> can get on improving our automation story here.
>>> 
 
 - How are we planning to reconcile the API differences between both 
 frameworks? For examples, one of my tests will run against CoreLibs but 
 not against Darwin because NSThread.init takes a closure as argument in 
 CoreLibs but a target+selector in Darwin. This is just one example, but I 
 guess they are other inconsistencies elsewhere. This seems to be 
 particularly the case with APIs that rely on the Objective-C runtime.
>>> 
>>> These should be marked as “experimental” in the documentation comments. If 
>>> not, we should do that.
>>> 
>>> There are some areas where we just don’t know what to do yet, because of 
>>> the lack of the ObjC runtime and implicit bridging on Linux. In some of 
>>> those places we’ve tried to provide a replacement API and mark it as 
>>> experimental until we can figure out the larger story.
>>> 
 In general, I'm starting to worry about the state of Foundation from a 
 portability point of view. Once Swift 3 is released, I want to start 
 writing portable swift code that relies on Foundation. And it seems like 
 this will require a huge amount of #if os() everywhere to cope with the 
 differences.
 
 David
>>> 
>>> Our long term goal is to enable developers to do this. I acknowledge that 
>>> we have a ways to go to get there. I’ve seen an uptick in contributions 
>>> recently, which gives me hope that we can get closer before the release of 
>>> Swift 3.
>>> 
>>> - Tony
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org
>>> 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
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_

Re: [swift-corelibs-dev] swift-corelibs-xctest JIRA dashboard

[Brian Gesiak via swift-corelibs-dev]

I'm glad people are finding these useful!!

Yes, I've made one for corelibs-foundation as well:
https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10410

Of course, as David mentioned, task curation is what makes these dashboards
really shine. Try assigning the "swift-3.0" label to tasks that should be
taken care of in time for its release. Also, I noticed
swift-corelibs-foundation doesn't have many tasks with the "StarterBug"
label. I think those are a great way to encourage more people to contribute.

- Brian Gesiak


On Mon, May 23, 2016 at 5:57 PM, David Hart  wrote:

> Brian Gesiak started started one for foundation. It seems it's only
> missing some trimming and labeling of issues:
>
> David,
>
> I actually started on one! http://tinyurl.com/foundation-dashboard :)
>
> Like you mentioned, I don't have a ton of context on the project, so I'm a
> little hesitant to decide what should be tagged with "swift-3.0".
>
> Still, one thing that stands out: swift-corelibs-foundation has only one
> task with the StarterBug label! I wonder if some tasks can be cleaned up,
> given clearer instructions, and labeled as a starter task...
>
> - Brian Gesi
>
>
> On 23 May 2016, at 22:41, Tony Parker via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
> This is slick!
>
> I would love to have one for Foundation too (although my understanding of
> JIRA is limited at best).
>
> - Tony
>
> On May 22, 2016, at 12:47 PM, Brian Gesiak via swift-corelibs-dev <
> swift-corelibs-dev@swift.org> wrote:
>
> Hello all!
>
> If you're like me, you might be curious how Core Libraries like
> swift-corelibs-xctest are doing with regards to the looming Swift 3.0
> release. Well, wonder no more -- this handy JIRA dashboard has the
> information you need:
> https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10408
>
> The dashboard not only lists tasks that need to be resolved by Swift 3.0,
> but also open starter tasks for new contributors.
>
> Let me know if you find it useful! I personally think it'd be neat to have
> one of these for all the swift-corelibs-* projects, what do you all think?
> :)
>
> PS: For those interested, the dashboard is implemented using custom task
> filters:
>
> - corelibs-xctest Open Tasks: https://bugs.swift.org/issues/?filter=10469
> - corelibs-xctest Open 3.0 Tasks:
> https://bugs.swift.org/issues/?filter=10471
> - corelibs-xctest Open Starter Tasks:
> https://bugs.swift.org/issues/?filter=10470
>
> To track tasks related to Swift 3.0, I created a new "swift-3.0" label in
> JIRA. I hope no one minds. (+cc Jordan Rose, I've seen him managing labels
> on JIRA before.)
>
> - Brian Gesiak
>
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> 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
>
>
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] swift-corelibs-xctest JIRA dashboard

[Philippe Hausler via swift-corelibs-dev]

I took a few moments to file a few more starters for Foundation (hopefully I 
should be able to fill out a few more soon). I ran across a some nice ones that 
should be relatively trivial to knock out. I think for Foundation the marker 
for a good starter bug would be things that are highly testable with a reduced 
scope of interfaces. Formatter subclasses are a great point to start with. Some 
of the NSUnimplemented methods are minefields that would require runtime 
support, whereas others are great points to start with.

Furthermore there will likely be a few good ones that will come in when the 
proposals start to land; there is a lot of busy work with the whole naming 
changes. So stay tuned on that front.

> On May 23, 2016, at 7:18 PM, Brian Gesiak via swift-corelibs-dev 
>  wrote:
> 
> I'm glad people are finding these useful!!
> 
> Yes, I've made one for corelibs-foundation as well: 
> https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10410 
> 
> 
> Of course, as David mentioned, task curation is what makes these dashboards 
> really shine. Try assigning the "swift-3.0" label to tasks that should be 
> taken care of in time for its release. Also, I noticed 
> swift-corelibs-foundation doesn't have many tasks with the "StarterBug" 
> label. I think those are a great way to encourage more people to contribute.
> 
> - Brian Gesiak
> 
> 
> On Mon, May 23, 2016 at 5:57 PM, David Hart  > wrote:
> Brian Gesiak started started one for foundation. It seems it's only missing 
> some trimming and labeling of issues:
> 
>> David,
>> 
>> I actually started on one! http://tinyurl.com/foundation-dashboard 
>>  :)
>> 
>> Like you mentioned, I don't have a ton of context on the project, so I'm a 
>> little hesitant to decide what should be tagged with "swift-3.0".
>> 
>> Still, one thing that stands out: swift-corelibs-foundation has only one 
>> task with the StarterBug label! I wonder if some tasks can be cleaned up, 
>> given clearer instructions, and labeled as a starter task...
>> 
>> - Brian Gesi
> 
> 
> On 23 May 2016, at 22:41, Tony Parker via swift-corelibs-dev 
> mailto:swift-corelibs-dev@swift.org>> wrote:
> 
>> This is slick!
>> 
>> I would love to have one for Foundation too (although my understanding of 
>> JIRA is limited at best).
>> 
>> - Tony
>> 
>>> On May 22, 2016, at 12:47 PM, Brian Gesiak via swift-corelibs-dev 
>>> mailto:swift-corelibs-dev@swift.org>> wrote:
>>> 
>>> Hello all!
>>> 
>>> If you're like me, you might be curious how Core Libraries like 
>>> swift-corelibs-xctest are doing with regards to the looming Swift 3.0 
>>> release. Well, wonder no more -- this handy JIRA dashboard has the 
>>> information you need: 
>>> https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10408 
>>> 
>>> 
>>> The dashboard not only lists tasks that need to be resolved by Swift 3.0, 
>>> but also open starter tasks for new contributors.
>>> 
>>> Let me know if you find it useful! I personally think it'd be neat to have 
>>> one of these for all the swift-corelibs-* projects, what do you all think? 
>>> :)
>>> 
>>> PS: For those interested, the dashboard is implemented using custom task 
>>> filters:
>>> 
>>> - corelibs-xctest Open Tasks: https://bugs.swift.org/issues/?filter=10469 
>>> 
>>> - corelibs-xctest Open 3.0 Tasks: 
>>> https://bugs.swift.org/issues/?filter=10471 
>>> 
>>> - corelibs-xctest Open Starter Tasks: 
>>> https://bugs.swift.org/issues/?filter=10470 
>>> 
>>> 
>>> To track tasks related to Swift 3.0, I created a new "swift-3.0" label in 
>>> JIRA. I hope no one minds. (+cc Jordan Rose, I've seen him managing labels 
>>> on JIRA before.)
>>> 
>>> - Brian Gesiak
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org 
>>> 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 
>> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> 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

[swift-corelibs-dev] my email

[developer--- via swift-corelibs-dev]

my email



___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev