Precedence: list
MIME-Version: 1.0
From: William Pitcock <nenolod@dereferenced.org>
Date: Mon, 24 Apr 2017 00:35:49 -0500
Message-ID: <CA+T2pCFE5P_2dpd82TDVMev4Go3EmXLV4ENm8iMNdamOpbwt8A@mail.gmail.com>
Subject: [alpine-devel] RFC: two new subprojects for dealing with industrial uses of alpine
 and upstreams wanting to get their stuff into alpine
To: alpine-dev <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain; charset=UTF-8

Hi,

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.

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).

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

- IBM wants Alpine on PPC64LE (this is a success, but the initial
interaction was awkward)

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
directly)

- 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

Thoughts?

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---