Release goals for 22.XX

[Rich Brown]

> On Oct 6, 2021, at 1:58 AM, Rafał Miłecki <zajec5 at gmail.com> 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? (https://openwrt.org/docs/guide-developer/releases/goals/22.xx) 

- 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.

Rich