[swift-dev] SR-122 / CollectionsMoveIndices.swift Prototype

Austin Zheng austinzheng at gmail.com
Sun Feb 21 19:34:04 CST 2016


Hi Dmitri (et al),

I have no personal objection to pull requests. If PRs directly to the Swift project are the best way to do things, let's keep it that way.

Austin

> On Feb 21, 2016, at 5:24 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> 
> On Sun, Feb 21, 2016 at 12:13 PM, Austin Zheng <austinzheng at gmail.com> wrote:
>> Agreed. I created a GitHub organization
>> ('swift-stdlib-opensource-collaborators'), and will try to invite the
>> non-Apple ('outsider') folks to join. Once that's happened, maybe Shawn can
>> move his fork under the organization, or one of us can fork the repo again.
> 
> Hi Austin, Shawn,
> 
> We're still working out the general policy for commit access for
> non-Apple contributors.
> 
> I'm trying to understand the situation better -- could you explain why
> pull requests present too much overhead for this project?  Many Apple
> engineers who have commit access find that the pull request approach
> works better for their day-to-day work.
> 
> My concern is that doing this work in a parallel organization hides
> this project from other contributors who might be interested.  Also,
> you would only get CI coverage in the primary Swift organization.  In
> general, creating a parallel organization sends an ambiguous message
> to other people working on the project.
> 
> Furthermore, even Shawn started his work on this project with a pull
> request against his fork (https://github.com/shawnce/swift/pull/1).
> 
> Could we start with pull requests against the swift-3-indexing-model
> branch in the primary repository, and possibly move to direct commits
> later?
> 
> Dmitri
> 
> -- 
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/



More information about the swift-dev mailing list