[OpenWrt-Devel] Kernel version for OpenWrt 20.X

[Petr Štetiar]

Hauke Mehrtens <hauke at hauke-m.de> [2019-11-28 00:42:53]:

Hi,

> planned to do the next release in January 2020 which is soon. This 20.x
> release is planned to use kernel 4.19 only.

that's my understanding as well.

> Based on these numbers it could be already hard to get everything to
> 4.19 till beginning of January, at least we should start switching the
> default to kernel 4.19 for every target very soon to get the needed testing.

Is the project somehow obliged to get everything to the next kernel? I'm
afraid, that you'll write the same in a few months, just replacing 4.19 with
5.4. The targets people care about would be converted, the rest would be in
the similar state like 4.19 is today.

> I would suggest to leave kernel 4.19 out and directly go to kernel 5.4.

Like make a release without 4.19? This doesn't seem right to me. Why should
anyone care about 5.4 if it might be skipped as well?

> Then we would target April for the release and hopefully get it in
> Summer. ;-) 

To me it seems, that we should probably discuss releases, again :-) From
Hamburg:

 * future releases now every 6 months, at least a RC

So after 19.07 that's 20.01, right?

Ok, it was decission made by a certain group of people attending that meeting,
but I didn't registered any negative feedback about this topic.

I think, that with 6 month release cycle we shouldn't delay release just
because it's missing feature Y (important to certain circles) or having
unfixed bug Z (important to other circles).  The only show stopper should be a
security issue.

Perhaps 6 months is too ambitious release cadence, considering the resources
on hand and higher release quality bar? On the other hand 12 months release
cycle makes backports painful. So maybe something in between, 9 months would
work better?

> Should I start a vote on this topic?

I think, that it would make more sense to make a releasing process clear, make
it predictable. So perhaps rather start voting about that? So we could came to
some conclusion, release rules? That way we don't need to argue about this
anymore, it would be set in the stone, unless changed by another voting in the
future if we find out, that it doesn't work well.

So this is my view for the start:

 * new release is branched automatically, 1st day of month, Y months after the
   previous release
 * release.0-rc1 images are being built immediately, automatically
 * release.0-rc2 images + 14 days since branch, automatically
 * release.0-rc3 images + 30 days since branch, automatically
 * final release.0 images + 45 days since branch, automatically
 * point release every 45 days, automatically
 * point release immediately in case of serious issues like bricked
   device, security fixes etc.

 + claim official support only for one previous release, any other option
   would need some kind of funding in order to have dedicated resources for that
   level of support, otherwise we steal this resources from other parts of the
   project (one of still unresolved topics from Hamburg)

Yes, I prefer predictability even if that would mean, that release.0 has some
rough edges for certain circles. I mean, I'm not able to use kernel 5.4 on my
laptop as trackpad doesnt work, it's noticeably slower then 5.3.13, but I'm
fine with that, because I expect it with every fresh release.0. It's
impossible to please everyone :-)

-- ynezz

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel