[swift-dev] Official Docker Image & "Blessing"s of Community Platforms

[Ted kremenek]

Hi Thomas,

There is an active "yes" here: Docker support is something we think is great for Swift.  Distributing it from Swift.org, if there was an active maintainer, seems great.

That said, in the general case we expect that distributing Swift will be decentralized.  For example, there are many Linux distributions, and while there will be a canonical definition of what the sources are for Swift 2.2, 3.0, etc., the core project will not be in the position to support building packages for every single Linux distribution because the differences are likely subtle changes in configuration.  What packages we distribute directly on Swift.org is something that can evolve over time, partially as we figure out what makes the most sense for the community and the project maintainers.

As for Docker, we expect that public CI will be up for Swift.org very soon.  Once that is in place, we can talk more about mechanizing the production of Docker packages.

Ted

> On Jan 18, 2016, at 12:36 AM, Thomas Catterall <me at swizzlr.co> wrote:
> 
> Hi Ted, all,
> 
> Picking this up after a few days, Haris and I have both had unusually busy weeks (job interviews on my part).
> 
> What I can conclude from this is that there's no active "no" here, and given that an official docker image is better than none, Haris and I will go ahead and work with Docker to start maintaining an official image. You know where to find us!
> 
> When Apple open up their CI to the world, I would love to be involved in helping set up docker infrastructure for that, and distributing snapshots as part of it.
> 
> Onwards to a containerised future!
> 
> As for the more general issue about blessing distributions, I'm glad we've had some discussion about this - I'm sure it's generated some internally as well, and for now that's all I need to know. The ad hoc basis upon which other distributions are proceeding is quite suited to the low volume for now, and no formal process is necessary. I'm very glad Ted approves of more involvement between the Swift project and third party maintainers, and I hope this view is shared by many more.
> 
> All the best, and I hope you're still having a great new year,
> 
> Tom
> 
> Sent from my iPhone
> 
>> On 11 Jan 2016, at 22:53, Ted kremenek <kremenek at apple.com> wrote:
>> 
>> 
>> 
>>> On Dec 29, 2015, at 10:07 AM, Thomas Catterall via swift-dev <swift-dev at swift.org> wrote:
>>> 
>>> For the matter at hand, Haris and I would like to at the least hear "go for it" from the core team; better yet, we'd love to have anyone from the core team/Apple who is interested in Docker/the build infrastructure to join Haris, Docker and I in creating this official repo, and serving as a representative of Apple's interests in this area.
>>> 
>>> For the larger matter, it seems to me that the Swift Project can take a few directions:
>>> 1. "Knock yourselves out, but we're just making the language." In this direction, the Swift Project would disclaim official support or blessing of anything that doesn't come out of it. Occupation of a top level namespace or being the "official" Swift for a platform would be something for the community to sort out independently with the platform vendor.
>>> 2. "Knock yourselves out, here's a list of all the current efforts that we think you might be interested in"
>>> Not so much as blessing, still disclaiming support, but at the least acknowledging the ecosystem around Swift for other platforms besides OS X and the two Ubuntus.
>>> 3. Blessing: in this direction, which I think a lot of people would like and I would prefer, the Swift project gives its blessing to projects, and links to them on its website. This has the benefit of centralising development efforts and providing an easy springboard for those who are interested in Swift and are checking the website.
>>> 4. Official support: in this direction, when a project meets a certain criteria, it is folded into the main Swift project, given a repo on GitHub etc. This would probably not occur for quite a while yet, but as continuous integration improves for Swift it could make sense that the docker image might be something that is actively supported in the development of Swift if it is sufficiently popular.
>>> 
>>> I'd like to hear back from the core team about this instance of the Docker issue, but I'd also like to start a conversation about community platform support and how centralising issues like this one can be handled in future.
>> 
>> Hi Thomas and Harris,
>> 
>> First, my apologies for the slow response.  Docker + Swift is a great combination that I'd be very interested in exploring as having a more official support from the Swift.org project.
>> 
>> This is something I need to discuss more with the rest of Swift Core, but what I'm looking for is #3 or #4.  From my perspective, having official support for Docker would be about adding a new sibling download next to the Swift binary downloads for Xcode and Linux (Ubuntu).  It's something I think we'd be open for exploring as long as their were active maintainers of the Docker image and a clear way for the Docker images to be built in an automated way.
>> 
>> For reference, right now the snapshots we provide for downloads (both Xcode and Linux) are produced by a continuous integration system we have at Apple.  For context, that continuous integration system should soon be available out in the open.  Ideally, Docker images would also be produced by the same continuous integration system as well, and aligns with what you said for #4.  It would also be important to have a way to make sure the produced Docker packages were functional.
>> 
>> If we took #4, I would imagine there are a couple of code owners for maintaining the Docker image.  They would be responsibility for curating content going into the image itself.  I would also expect them to help define the functionality of that image, and help crafting a story so that it can be maintained in an automated way.
>> 
>> More generally, there's an interesting discussion about increasing the variants of binary packages on Swift.org.  For example, before the open source launch we discussed whether or not to publish rpms, debs, etc. for Linux and settled on tar files because of their simplicity and that we hoped that, if the community interest was there, others besides the Swift team at Apple could play a role in helping provide curated packages for specific distributions.  How exactly this would work logistically will likely have different answers for different platforms.  For some it may make sense to distribute those on Swift.org, and for others to distribute them independently, possibly with a nod from the Swift.org website (option #2 and #3).
>> 
>> Ted
>