Suggestion to make a 2.3.3 release

NOYB

Ditto that for sure.

NOYB

We don't default to cherry picking them all the time unless it's requested. If a separate PR is submitted against RELENG_2_3_2 it's more likely to be included. It isn't always immediately clear if a bug applies to all branches. I usually check on the things I fix myself, but for PRs it's a bit of an extra burden to expect us to check all of the branches to see if it applies.

Here is a case where no checking if applies was required. It was spelled out.

Even when there is a referenced bug report with both the target and affected versions set it still doesn't happen. Seem like that is a reasonable form of request for it to be back ported.
Delete NAT rule with associated firewall rule does not update firewall separators position
https://github.com/pfsense/pfsense/pull/3089
https://redmine.pfsense.org/issues/6676

Plus additional reference if it were needed.
https://forum.pfsense.org/index.php?topic=116099.0

If it not clear. Simple ask or at least let the submitter know. There simply isn't enough communication to the active community. We are and have been for quite some time been left in a black hole.

jimp

Fair point, but it does go both ways. A gentle reminder that it needs cherry picking would likely lead to it being pulled in a majority of the time.

MaxPF

So jimp, can you confirm that there will be a 2.3.3 and it will include all those the fixes and "enhancements" back-ported to RELENG_2_3 that did not make it in 2.3.2_1 then?

jimp

I don't think we've officially decided either way. There are snapshots, so it's likely, but it depends on how quickly 2.4 progresses.

jahonix

@jimp:

… it's likely, but it depends on how quickly 2.4 progresses.

Please remember that a bunch of users would be cut off the things discussed above with 2.4 being 64 bit only.
Having that on the last 32 bit release will help some, don't you think?

jimp

@jahonix:

@jimp:

… it's likely, but it depends on how quickly 2.4 progresses.

Please remember that a bunch of users would be cut off the things discussed above with 2.4 being 64 bit only.
Having that on the last 32 bit release will help some, don't you think?

We'll keep doing errata releases as needed for security updates and such (and to pull in more of the referenced bug fixes from this thread and beyond), it's just not clear if we'll need another full release. Depends on what comes up.

NOYB

@jimp:

We'll keep doing errata releases as needed for security updates and such (and to pull in more of the referenced bug fixes from this thread and beyond), it's just not clear if we'll need another full release. Depends on what comes up.

What will trigger a 2.3.3 release? If we knew maybe we could help it along. ;)

jimp

@NOYB:

What will trigger a 2.3.3 release? If we knew maybe we could help it along. ;)

Now that we have the ability to do errata style releases it's a much tougher question. Probably something that would require a rebuild of the installer images in the extreme case, or when there have been enough changes to warrant a new installer. Maybe a significant change that would need more long-term testing in snapshots. Or a significant enough security issue that we wouldn't want new installations to be vulnerable without an update.

With the errata releases and pkg we can update binaries, kernels, etc, in between without much fuss. It's a lot better system than we had in the past.

JorgeOliveira

@jimp:

With the errata releases and pkg we can update binaries, kernels, etc, in between without much fuss. It's a lot better system than we had in the past.

I'd still vote for having one steady release (or patch-level rebuild) every 2 months with ISO/memstick made available for download and installing on clean systems.

Updating clean installs on non-patch-level build takes considerable time when updated packages is high. Having a regular flow of releases would be helpful.

So far I am relying on the snapshots, while researching on what's incorrect when things don't happen as expected and submitting bug reports/fixes afterwards on those.

NOYB

@jimp:

Fair point, but it does go both ways. A gentle reminder that it needs cherry picking would likely lead to it being pulled in a majority of the time.

It may be a two way street, but the traffic is going in only one direction.