FEATURE FREEZE PLANNED FOR 2024-11-20

[tlaurion]

This is follow-up conclusion from discussions having happened after my QubesOS mini-summit Heads rolling release : roles of upstream and downstream forks (Design Session)

• Takeaway is 30 seconds long at end of the recording, up to the end: https://youtu.be/mAb_kHrF6SQ?list=PLuISieMwVBpL5S7kPUHKenoFj_YJ8Y0_d&t=1848
• Priority review needed on everything labeled Release Cycle EDIT: Release cycle -2024-11-20 from downstream so that commit chosen for releases include upstream merged stuff.
• Everything unfixed at time of feature freeze should be labeled known issues in downstream release to be fixed in next release.
• Note that downstream plans 1 to 2 releases a year, so this is important to prioritize.

Date might be postponed, in which case title of this issue will change.

TODO from downstream:

• Prepare automated testing system for @tlaurion to access them as early as possible. (task: @macpijan? otherwise tag proper github aliases here)
• Downstream needs to raise issues upstream ASAP to have a chance to be addressed if not already (task: @nestire/@jans23 + @wessel-novacustom + @JonathonHall-Purism ? otherwise tag proper github aliases here from your support team issue dispatchers for most common issues)
• Other tasks? Comment and i'll add them here in OP.

[wessel-novacustom]

I will try the latest Heads upstream version tomorrow and provide feedback in tickets.

[wessel-novacustom]

I will try the latest Heads upstream version tomorrow and provide feedback in tickets.

I'm sorry for the delay. I have to postpone this for now, as we are now working on the videos for the current Dasharo coreboot+Heads release. I hope to find enough time to continue this on Saturday, otherwise the Saturday after.

20th of November sounds a bit early to me since there is probably also some time needed for realising improvements, if needed from our side of course.

[tlaurion]

I will try the latest Heads upstream version tomorrow and provide feedback in tickets.

I'm sorry for the delay. I have to postpone this for now, as we are now working on the videos for the current Dasharo coreboot+Heads release. I hope to find enough time to continue this on Saturday, otherwise the Saturday after.

20th of November sounds a bit early to me since there is probably also some time needed for realising improvements, if needed from our side of course.

@wessel-novacustom I didn't know you were spooling this this fast. There are still changes pending that changes the UX, so please sync with me prior of doing the videos. One example is #1541 (comment) which I cross-linked here exactly for video creation purposes. Once that PR is merged, oem-factory-reset/Re-ownership is not expected to change until feature freeze.

EDITED: link

[tlaurion]

20th of November sounds a bit early to me since there is probably also some time needed for realising improvements, if needed from our side of course.

This is date Dasharo picked for coreboot release. This is interesting experience.

@wessel-novacustom @macpijan @pietrushnic : this needs better synchronization.

Bugs still awaited to be opened on heads (upstream release) to work on issues. Then fixes need to be tested and then pooled to dasharo for downstream release.

This is why I said Heads is rolling release in my talk. If I have to wait for input from all parties, and videos are to be produced, this is forever chicken egg problem and hence why rolling release.

Let's say as of now that known issues upstream of today will be fixed first week of November as of now.

If this is the case, then videos should be spooled to be produced when Dasharo will pick Heads commit, but issues still awaited on Heads master as of today and planned feature freeze planed is in 20 days as of now. Time to redefine?

Sync needed off github people. Let's chat under matrix and come here with realistic date with now better understanding of realities of a release requiring a feature freeze without issues even opened yet nor upstream tested today from downstream, nor stated needed development for next downstreamrelease that is expected to happen only once a year.

[srgrint]

Not sure whether you want testing reports given the recent version bumps in the last week? In any case, I can confirm that heads-x220-maximized-v0.2.0-2410-g9d656fc works fine.

[srgrint]

Also works on my intel t430

[pietrushnic]

• Everything unfixed at time of feature freeze should be labeled known issues in downstream release to be fixed in next release.

@tlaurion I think there are better approaches than this. By "feature freeze," we mean limiting the addition of features and pace in which hash on top of which we integrate change. After that, we should not add any features. Bug fixes can be added. We could have rc, as we discussed during the Qubes OS Summit, which achieved a certain level of quality (criteria have to be decided). After we agree that we have achieved that point, new issues will have to land in the "known issues" section, and we have to live with that until the next release.

This is date Dasharo picked for coreboot release. This is interesting experience.

Could you let me know if you are sure? Please ping me where that was proposed because the conclusion of the only discussion about the dates I see is like that between you and @macpijan:

End November?

I'd say something like this

[tlaurion]

So end of November is the goal. Will post blockers and change label name accordingly and tag features and Bugfixes that happened between last release and feature freeze for reference on the 20th.

I agree with your definition of feature and bug. The thing is that sometimes things considered bugs are features, and some features, if untested properly, have bugs. Features not properly implemented also prevents other features, as can be seen in this feature freeze of merged things and issues created/fixed in the goal of feature freezing with feature requests depending on currently/recently fixed broken things/fix pending yet unreleased.

This is not just heads here. Heads depends on other moving parts, like security dongles, coreboot, ec, tpm implementations, software stacks, kernel, libraires, etc which also has their own new features and bugs.

Only thing that can be done is thorough testing from multiple angles, and maybe joint effort in unit testing which I'm looking for next when I'll have a chance, outside of this feature freeze with help of qemu targets when pflash and firmware update feasible within q35.

A reminder that up to this, Heads was and still is a rolling release, where new features are paused until the freeze, even though new requests were made to postpone feature freeze after freeze announced; while blockers preventing feature freeze not fixed(no or created yet) to be tested upstream and code adapted under Heads for feature freeze. See label.