OpenWrt Forum Archive

Topic: Are trunk builds safe to use?

The content of this topic has been archived on 19 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

As there have been reports about trunk builds to brick devices, I'd like to know whether those builds pass a minimal "brick test" or are simply "dumb builds".
Since 12.09-beta is out (and working for me), I've seen 2 new trunk builds and would like to test them, without bricking my WDR-4300.
TIA.

(Last edited by uqbar on 26 Sep 2012, 14:38)

Trunk snapshots are completely untested, unattended builds. No quality guarantees of any kind.

...but still usually quite stable and usable.

I have been compiling my own version 2-3 times per week the last 2 years, and during that time I have bricked the router only 3 times.

If you look into the timeline of the last 2-3 days and see no major changes regarding your platform and there are no new bugs related to bricking, most likely the current trunk snapshot builds are ok. But like Jow says, there are no guarantees.
https://dev.openwrt.org/timeline

(Last edited by hnyman on 26 Sep 2012, 17:54)

Well, I'm not expecting any *special* guarantee, for sure.
After all this is a so-called "after market" firmware: not even the stock firmware has any guarantee!

But I find not less than puzzling those cases where a simple flash will lead to a completely bricked unit.
A missing driver or package from a trunk build is something I can expect and is something that won't lead to a brick.
But a completely bricked device sounds like some trivial quality check in the development process is missing. That sounds like a Russian roulette!
This is my possibly wrong opinion and I'd like suggest to have a warning in the trunk downloads!

If the missing driver happens to be the ethernet driver, the unit will be "bricked" as well. Even a simple unrelated change in the image Makefile can brick a whole range of models - or stuff like ethernet driver register changes that work on most but a few specific hardware revs. We don't even have a physical sample of each device we support, it is impossible to test anything.

Your comment about quality checking in the development process is wishful thinking, we don't have the resources to regression test each trivial change on the full range of supported platforms. And yes, most bricking commits where trivial changes, not something big like a kernel update.

If you're unable to recover your device from a bad flash then don't use trunk snapshots. If you maintain production setups then get a local testbed and stop deploying untested images.

So please keep your possibly wrong opinion or actually try to maintain a few dozen models over the course of a few months before doing such statements. From a bystanders perspective everything seems obvious and simple, especially if looking at stuff after it has been fixed.

If I had the skills to solder a JTAG or a serial console to my boxes, then I'd like to volunteer as a tester, to push this project quality further.
But unluckily I have not any.
So far I've run the trunk builds (for WR1043 and WR2543) to test them and to help in the debugging process as much as possible.
As a software developer I do know that a (buggy) compiler option can make the difference between a working program and disaster.
Nonetheless I don't expect my software to become a disaster after a compiler/library upgrade.
And as a software developer I am unluckily not prepared to cope with a bricked unit. That's it.
Anyway, I need to thank you all for your efforts in this projects.

The discussion might have continued from here.