On 9/3/22 23:53, Chris Morley wrote:
I see the action with Debian package.
I hope that gets us some more exposure and more develops/users.
Me too!
I did wonder what that means for the project as far as maintaining versions.
How are bug fixes addressed with Debian packages after (Debian) release?
Each debian package is built from a specific commit in our repo. So far
we've been using the tip of the master branch, but once we make the 2.9
(or 3.0 or whatever) release branch we'll package from there, and
ideally package our official releases.
There are two options for making a bug fix in a released debian package:
1. If there's a newer commit in our repo that fixes the reported bug
(ideally but not necessarily a newer release in our stable release
branch), we have the option to just make a new debian package from that
newer release or commit.
2. We also have the option of treating the packaged buggy commit as a
branch point for a bug-fix branch, fixing the bug in that branch, and
releasing that as a new package. We'd then "merge up" to get the bug
fix commits into our appropriate "real" branches. This technique is
often used to fix bugs in the packaging itself (as opposed to bugs in
the linuxcnc software), but it can also be used to patch bugs in the
software.
Will Debian users be directed to the forum or github for issues?
Not automatically via any debian tooling; any pointers to our forum,
irc, github, etc will have to come from our documentation, e.g.:
<http://linuxcnc.org/docs/devel/html/getting-started/about-linuxcnc.html#sec:getting-help>
<http://linuxcnc.org/community/>
Will it end up we have a current buildbot released version, current Debian
version and master version?
There are currently four ways to get pre-built debs of linuxcnc:
1. debian.org
2. buildbot
3. www.linuxcnc.org
4. github "artifacts"
# debian.org
<https://packages.debian.org/linuxcnc-uspace>
The debian.org debs are the most user-accessible, in the sense that a
user doesn't have to know anything about linuxcnc.org and doesn't have
to edit their `/etc/apt/sources.list`, they can just `apt-get install
linuxcnc-uspace`. This has a couple of downsides, from LinuxCNC's
perspective, as I see it:
* debian.org only packages for newer debian distros, currently
unstable/sid/13 and testing/bookworm/12. There is a possibility of
using "debian backports" to get linuxcnc into stable/bullseye/11, but
(as i understand it) nothing older than that is possible within the
debian.org framework. We'd have to roll our own to support e.g.
buster/10. (The LinuxCNC project has historically tried really hard to
support old distros, on the theory that machine builders don't want to
upgrade. For example, 2.8 runs on Ubuntu 12.04, which is 10 years old.
This tendency of ours is both good and bad...)
* In the debian.org package archive, each distro is (pretty much)
limited to one LinuxCNC deb: we cannot publish debs from multiple
different LinuxCNC branches within a specific distro. (There are ways
around this, but they're not used much.)
# Buildbot
<http://buildbot.linuxcnc.org/>
The buildbot debs are how we've been distributing our debs so far. Some
things to consider:
* We can easily publish debs for all our different branches, for
whatever distros we choose to support.
* We have full control over the build environments, so we can support
platforms that debian.org doesn't support, such as RTAI.
* Selfishly, it takes effort on my part to maintain the build farm, and
i'm having a hard time finding time/energy for it. For example, there
is a bunch of work needed before the buildbot can support newer distros
(bullseye and later).
# www.linuxcnc.org
<http://www.linuxcnc.org/dists/>
This is/was the "official" way to get linuxcnc debs, for folks who
didn't want the bleeding edge of buildbot debs. These debs come from
the buildbot, and share all the pros and cons of buildbot debs.
# Github artifacts
<https://github.com/LinuxCNC/linuxcnc/actions/runs/2988288333#artifacts>
The github artifacts exist, but they're not super convenient in their
current form... Maybe this could be made better, but I haven't looked
into it very much.
# Version Numbers
One important thing we need to talk about here is the version numbers
used for debian packages.
The version numbers of the linuxcnc software are fully under our
control, and ultimately come from release tags in our git repo such as
"2.8.3" or "2.9.0~pre0".
However, because of an abundance of caution back in the way-back-when,
our debian packages have historically carried an "epoch" number; that
is, our debs have versions like "1:2.8.3", not "2.8.3".
<https://www.debian.org/doc/debian-policy/ch-controlfields.html#version>
This scheme was rejected by debian.org, and the epoch was deleted from
the version numbers of the official debian.org packages.
I'm not sure how to deal with this. We should probably follow suit,
delete the epoch number from "our" debs, remove all debs-with-epochs
from our package archive, and somehow teach our users the recipe for
downgrading from debs-with-epochs to debs-without-epochs.
But this is a slightly tangential issue & discussion, and I don't want
to derail Chris's thread too much.
Will having Debian force us on a time schedule?
What happens if we are not on time?
No, debian does not force a release schedule on us. Debian releases and
LinuxCNC releases are fundamentally decoupled.
There is some advantage to having a relatively up-to-date stable release
of LinuxCNC ready "shortly" (a few months?) before a Debian release, so
that we can all feel excited to maintain the version that made it into
the debian release. But this is an optimization, it's not a hard
requirement.
If we don't have a LinuxCNC release ready when Debian freezes for its
release, we have two options:
1. Package whatever is in the master branch at that time (like we
currently do with our 2.9~pre debs), and update the packages when we
make the final release (at any point in the life cycle of that debian
release).
2. Package the current stable branch, whatever that is at the time.
This does strongly encourage us to maintain that stable branch until the
debian release reaches its end-of-life.
--
Sebastian Kuzminsky
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
