[OpenWrt-Devel] OpenWrt 20.X release plans

Sun Jan 19 12:17:10 EST 2020

On 1/16/20 11:05 AM, Petr Štetiar wrote:
> Hauke Mehrtens <hauke at hauke-m.de> [2020-01-16 00:00:33]:
> 
> Hi,
Hi,

Sorry for answering so late, was busy with other stuff.

>> My preferred timeline would the the following:
>> * Beginning of February: freeze master for big changes (adding new
>> boards is no problem)
>> * Beginning of March: branch off 20.3 release branch
>> * 1 week after the branch was created: tag and build 20.3-rc1
>> * 3 weeks later tag and build 20.3-rc2
>> * 3 weeks later tag and build 20.3 final
> 
> Amazing!
> 
> Is this fixed or relaxed timeline? :-) I mean, are those steps going to happen
> as they're defined or they can slip by some days/weeks/months?

This is just my proposal and I would see the dates relaxed, it also
depends if people have time to do it and so on. We can also do two weeks
between the RCs and do one more like you suggested a month ago.

The week between the branch and the RC1 is just to setup the build bots
for the branch.

Someone has to take care of the release and this person would then
announce that he wants to tag and build the next RC some days before so
that people can prepare. The person can change in the release process.

Does someone else other than jow know how to setup built bot for a new
branch? Is this documented somewhere?

> Looking at the recent past, and I think, that we should learn from that
> experience, it would be nice to define who/what can delay this proposed
> timeline, release blockers so to speak. 
> 
> Thinking about it, just this two points came to my mind:
> 
>  - unfixed security issues we're aware of
>  - unfixed bug which could lead to:
> 
>    * bricked device
>    * preventing access to the device over SSH or LuCI
> 
>    Those issues needs to be properly reported at respective bug tracking
>    system and confirmed/reproducible by at least one more person.
> 
> From my point of view anything else shouldn't delay .0 release, as the other
> issues could be fixed in subsequent .1 even a week later if needed to be.
> 
> Any delay in this timeline should be properly communicated to the development
> mailing list at the time we discover such release blocker.

From my point of view the delays were not caused by someone saying that
we should wait till something is fixed, but that nobody did the next
step and nothing happened.

If there is something important which should be fixed in the RC or final
release this should be mentioned on the mailing list if we do not have a
fix yet.

I would also only list the big problems you listed as real showstoppers,
but it would be nice if more people also get informed about the other
bugs too.

> BTW it's still master + 2 stable releases which will receive the support? Once
> the 20.y is out, the 18.06 is EOL?

I think this is not really clarified yet. I assume that 15.05 and 17.01
are now officially fully end of life. I do not know when we put 18.06
into this mode, but it will definitely get less patches after 19.07 is
out, because people care now less.

I added some support status to this wiki page:
https://openwrt.org/docs/guide-developer/security#support_status
I hope this is ok, I put some minimum dates there and they should be
extended if we think we will support something longer. I am fine with
changes.

I think the latest release branch is better support than the previous
one, how do we paraphrase this? Name it extended support like some
companies do it?

>> I am fine with kernel 4.19 or 5.4, but we should decide and not stay in
>> a limbo for log, so we can work io the right direction.
> 
> There is going to be a vote about this topic soon, probably tomorrow, see
> bellow.
> 
>> It would be nice to have jails activated by default, but there are still
>> problems when using an initramfs, I will probably not have the time to
>> investigate into this problem in the next 4 weeks.
> 
> I would like to have jails as well, but it should be probably first enabled in
> master for some time. Is this[1] the issue you're having?

Yes this is the issue I am talking about.

>> Should wpad-openssl or better wpad-wolfssl (after it works with WPA3) be
>> added as default wpad version now? If we do this we can also activate
>> https support for luci by default https support should not cost much
>> space when we already have an ssl library.
> 
> I agree.
> 
> Is there anything we can do in LuCI UI to make the errors caused by
> self-signed certs in the browsers less stressful? Perhaps adding one more step
> (until there's password set or just for the first time) while redirecting from
> 80 to 443, some kind of special page, where we could entertain the user about
> the next possible browser certificate error (show the certificate
> details/fingerprint for additional verification) ?
> 
> Simply something which could improve the UX. I know, it's very hard.

I am not aware of anything.

>> Are there any other bigger changes planned you would like to get into
>> the next release?
> 
> Sysupgrade image signature validation enabled by default.

Someone told me that we often changed the signature key in the past is
this true?

>> Should we do a vote on the kernel version and release plan in the end?
> 
> We've somehow agreed about the kernel voting on IRC. If we can formalize the
> release plan/rules/timeline soon, lets add it to the next combined vote as
> well (it doesn't matter if it's 4in1 or 5in1 voting, we're saving time), so
> far it looks like:
> 
>  - 4.19 Vs 5.4 for next release (Jow is preparing the text)
>  - new project logo/colors (ynezz)
>  - openwrt-announce mailing list (ynezz if needed be)
>  - GitHub Vs self-hosted GitLab Vs whatever else (ynezz if needed be)
>  - release timeline/rules definition (Hauke/Baptiste?)
> 
> Does anyone else see any other topic which should be included in this combined
> vote? If so, let us know ASAP and ideally prepare the text/voting options as
> well.

I would prefer if we make separate votes at least for the topics which
are separate, you can start them at the same time, but I think it is
easier to have separate discussions.

> 1. https://patchwork.ozlabs.org/patch/1179527/

Hauke

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200119/b101baaa/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel