I work in LinuxKit (among other things) at Docker.
On 24 April 2017 at 06:35, William Pitcock <nenolod_at_dereferenced.org> wrote:
> A common observation I have made is that frequently industrial users
> of Alpine don't really know how to optimally engage the distribution
> maintainers. While there are some partial success stories such as
> Docker (who employ Alpine developers and of course the guy who started
> it all), it seems to me that a more productive relationship could be
> established with many industrial consumers. As an example specific to
> Docker, their LinuxKit project seems like an area where better
> technical collaboration could happen -- some of the things they are
> doing probably would be better for all parties if they were done
> directly in Alpine. In the case of LinuxKit, there are obvious
> philosophical differences, but it's a conversation worth having.
LinuxKit originally was directly Alpine for a long time, but it seemed
a good opportunity to experiment with doing something a bit differently.
It would be nice if it reconverged with upstream at some point, but we
are still using Alpine for building everything, and getting much of the code.
> But they are not the only industrial consumer of Alpine, there is
> Flockport and many others. Not to mention all of the companies
> offering Alpine builds of their software.
> Another related concern is getting upstream software into Alpine.
> Largely, there are companies building their own repositories and
> distributing the software that way, which is fine, but it would be
> better for everyone if we could get that software into Alpine itself
> (assuming that it is compliant with our guidelines of course).
It is a great improvement that companies are getting their code to
work with Alpine/Musl and its certainly a lot better than it was, but
yes having more upstream would be useful.
> I think for the most part, upstreams don't have a good story for
> achieving this, or perhaps are convinced that it is not worth it.
> This is unfortunate because at least, in my opinion, the best
> maintainer of a package is the person that is putting out the releases
> upstream *anyway*.
> Some examples of upstream opportunities:
> - Microsoft wants .Net Core on Alpine, why not go all the way and have
> this be an officially supported package?
> - The work being done for Rust
> - Crystal (another LLVM language) is presently shipping it's own
> binaries on Alpine, but they never reached out to get it included in
> Alpine itself
> - Pony (another LLVM language) has the same situation
The LLVM languages have been a pain, for many different reasons, I have
only been following the Rust saga, but the end result seems great, even
if it took longer than we would have hoped.
I do like the NetBSD model where there are two ways to build the whole distro,
one with gcc and one with llvm, for the entire system. It is a lot of work but
would help make sure everything works with the llvm toolchain.
> - IBM wants Alpine on PPC64LE (this is a success, but the initial
> interaction was awkward)
I don't think this was entirely Alpine's fault, I don't think IBM knew how to
get this to happen initially either.
> As such, I would like to propose that we establish a team which:
> - reaches out to projects that consume Alpine (such as Docker's
> LinuxKit) and have a conversation about how downstream changes could
> be better integrated
> - reaches out to upstream projects that are sending us patches to make
> their software work and engage them on getting their software directly
> in Alpine
> - mentors upstream/downstream developers to get their patches into
> Alpine as well as recruiting them to be active Developers (as in the
> status, e.g. having access to push their packages to the distribution
> - acts as a general point of contact (with a specialized mailing list
> perhaps) for inquiries / concerns of upstreams and downstreams for
> guidance on engaging the Alpine project
I think at least some guidance and examples of how to engage for that
audience would be
useful as a starting point.
Received on Thu May 11 2017 - 11:40:21 UTC