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

[Ted kremenek]

> 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