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 <j...@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
Eric
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
