Precedence: list
MIME-Version: 1.0
In-Reply-To: <CA+T2pCFE5P_2dpd82TDVMev4Go3EmXLV4ENm8iMNdamOpbwt8A@mail.gmail.com>
References: <CA+T2pCFE5P_2dpd82TDVMev4Go3EmXLV4ENm8iMNdamOpbwt8A@mail.gmail.com>
From: Justin Cormack <justin@specialbusservice.com>
Date: Thu, 11 May 2017 11:40:21 +0100
Message-ID: <CAK4o1Ww9RVaqXif4vnEd=eMOyeEMLF1HS_PVE44s=y5E1mOS4w@mail.gmail.com>
Subject: Re: [alpine-devel] RFC: two new subprojects for dealing with
 industrial uses of alpine and upstreams wanting to get their stuff into alpine
To: William Pitcock <nenolod@dereferenced.org>
Cc: alpine-dev <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain; charset=UTF-8

Hi,

I work in LinuxKit (among other things) at Docker.

On 24 April 2017 at 06:35, William Pitcock <nenolod@dereferenced.org> wrote:
> 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.

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
> 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

I think at least some guidance and examples of how to engage for that
audience would be
useful as a starting point.

Justin
l


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---