Release goals for 22.XX

Rich Brown richb.hanover at
Wed Oct 6 05:38:21 PDT 2021

> On Oct 6, 2021, at 1:58 AM, Rafał Miłecki <zajec5 at> wrote:
> On 30.09.2021 03:34, Rich Brown wrote:
>> My desire would be to name our next release "22.03", with a target release date in March 2022. And we should name the following release "22.09" with a release date in.... September. And so on - every six months (or whatever interval we believe we can sustain for the long term.)
> This is absolutely undoable. We have too little manpower and too little
> people actually interested in preparing releases. It takes testing,
> checking feedback, reviewing bug reports, debugging issues, backporting
> changes. That is a lot of work.
> Every time we have a discussion about releases there comes an idea of
> time-based releases. Also a lot of people have opinions on when to
> branch and how to proceed with development.
> When it comes to actually working on a release there are very people
> that stay involved.

I am so pleased that you are pushing back against my suggestion, especially since you are actually *doing* the work. (I have not, and probably will never contribute any code to OpenWrt. But I've been writing software for 40 years, and have watched a lot of projects struggle with their goals.)

I advocate for regular releases because:

- It keeps the project fresh. We look like a "living project" and attract new users and new developers
- Our users get new features in stable versions on a regular basis
- It gives our users confidence in us
- It makes us proud to ship software

BUT... you point out the very real problem - limited available time for people who can actually do the work.

This leads me to think about how we can preserve our most precious resources - time and attention. Some questions:

1) What would prevent us from accomplishing the 22.XX Release Goals in March 2022? ( 

- How do we see the time between now and March playing out?
- Are there things we should leave out? Or should the release date be shifted?

2) How important is it to update kernels regularly? In the abstract, I know there's a balance between backporting critical bug fixes and important features to the current (older) kernel vs the effort to move (and test) our entire code base to a new kernel.

- But what real-world implications does this have for OpenWrt? 
- What's the balance (in time/effort) between those two activities?
- How do we balance the *value* of new kernel features vs what we could create if we spent the time on other projects?

3) Architecture support. There's a certain amount of pride that "OpenWrt runs just about everywhere". (I agree - this is an astonishing accomplishment.) But... now the attention from skilled developers is scarce.

- Does support of this broad variety of architectures add to the developer effort? 
- Should we ever drop architectures from support?
- How would we decided to do this?
- Can we make a "guesstimate" of how much time we'd save if we drop architectures?

4) How quickly should we embrace new devices? In the forum, and to a certain extent on openwrt-devel, I see notes like "Hey, I just found this sexy device quad-core device with 128M Flash and 512M RAM. And it's only US$17! Can you make OpenWrt run on it?"

- Does a task like this take any effort from "core developers"?
- Does a task like this increase our testing effort?
- Does a task like this create an on-going maintenance/support obligation?
- If so, do we need a process to decide whether to take on a new device?

5) I am fully aware that OpenWrt is driven by volunteers. We contribute because a particular piece of the puzzle seems interesting or fun. We can't "force" anyone to do anything.

- How can we construct OpenWrt goals (kernel, packages, releases, documentation, build system, all of it...) to match projects that excite our group?
- What would it mean to attract new people to "fill in the gaps" of our project.

I don't imagine that we'll come with answers to all these on the mailing list. Perhaps Hauke will add them to the next online meeting. Thanks for listening.


More information about the openwrt-devel mailing list