Known issues & workaround section

[notspam]

Dear community,

is it possible to summarize the known issues and their workarounds dynamically in the release notes as a separate section ?
Yes there is a bug tracking in github.
But it is not really comfortable to give an easy full view.

This might be
- a better transparency for the user
- a good tracking overview.

F.ex.:

- issue 54321: "mtu change" / workaround 12345 / link to the thread

What are your opinions to this ?

[wuwzy]

It's a good suggestion, but this problem will not exist forever, and it will be meaningless after it is fixed.
It is a basic rule not to use a large update version in the production environment first. Give the developers time to solve it.
Drink less coffee and sleep more.

[epimpin]

It's a good suggestion, but this problem will not exist forever, and it will be meaningless after it is fixed.
It is a basic rule not to use a large update version in the production environment first. Give the developers time to solve it. As a seasoned vet in software development and network engineering yotalling 34 years, I smugly disagree with you.
Drink less coffee and sleep more.

[notspam]

Thank you very much for all views.

You should keep in mind that central, comprehensible quality management, knowing what doesn't work and how to fix it using a workaround, is an important level for software quality. The software user immediately collects all information in one place.

This has nothing to do with whether you use the first final release version in production. Even in stage testing, you want to see at a glance what's not working and how or whether you can fix it.
And by the way, the update to 24.10.12_4 shows in the webinterface the message that the 24.10 branch is being replaced by 25.1 and 24.10 could be outdated soon. This means that you should look into whether you can switch to 25.1.

My post was intended to be a suggestion as  how the release notes could be improved. If you look at the major world market leaders, you will see that bug tracking is written transparently in the release notes (known issues).
 
I need more coffee if I don't know very well what's wrong and how to fix it :-).

Every supposed report gets a running number in the bug tracking (like in github) and the links to fixes or discussions are noted.
This would be much easier than searching through the entries in the forum manually or search in github.
But in github there are totally 243 entries. There are posts with no comment except the thread owner, there are feature requests, configuration issues ans so on.
And there is a form of redundancy concerning issues in github and discussion here in our forum. So the idea is to better list at one place the known issues per release.
It is not my intend to make unneccessary work. I thinks this might be a better transparency concerning software issues and their handling.

I would like to promote it again.
Thanks all for your input and discussion about.

[meyergru]

What you are asking for is a non-open-source approach to things.

There is an important difference between OS projects to commercial products: OS tries to catch bugs and fix them quickly in the next release. It does not turn back and deals with people who are not using the "latest and greatest". Sometimes, this is a problem, because OS developers tend to change (and break) things, like backwards-compatible APIs, for better or worse, because they go with the flow and adopt new technologies or methodologies. There basically are never two forks for feature-development and security-updates-only.

That leaves users at a problematic decision: Use the latest and greatest revision, which fixes the newest security bugs? Or carry on with an out-of-date, but proven working revision, but knowing there are unfixed bugs, including, sometimes, security vulnerabilities.

Call this the "Linux" way.

When working with larger companies, like Microsoft, you have a variety of supported releases, like Windows 10 (still), Windows 11, Windows Server 20XX, all in different variants (e.g. 23H2) of which are supported with at least security updates (and sometimes bug fixes). Keeping that zoo at bay takes thousands of people and obviously, comes at a price.

Call this the "Windows" way.

As you correctly pointed out yourself, on Github and in the forums, there are tons of "bug" reports, some of which are user (or "me") problems, some are feature requests and some are real bugs. To even sort them into correct categories would be a huge effort, not only on the development side, but also for documentation. We know that, and we even have a tutorial section here in the forum to teach people things that are most often misunderstood - BTW: should the documentation really cover such topics?

So, basically, what you are asking of Deciso is: "Double or quadruple your efforts, like Microsoft does."

What you would end up is a commercial product you probably do not want to pay for. On the other hand, you can choose for better support and a more proven, stable product from Deciso with most of the glitches ironed out. It is called OpnSense Business Edition.

If you instead call for the free version, you can become part of a community that takes a journey, but also takes a risk and in turn, gives Deciso insights on what works and what does not in return. That is why they provide OpnSense for free in the first place.

Choose your poison: you cannot have your cake and eat it.

[franco]

My two cents here: the bug tracker IS the way to go for bugs and known issues and workarounds. Offering information in release notes will clutter them much more than necessary.

The time it takes to qualify bug reports (a sizeable chunk of reports are support requests worded as a bug) is the bulk time to be spent. Fixing after the fact is easy and fast as you can see from most bug reports even the ones involving kernel issues.

I don't think creating a "backlog" of issues with workarounds is going to help. People already do ask over Bluesky, Reddit and the forum without much regard for the bug tracker (or duplicated posts elsewhere).


Cheers,
Franco