I was not aware that publicly setting boundaries on what is a supportable configuration and what wasn't one was somehow equivalent to white nationalist syndicalism, but thanks for letting me know.
When your first reaction in all this was to figure out a way to try to block a third-party package from being installed, and then you make comments like... "we feel it appropriate to signal our position more
forcefully." And then you lock comments on GitLab from people commenting..
You could have, before even writing the blog post, posted an issue on their GitHub to try seeing if they can post a more noticeable disclaimer... although it doesn't really even need one and is pretty inherent, just like all the other Docker Hub images using Alpine in their name to indicate the underlying distro.
The issue is not the package. Obviously Sasha is allowed to publish whatever packages he wishes.
The problem is that third parties take his package and then describe the combination of Alpine with his package in such a way that people are led to believe is totally stock Alpine.
This then causes many people to complain in Alpine support channels, or on websites like this one, that Alpine is "buggy" in ways that cannot be reproduced on real Alpine.
You also assume that this is our first reaction.
Our first reaction was 6 years ago when it first came out: meh.
No, this is our first reaction to a large company trying to pass off their hackjob images combining Alpine, glibc and a glibc JDK as a certified JDK that is running on stock Alpine.
It is unfortunate that we have waited this long to put our foot down, honestly!
We need to support our friends in the Docker community who manage the Docker Library who also get to deal with the fallout of these hackjob images.
The person who makes the hackjob rarely faces the consequences of it breaking, that basically has always fallen on us, or on the Docker Library team, or on some other team in the ecosystem that has to deal with somebody who is mad because their application has failed due to some shoddy work done by somebody 2 years ago.
Stop assuming this is our "first" reaction. It isn't. I even said it wasn't to begin with -- a "first" reaction cannot logically be an escalation from a previous position, it must be an initial one.
> The issue is not the package. Obviously Sasha is allowed to publish whatever packages he wishes.
> The problem is that third parties take his package and then describe the combination of Alpine with his package in such a way that people are led to believe is totally stock Alpine.
You were specifically trying to block the package from being installed without recompiling musl.
> This then causes many people to complain in Alpine support channels, or on websites like this one, that Alpine is "buggy" in ways that cannot be reproduced on real Alpine.
You're putting too much pressure on yourself. This is simple... if someone isn't using the official Alpine image (alpine) then they should ask for support from the image creator, as there are thousands of things that can go wrong outside of you control.
> No, this is our first reaction to a large company trying to pass off their hackjob images combining Alpine, glibc and a glibc JDK as a certified JDK that is running on stock Alpine.
Labeling other developers work as hackjob images is condescending. Your whole post was condescending. Just because someone has alpine in an image tag doesn't mean that they are trying to indicate that it uses stock Alpine as the base image, but instead that it uses Alpine as the underlying distro. Who knows what software or changes they've added to it that may cause issues outside of Alpine's control.
> It is unfortunate that we have waited this long to put our foot down, honestly!
> We need to support our friends in the Docker community who manage the Docker Library who also get to deal with the fallout of these hackjob images.
> The person who makes the hackjob rarely faces the consequences of it breaking, that basically has always fallen on us, or on the Docker Library team, or on some other team in the ecosystem that has to deal with somebody who is mad because their application has failed due to some shoddy work done by somebody 2 years ago.
Seriously, these comments only show that this is more about control for you than anything. I can't say for sure, but I have a feeling that eventually other people in the community will either leave or ask you to leave for toxic behavior like this.
The only reason I took any position at all on this issue is because other partners in the Alpine / Cloud Native ecosystem requested that we clarify our position on mixing musl and glibc runtimes.
You ignore the point I am making: people are already fighting this issue for years, and Alpine has not taken a position on it until now.
We should have done so sooner, but unfortunately we did not, so a more theatric approach is sometimes needed to make a point.
We want to discourage bad practices in the creation of alpine-based images, so that our partners (such as the Docker library team) do not have to deal with user complaints with images, or feel like companies are bullying them into accepting images they know are built with bad practices.
If you call taking action to provide assistance requested by our ecosystem partners (who have been thrilled that we are putting our foot down by the way) toxic behavior I wouldn’t want to know what your idea of a party is to be blunt.
You could have, before even writing the blog post, posted an issue on their GitHub to try seeing if they can post a more noticeable disclaimer... although it doesn't really even need one and is pretty inherent, just like all the other Docker Hub images using Alpine in their name to indicate the underlying distro.