most of the software you install with
your package manager is going to be a
tag release it's going to be something
like Firefox 100 alacrity
0.10.1
neovim0.7.0 and the vast majority of the
time it is just going to be a packaged
version of the developer's code but with
the exceptional project let's add its
final version let's say the project is
done or for whatever reason the
developer just wants to abandon it most
of the time development isn't stopping
with that latest tagged release and
usually what you're going to see
especially on the larger projects is
there's going to be a lot of patches
that are being worked on that for
whatever reason didn't make that current
release let's say the patch is not done
yet or it just doesn't fit the general
theme of this release so if you start
exploring pretty much any reasonably
sized project you're going to notice
there's a lot of things like work in
progress draft and unreviewed patches
along with it being extra branches like
the development Branch or the work in
progress Branch or feature branches and
things like that maybe at one point a
lot of these changes are going to make
their way into a actual version release
but right now the developers consider
that these things are not ready for the
regular user to be using but not
everybody agrees that this is the way
that software should be packaged
sometimes you'll see a Linux
distribution ship let's say version one
of Foo and instead of actually shipping
version one what it is is version one
with some extra patches applied to it
some of those work in progress some of
those draft and unreviewed patches so
what this is is effectively a fork of
the project but isn't being labeled as a
fork of the project and this open letter
recently came out basically saying to
stop doing that please do not ship work
in progress to users an open letter from
developers to The Wider Linux Community
now they want to make something clear
and I want to make something very clear
as well this is not being aimed at
individual users this is aimed at
distribution shipping developers patches
without consulting them first breaking
the intended user experience of Upstream
this letter is not aimed at tinkerers
playing with their own setup so let's
say you download a terminal let's say
alacrity for example and it works really
well but you notice in the poor request
you notice in the patches that there's
this patch that would really really
change the way that you use the
application and really improve your
workflow well if you want to go and take
that patch and then compile the
application yourself and merge it into
your own personal version that's totally
fine go ahead and do so because you know
what you're doing you have actively
decided to step out of the intended
developer experience but the
distributions what they should be
offering is the software the developers
made and the way the developers intended
for it to be used from the perspective
of the developer you want your users to
have a stable consistent experience as
an overall idea your project may still
be a work in progress but when you
release see version 1 version 1.1
version 2 so on and so forth you know
what features are supposed to be in that
version and you know what you're
supposed to be getting or by using that
version so if someone comes to you as
say a bug report or they want to get
some user support for example and they
say they are on version one
if they are not really on version one
they're on version one with all of these
extra patches on it there's not really
any productive way to actually handle
that bug report because what's breaking
with it may not actually have anything
to do with your actual version one it
may be some of these extra patches and
then for the users you want to make sure
they're getting a fair perception of the
project sure it might not actually be in
a really good state it might have some
actual legitimate issues but those are
issues that are totally fair if it's the
fault of the developer sure absolutely
fine but if it's an extra patch that
wasn't supposed to be added that the
packager just wanted to add themselves
it's something they wanted to remove
things like that that's not something
that you as the dev can fix but you're
still probably going to be blamed for it
my favorite example of this if you've
seen my channel before you know exactly
what I'm going to say it is OBS on Arch
Linux so OBS on Linux isn't in the same
state it's in over on the window side
there are certainly features that are
missing which would be really nice to
see but those are features that are
actually missing on Arch Linux though
the browser embed is missing this lets
you embed things like your chat and
stream alerts and things like that this
isn't a fault of the OBS team it is
entirely the fault of the Arch Linux
team for not packaging it correctly but
all of the complaints are directed at
OBS because why would the user think any
different when you install OBS on Arch
it says its version let's say version
27.1.0 not 27.1.0 Linux or give you some
indication that this isn't the intended
developer experience this is the
modified Arch experience or how about
you look at some Forum posts from 2007
2008 about the rollout of pulse audio at
that point pulse audio should not have
been shipped as a default on dissert it
was not ready yet it was close to ready
but it certainly wasn't and a lot of the
destroys that we're shipping it were
shipping it with broken configs so it
looked like the project was so much
worse than it actually was but it was
entirely the fault of the distros but
that doesn't mean that a distro should
never ship patches that aren't a part of
a tagged release as they say here we ask
respectfully to consult with developers
before shipping anything outside of a
tag release to the end users there are
absolute cases like back porting patches
to security and bugs and they say we
thank all distribution package
maintainers for backboarding patches
that improve security fix bugs Etc who
coordinate with Upstream oftentimes this
means creating or pulling patches to fix
issues with inactive abandoned or
unresponsive Upstream projects these
distribution package maintainers are
doing a tremendous job and their work is
not the subject of this letter so the
subject of this letter isn't patches
that are already well tested that don't
actually change the feature set of the
application they're fixing some exploit
that might be there they're fixing some
bug things like that this letter is
about pulling in patches that change
things that actually affect the user in
maybe not some negative way but affect
the user in some way that misaligns the
project with what the developers expect
to be there for the project but when a
distro does want to make these changes
make sure you consult the developers
consult the maintainers to make sure
they're aware of this change actually
occurring so if someone comes to them
with a bug report or a user support
request things like that and they say I
am using this version on this distro you
actually have an understanding of what
they are saying and why this might not
align with the regular tag release say
for example you're working on a new API
or making some major change to an
existing API let's say for example
you're working on global shortcuts with
Weyland doing that through xdg portals
right now the way it works is a work in
progress It's a draft it is very highly
subject to change the way it works now
there is no guarantee that a week from
now it's going to be the same a month
from now it's gonna be the same a year
from now it's going to be the same
nobody really knows exactly how it's
going to function but let's say it's in
a state where it does actually function
to some extent but it's still a draft
if these stories decided hey we just
like the way it works right now we are
going to start shipping this version and
then software starts getting built
around that being the way it functions
there is no guarantee that when the
stable version of the API comes out that
any of that existing software is even
going to remotely function and that's
basically what they don't want distros
causing now I mentioned individual use
at the start on your personal system you
are free to do whatever you want and if
you know what you're doing they actually
encourage you to go and do so if an end
user is informed and wants to test
patches without broadly Distributing
them to others that's fine with us we
certainly want to encourage end users
and distributions to test packages and
Report their findings this helps
developers find and fix bugs and
increases confidence of their work won't
cause issues for users now when they say
distributions to test patches what they
mean is the distribution maintains to
test them personally or or putting them
into places like your development repos
or your testing repos things like Debian
unstable for example not the place where
regular people are going to be using
that system if you're using the testing
repos then you should be someone who
understands the risks they are taking on
this also helps ensure information end
up in the right place so if you're
testing a patch that hasn't been merged
yet the Upstream merge request rather
than the distributions bug tracker forum
and or social media if a distribution
wished to ship unreleased or work in
progress patches we believe it should be
opt-in even better avoided entirely I
Believe by opt-in here they are
referring to things like your testing
repos and things like that the end user
must understand rather than being on The
Cutting Edge they are in Uncharted
Territory and should expect things to
break packaging unfinished work and
shipping it to users who have not
explicitly consented is unacceptable
acceptable I think one place that could
really improve this is with the Aur so
as someone who has read the arch Wiki I
know that something is marked as a dash
get package is usually going to be the
latest commit on the repo and usually
that's going to be ahead of the latest
tagged release but the Aur website at
least from my understanding from where
I've seen on it doesn't make it clear
what the different naming conventions in
the repo actually mean now the aui is
certainly a weird exception you probably
shouldn't be using it unless you know
what you're doing but when just talking
about regular package repos uninformed
users basically get the worst of it they
get what is potentially broken software
or software that just doesn't work in
the way the developers intended for it
to work and then devs who are basically
unwilling or unable to help with any
problems that you know you may come
across because that's not supposed to be
in that version we don't even know what
is being compiled into it it if you're a
distribution that ships developers
unreleased patches please reconsider
this decision shipping unreviewed
patches to your users is reckless it
unfairly exposes your users to potential
issues waste time and may give the
patches developer or active Upstream
project a bad reputation it discouraged
developers from working on new features
publicly something we care about a lot
in the free and open source software
Community it also frustrates developers
and in some cases caused developers to
stop supporting a distribution
altogether in this scenario the end user
gets the worst of Both Worlds a broken
distribution and developers who are
unwilling to help but if you think the
internship patch right away please reach
out there might be cases where a merge
Quest looks like it's fixing an issue
your users are seeing and you want to
get it shipped to them as soon as
possible if this is the case please
reach out to the developers to discuss
how you can help to ship it as soon as
possible to your users
right now this is still a fairly small
open letter I will leave it linked in
the description down below I highly
recommend you go and read it for
yourself and if you're a developer who
agrees with the cause that's going on
here and you want to put your name
behind it go ahead and do so I fully
encourage you to do that so let me know
if you're a developer and you have any
thoughts about this whether you know
distro should be shipping your
unreleased patches or they shouldn't be
what if you think about it I would love
to hear it and if you're not a developer
and you're just a regular user I'd love
to hear your thoughts about it as well
so if you like this video I'm going to
go and like the video If you really
liked the video and you want to become
one of these amazing people over here
check out my patreon subscriber Center
bear pay Linked In the description down
below I've got a podcast called Tech
over T I've got a gaming channel called
birdy Robinson plays that's gonna be it
for me and
I'm out
[Applause]
[Music]