22.01 ETA still holding up?

A Former User

@stephenw10 said in 22.01 ETA still holding up?:

encontramos y solucionamos que causaron retrasos.

how I can help?

keyser

@silence said in 22.01 ETA still holding up?:

@keyser, mmmm your point seems interesting could you be so kind as to share a little more details about your configuration? schematics etc...what is the purpose?

?? The configurations are fairly simple, but the devices still seems to touch the disk/ssd enough, that quite often a power outage will leave the FS openended and corrupted.

ZFS uses an intirely different strategy for writing to disk. It always allocates free sectors to write/overwrite data, and then completes a write by updating filesystemtable/pointers in the current datainstance - the old data and pointers are still there - not touched -, but they now belong to the latest snapshot.
Once flushed, the filesystem is consistent. If a flush is not made, no changes that leaves existing filesystem corrupt has been made. So hopefully that will help keeping the ARM devices from boot looping because of inconsistensies in the filesystem.
I understand specific files can still be logically corrupt, but that’s easier to survive - especially because ZFS also has the previous snapshot to read from.

A Former User

@keyser Oh okay ! I also wait for the next version but I don't have any problems at the moment.

keyser

@stephenw10 said in 22.01 ETA still holding up?:

I wish I could tell you 100% when it will be released but until it passes testing I cannot.

I can say you would have been far more disappointed had it been released with any of the issues we found and fixed that have caused delays.

Internally it is looking good right now.

Steve

Hi Steve.

It’s not a disagreement because I don’t want releases with known bugs either. Software quality is paramount.

I’m just not happy with Netgate settings public schedules and release names that they are not remotely close to maintain. If you set them, you need to inform and update the customerbase well ahead of any kind of delays - and include a new ETA to the best of the current knowledge.
If you are so tightlipped with ANY guessing on release date now, how can you guesstimate the planned release schedule and planned release names?

Either keep us informed whenever deadlines starts to be threatned, and then keep us in the loop during the delay.
Otherwise announce a FULL stop to the planned release schedule/kill the monthly build name indicator, and go back to it’s ready when its ready.
You are setting expectations with the current strategy that netgate cannot cash in. The current strategy can only create dissapointment (There is no possible win).

Anyhow :-) I’ll wait patiently for a few weeks more until it is presumably ready.

netblues

redmine has only 23 open issues, all of them in feedback status.
2.6 rc hasn't changed 2.6.0.r.20220124.1828 for the last two weeks.
So its close. Very
And since we all love it, next Monday(2/14) is the most probable date.

herozero

@netblues it’s been at 26 open for weeks. Commits in GitHub as recent as 1/31. Don’t use redmine as a gauge for release, you’ll be disappointed.

netblues

@herozero I know, I'm aware of the rate.
Still it Is very close to be released.
I'd bet this month. Finger's crossed.

(on the other hand rc has been quite stable too.
No, I wont put rc anywhere critical or without easy supervision. But then I wont be putting 2.6 telease anywhere until at least two weeks have elapsed and the forum isn't on fire too)

Patch

@keyser said in 22.01 ETA still holding up?:

I’m just not happy with Netgate settings public schedules

You do realise the only option to Netgate to fix this problem is tell you less.
I'm not sure how that really helps you but each to their own

herozero

@patch what utter drivel.

johnpoz

@steveits said in 22.01 ETA still holding up?:

consider labeling the releases "22.Next"

Looks like maybe they liked that idea... I just noticed this on the pcscd redmine.

https://redmine.pfsense.org/issues/12095

Where is the announcement of that? I see nothing here, or on twitter? Communication is key..

or is that talking about after 2.7 and after 22.09 which what might be in the roadmap?

stephenw10

In that particular case I'm pretty sure I chose that because the 22.01 tag didn't exist yet when I opened it. However it may also have been changed to that because after applying the patch to prevent it running by default it became low priority to fix the actual leak. It's probably an upstream fix required there anyway.
Those labels have existed for some time though and do not imply a move away from the current release naming. That label in redmine means this should be fixed but does not need to be for a specific target release.

Steve

johnpoz

@stephenw10 isn't that what the future tag is for? I do recall seeing beofre target of just future.

jimp

@johnpoz said in 22.01 ETA still holding up?:

@stephenw10 isn't that what the future tag is for? I do recall seeing beofre target of just future.

The -next tag is for items that are potential candidates for the immediate next release. Rather than keep kicking the same set of issues forward over and over this gives us a pool of near-term goals to draw from without committing to a specific release. The Future value is for more long-term items or items that are unlikely to be completed by internal developers, but are waiting on community contributions.

johnpoz

@jimp thanks for the info, that makes sense.

SteveITS

My post yesterday was intended as tongue-in-cheek. Microsoft ran into this same discussion with Windows 10, after switching from three feature updates a year to two, then changing the labeling from "1909" to "20H2" because people kept expecting releases in March and September, per the numbers. It seems the misunderstanding here was that the ".01" release would definitely be out in January, not "when it's ready."

Changing versioning to "21Q1" may not work with internal version numbering. I don't know if "21.1" for the first release of the year then "21.2" and "21.3" would still fit the stated goal of dating the release but might be a compromise. If one is even needed...setting the "when it's ready" expectation a bit better would be another method.

I do understand the point of view where people may have been waiting for the new version to ship routers, and sympathize.