Beta firmware update via DTS

[wessel-novacustom]

The problem you're addressing (if any)

Currently, releases are rather slow and sometimes, critical issues that can only be found in practice are discovered after releasing, like the fan spinning up issue. We should offer a beta firmware update option that flashes a release candidate binary, so that customers can help with debugging. However, downloading the correct files and getting them in DTS is hard.

Describe the solution you'd like

Beta test firmware update option in DTS. This should flash the latest binary that wasn't extensively tested by Dasharo.

Where is the value to a user, and who might that user be?

1: More issues reported before final release.
2: More testing in practice.
3: More engagement from the community, meaning more feedback in general.

Describe alternatives you've considered

No response

Additional context

Users should be informed that applying an RC binary might be risky and that debricking could be possibly necessary at some point.

Applying the beta test firmware update should be blocked when the platform is fused.

We have very engaged customers, let's take advantage of that.

[DaniilKl]

Makes sense. Right now it might be complicated, but when we fully migrate to proper metadata handling in DTS (DTS v2.8.0) it will be simple enough, because there will no DTS releases be needed to change the firmware version supported, just a commit to the repository with metadata (e.g. just change the version here). Thank you for the issue, I will push the idea further.

[wessel-novacustom]

Replying @pietrushnic 's comment from #1581:

@macpijan @BeataZdunczyk I think we should have better tests in scope for laptops, temperature should also be a thing.

@wessel-novacustom, also let's think about testing group rollout, so we do not ship to all users at once, but we have some group of people who are willing to get things earlier, even if they do not commit to test and recover, but try and report a bug like that one. So three strategies:

* Beta Testers - willing to recover

* Release Testing Group - willing to report and issue, but it cannot be fatal, like in the case of the Beta Testing Group

* Production - all customers

This may be indirectly connected with: Dasharo/docs#1154 Dasharo/docs#1144 (comment)

---

This means that the binaries that are used for Release Testing Group would need additional effort for basic testing.

Let's be honest: how often does it really happen that a device needs to be un-bricked? Is it worth it to cover those scenarios? Can't we instead warn the user that there is a higher chance of a brick?

[pietrushnic]

This means that the binaries that are used for Release Testing Group would need additional effort for basic testing.

My idea was to send release binaries, but to not hit all the audience at once, we would like to give 2 weeks of daily driving to this group, so some problems like battery draining or performance drop in some scenarios would be caught.

Let's be honest: how often does it really happen that a device needs to be un-bricked? Is it worth it to cover those scenarios? Can't we instead warn the user that there is a higher chance of a brick?

For the Release Testing Group, there should be close to zero chance of bricking. We can also redefine the beta testing group. It really depends on who we have. Maybe when someone is buying from you, they could have an opt-in checkbox "I want to belong to ... group"

[wessel-novacustom]

I think three types of groups is too complicated and not really necessary. Instead, Release Testing Group and Production only would be fine for NovaCustom.

I see it like this:

Dasharo has new release candidate -->
Team decides if it is good enough for Release Testing Group.

• Yes? --> Newsletter notification + easy applicable instructions
• No? --> Do not publish the RC to the RTG, nor send a notification.

Release Testing Group should be aware of the fact that the binaries are not extensively tested. In return, they get access to exiting new features and they help themselves as well as other Dasharo users at the same time.

In practice, making binaries available for RTG would happen after 3/4/5 release candidates. Something to decide.

Is this OK for you? @pietrushnic

If so, yes: we will make an option for signing up for the RTG while ordering. And we will pin a relevant thread in our forum.

Once we agree, let's make this happen.

[pietrushnic]

Is this OK for you? @pietrushnic

Whatever would work for you, I'm ok with.

[wessel-novacustom]

Is this OK for you? @pietrushnic

Whatever would work for you, I'm ok with.

Great. So let's do it like my plan, @macpijan @BeataZdunczyk :

Please set up a way to release binaries for the Release Testing Group (RTG). These have separate newsletters. They get firmware update notifications just like normal releases, but then also for RTG releases. You decide when a RC binary is OK enough for RTG. It doesn't need extensive testing, since the people who join this programme know about the 'dangers'.