We're updating the issue view to help you get more done. 

Defining a bugfix update process

Description

Often we have a need to issue a quick buf fix, update a single package or a kernel that is common to many boards. Since we can't afford to maintain last stable release very long, those fixes has to be issued from current master branch. Currently this is done by issuing a release with previous major version and a indrementing patch number. Also all those bug fix releases could potentially bring more bugs then solve. How to determine which upgrades are safe? We can rely on simple upgrade test on our automated testing facility, but nothing more than that.

Update procedure must be crystal clear that the one running it doesn’t need to think or deal with excepetions.

Also we provide kernel updates via armbian-config which could be broken - in some ways packages are pushed to cover up for those bugs, but we don’t remove broken version.

Clearly this is not the best way. What we can do about to improve this?

Activity

Show:
Werner
October 27, 2020, 8:51 AM

To reduce the chance for regressions we would need to fork the needed sources within the merge window and then work with these sources to provide updates for a current release. Bugfixes from upstream would need to be backported.

I think there is no need to think further her because the increase of effort nobody can compensate atm.

However what CAN easily be done is to not increment the major kernel version for example inside a release cycle. So for example if 20.08 sunxi is shipped with 5.8.x then keep it on 5.8 regardless if upstream support ends. This at least will reduce the chance to catch a regression.

Assignee

Unassigned

Reporter

Igor Pecovnik

Components

Labels

None

Fix versions

Priority

Medium
Configure