[OpenWrt-Devel] OpenWrt 19.03 plans

Eric Luehrsen ericluehrsen at gmail.com
Wed Apr 10 00:00:18 EDT 2019

On 4/9/19 7:53 AM, Vincent Wiemann wrote:
> Hi Bjørn,
> routers are critical infrastructure. We should try to achieve the best we can.
> One of the reasons for the Lede split was that problems were procrastinated
> and accumulated over the release timeline.
> That's the reason why we should release less often, but with a higher quality.
> If problems delay a release that is a sign of taking responsibility.
> Some time ago a friend of mine told me that they have a problem with tickets that
> nobody wants to take care of. I told him when those tickets appear he
> should automatically assign them to all people with highest priority after a due
> date even if it is a minor issue. Productivity has increased rapidly since then.
> If a device is not supported in a specific release, that might give someone the
> stimulus to sit down and get this device working again.
> E.g. many devices have a partition layout on which a bigger kernel does not fit.
> It is possible to change the partition layout in most cases requiring a modification
> of the U-Boot boot environment variable. So hard it sounds unfortunately someone
> needs to be urged to do it. It's the same with porting ar71xx to ath79...
> When we stop generating ar71xx images some device owners wonder why there is no
> new release for it. They become aware that they need to sort of add support for
> this device as if it was a new device support and they might do it.
> Urging is a bad word, but we need to motivate people to do changes which are not
> of the fun kind or we might end up in a mess again.
> Regards,
> Vincent Wiemann
> On 09.04.2019 11:02, Bjørn Mork wrote:
>> Jo-Philipp Wich <jo at mein.io> writes:
>>>> Is there any kind of "official" roadmap/checklist available what "needs"
>>>> to be done?
>>> not that I am aware of, but from the top of my head:
>>> - make sure all targets are ported properly to 4.14
>>> - disable all devices which cannot cannot handle the increased kernel
>>>    size anymore
>>> - drop all targets which are not ported to 4.14
>>> - fix important open issues in the tracker
>> Apologies if this is out of line...  I just fealt the urge to post my
>> personal opinion, FWIW.
>> It seems to me that you are setting way too high standards for
>> yourselves.  From my point of view, the OpenWrt master branch is almost
>> always in a releasable state. The OpenWrt development and review process
>> ensures an extremely high quality, even for targets which are considered
>> WiP. There are very few days over the last 6 months where you could not
>> have decided to cut a release branch, and got away with it.  It's
>> something to be proud of! But you need to tell the rest of the world
>> that you are proud of this by making releases.
>> You should accept that the targets which are ported properly to 4.14
>> defines "all targets" for the next release.  It's not the other way
>> round.  Any remaining targets which can be expected to be ported to 4.14
>> or later, if any, can and should be deferred for a later release.  Note
>> that accepting this means that there could be a "next release" in 2019
>> too...
>> You should also accept that there will be unfixed important open issues
>> at all times.  You can't fix them all.  To make a release, these issues
>> will either have to be
>>   - ignored for that release,
>>   - demoted to less important. or
>>   - removed by removing the feature/target/whatever is affected by the
>>     issue from the release
>> Look at the Debian "release critical" bug handling.  It's not really
>> about fixing all the RC bugs, but dealing with them.
>> I realize that actually making a release is real work too, and that this
>> has to take some time after making the initial cut.  But delaying the
>> cut for the master branch to get in an even "more ready" state is not
>> really helping...
>> Just my .021 € (considering inflation)
>> Bjørn

Hi Bjorn,

I agree with you on this one. New OpenWrt adopted a different working model
from LEDE. That is staging trees and more careful testing before actual
master commits. Long ago are the days when someone thought they were
special, commit without review, and just blow up the nightly builds.
OpenWrt should release regularly and it should be an editing (cutting)
event. Target not on envisioned kernel, cut. Package not core and sketchy,
cut. What's left is pretty good. With a variety of targets and volunteer
support team bugs will happen. You can test to high confidence, but in
such situations nothing is 100%. Instead, you just need to be prepared
to deal with them in a timely matter.

Just my $0.018649 exchanged at 20190410 04:00

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list