Currently, the repository that gets continuous releases is called ‘testing’. This creates an uncomfortable feeling among our users that this is meant for testing FreedomBox and is not meant for general consumption. I propose to rename this terminology to ‘Rolling’ everywhere. We should still keep (or make it more clear) the message that these rolling releases may occasionally break some features.
Tasks
Update freedombox.org (add/keep the message the rolling builds may break working things occasionally).
I have seen other software projects name testing as "rolling.’ I would be okay with it so long as we include adequate warning on freedombox.org about the occasional breakages with rolling.
Hm, I’m hesitant about this. Maybe just encouraging people to be pioneers about it would do the trick? Renaming to “rolling” seems to convey that you get only benefits, no downsides. But in the past, “testing” surely had more hickups than “stable”. I was actually hoping that with the upcoming release of Buster, more people should be fine with the more up-to-date “stable”, at least for a while.
Another problem I see is that would break the established Debian terminology. Admittedly, this is not a huge reason given that most users don’t know Debian, but I think it should be made clear that “rolling” and “testing” have absolutely identical meaning.
Finally, “rolling” seems harder to translate than “testing”, but that may be just me .
After the Pioneer edition release, while people were discussing FreedomBox, I saw two separate comments where people said that our project hasn’t made a release since 2017.
How did we make 40+ releases and people checking out the project didn’t see those calling our project stale? I believe that the term “testing” played a big role in this. People go to see the downloads, pick stable because ‘testing’ is not relevant for them and see that there is no progress in the project since the last two years.
‘Rolling’ concept is being used by other distributions. Many people have expressed frustration at Debian’s stable vs. testing usage and naming. People new to Debian first pick stable due to naming and later realize that what they really want is ‘testing’. We need not stick to Debian’s naming. We can document that our ‘rolling’ is built on Debian ‘testing’ for the sake anyone looking deeper.
After the release of buster, within a few months, people seeking new features or major updates will start looking at our testing distribution. In the past we have also felt uncomfortable recommending ‘stable’ to new users especially as we were getting closer to a newer stable release cycle.
We could try to adopt the translated term for ‘rolling’ from the Linux distributions that are using it. It is also not a bad thing to introduce a completely unfamiliar term and explain it rather use a term like ‘testing’ that will scare away people.
Testing is not what the average user should want. Naming it “rolling” just paints it in a hip colour but that does not give any benefits.
IIRC "Constantly Usable Testing ", something like a rolling release, never was more than a thought experiment and I think it just does not fit into the Debian universe.
We have put in significant effort in FreedomBox project to write functional tests that constantly check that packages needed for FreedomBox are in usable shape. This list of packages is much smaller set than Debian as a whole.
In the past, we have also worked on writing upgrade paths when an app changes in a major way.
There are areas we could identify and work on improve on top of this to make ‘rolling’ trouble free.
In terms of receiving continuous feedback and addressing it, we gained a lot by doing bi-weekly releases. It is hard to imagine making releases to all our end users only once every 2 years.
I do not feel very comfortable with this kind of renaming. Testing is testing, and there is a reason for it. If you think, this is scaring people away, maybe call it Buster and Bullseye, to stay with the debian naming convention. So, it would be clear what the release is based on.
Not a comment on the naming (though I’d say rolling=unstable more than testing), but I just want to caution against falling into the common upstream mentality of “oh, obviously the latest release is best - fixed a lot of bugs - I haven’t even used our LTS version for over a year, why doesn’t debian just package the latest point release?”. I am extremely glad you decided to pick the pure blend approach to work entirely inside debian (see also libravatar), though I gather that has some downsides for the Freedombox project e.g. NextCloud, Coquelicot.
I’m hoping I’ll be able to recommend e.g. the Pioneer Edition to family and friends as the easy home cloud solution with no need for linux sysadmin (it’s very, very close to that). Specifically, the privacy entry point in my social circle seems to be awareness that Google sync of phone calendar and contacts is bad, but the backup and convenience is essential - radicale on Freedombox with davx5 on android can be the solution, but only if it’s appliance style, where debian’s stable=unchanging is beneficial because if it works in 2019, it’ll keep working until 2021.
Personally, I will probably use stable+backports, but I was surprised to find that backports of the freedombox package itself are enabled by default in /etc/apt, rather than as a checkbox in the Update module. I think this is a bad idea, because you’ll start to assume that a user has a relatively up to date install as bugs are discovered #1508 is a minor non-breaking bug, rather than fixing them for stable users too #1457 blocks plinth & ssh after installing openvpn.
Most of us understand the appliance mind set and how stable release can cater to it. We put in lot of effort to get ready for stable so that Pioneer Kits could use stable. Some problems though:
We wanted to provide not only security fixes but also important fixes for stable users. Unfortunately, backports has a restriction that whatever version is available in testing must go into backports. That didn’t allow us to release 19.2.x with only important fixes to users. We really didn’t want to add a repository outside of Debian infrastructure.
FreedomBox has come a long way since its beginning. However, we think it is still in active development and many of its features are yet to come. In the previous stable cycle the project changed very drastically. Perhaps we will do a better job for the next stable cycle.
We tried to fix this and other important bugs for stable users. There was a problem with release scheduling https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924523 Now we are not sure if there is any way to get those changes without backports.
From what I have seen, testing is less likely to break nowadays, due to autopkgtest failure results (including for reverse dependencies) blocking migration from unstable to testing. We could further improve this situation by adding more autopkgtests for the packages that FreedomBox relies on.
.
Now we are not sure if there is any way to get those changes without backports.