On 06.09.19 12:44, Bjørn Mork wrote: > Jo-Philipp Wich <j...@mein.io> writes: > >>> Buildbot is already crunching the images and packages, and pretty much >>> all targets are green. So there are no obvious build related issues >>> preventing the release. I have also not noticed any franctic discussion >>> about specific major bugs blocking the release, so it looks pretty good >>> at the moment. >> >> there are various LuCI bugs which need to be addressed first. > > Is there a list of release blocking bugs anywhere? I guess we are more > than a few who would be interested in looking at unknown code, if we > knew fixing it was critical for a release.
I assume OpenWrt's policy is similar to the Linux kernel, but as far as I know it's undocumented. From my perspective mostly critical bugs in the bug tracker. > It would also be nice to know the release policy. I.e., what makes a > bug critical enough to block the release? When a default feature or important platform breaks. > When is a buggy > feature/platform/whatever dropped from the release instead of waiting > for a fix? When nobody is working on it or it takes too long. > I believe Debian has had great success with explicit release > goals and absolute time limits. Encourage people to fix blocking issues and mark them as blocking/critical. Setting an absolute time limit is not a good idea for a FOSS project as it does not increase pressure on anyone like in a working situation and should be a last resort only. I think Debian is not the best example... At some point they lost many of their developers to Ubuntu (maybe because they were used to be treated as employees ;-D) > Documenting workarounds is also an option, especially for optional > features in release candidates. This will likely frustrate users and is a last resort only. Documenting issues is also work. Better try to fix it first. > I can understand that major LuCI > breakage still is considered unacceptable, but I can't really imagine > that there are that lots of such bugs? > > And documenting known issues in a release candidate will attract even > more attention to bug fixing for the final release. It's a win-win. That's a good idea for non-critical issues. > > > Bjørn > It seems there really needs to be a clear, documented way of OpenWrt handling releases. One blocking issue I know of is the migration from ar71xx to ath79. It's unclear whether to only release ar71xx (which lacks devices added in the last year) or both. Another thing is the change of the sysupgrade metadata format. Personally I think OpenWrt is near a releasable state. Vincent _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
