~alpine/devel

1

[alpine-devel] RFC: two new subprojects for dealing with industrial uses of alpine and upstreams wanting to get their stuff into alpine

William Pitcock <nenolod@dereferenced.org>
Details
Message ID
<CA+T2pCFE5P_2dpd82TDVMev4Go3EmXLV4ENm8iMNdamOpbwt8A@mail.gmail.com>
Sender timestamp
1493012149
DKIM signature
missing
Download raw message
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
---
Details
Message ID
<CAK4o1Ww9RVaqXif4vnEd=eMOyeEMLF1HS_PVE44s=y5E1mOS4w@mail.gmail.com>
In-Reply-To
<CA+T2pCFE5P_2dpd82TDVMev4Go3EmXLV4ENm8iMNdamOpbwt8A@mail.gmail.com> (view parent)
Sender timestamp
1494499221
DKIM signature
missing
Download raw message
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
---
Reply to thread Export thread (mbox)