Suggestion to make a 2.3.3 release
-
At least some good news. 2.3.2_1 shows 97% complete all of a sudden.
https://redmine.pfsense.org/projects/pfsense/roadmap
-
It would be great if correct iface names would display in new traffic graph widgets. I hope it makes it to this release…
-
At least some good news. 2.3.2_1 shows 97% complete all of a sudden.
https://redmine.pfsense.org/projects/pfsense/roadmap
Most of the bugs were fixed but needed closed, and a few needed moved. We'll be doing 2.3.2_1 this week, assuming everything goes well.
-
At least some good news. 2.3.2_1 shows 97% complete all of a sudden.
https://redmine.pfsense.org/projects/pfsense/roadmap
Most of the bugs were fixed but needed closed, and a few needed moved. We'll be doing 2.3.2_1 this week, assuming everything goes well.
I think there are quite a few "new" things that were backported to RELENG_2_3 but not RELENG_2_3_2. (I will check that…) It would be nice to get the code in RELENG_2_3 released.
-
I think there are quite a few "new" things that were backported to RELENG_2_3 but not RELENG_2_3_2. (I will check that…) It would be nice to get the code in RELENG_2_3 released.
Ditto.
-
Depending on what they are, they'll probably have to wait at this point. We'd like to get it out ASAP and can't bring in a bunch of things that would need extra testing.
-
Depending on what they are, they'll probably have to wait at this point. We'd like to get it out ASAP and can't bring in a bunch of things that would need extra testing.
When did this testing religion take hold? Thought it was all guinea pig. ;)
-
The recent copyright text changes are in RELENG_2_3 but not in RELENG_2_3_2.
And things like "Save widget settings per user", "Backport Add missing recommended key lengths/digest to Cert system"…Anyone using the 2.3.3-DEVELOPMENT snapshots has been using the code from RELENG_2_3. It seems a shame not to release it.
I attached the output of:
git diff RELENG_2_3_2..RELENG_2_3But there is a lot of noise in that because of the 100's of files that have the copyright diff.
-
The keys, perhaps, could be for security but not the widget settings, that's a feature. The _x releases are intended to be strictly security and significant bugs. Those changes make sense in 2.3.3 but not 2.3.2_x.
-
The keys, perhaps, could be for security but not the widget settings, that's a feature. The _x releases are intended to be strictly security and significant bugs. Those changes make sense in 2.3.3 but not 2.3.2_x.
Yes, I agree. I am just suggesting to release 2.3.3 (rather than bothering with 2.3.2_1)
-
That would require a significantly larger amount of testing which would delay a release further. Better to get a quick security release out without the extra hoopla of a full release with new installers and whatnot.
-
The keys, perhaps, could be for security but not the widget settings, that's a feature. The _x releases are intended to be strictly security and significant bugs. Those changes make sense in 2.3.3 but not 2.3.2_x.
Yes, I agree. I am just suggesting to release 2.3.3 (rather than bothering with 2.3.2_1)
For what it's worth, irrespective of whatever it gets called, it would be great if this release would include the "DHCP6c before RA" fix, assuming it's been back-ported. I and others have been using it for quite a while and it's been solid. (I was using the "2.3.3" snapshot since early August, but switched to the 2.4 shapshot a couple of weeks ago.)
-
The keys, perhaps, could be for security but not the widget settings, that's a feature. The _x releases are intended to be strictly security and significant bugs. Those changes make sense in 2.3.3 but not 2.3.2_x.
Yes, I agree. I am just suggesting to release 2.3.3 (rather than bothering with 2.3.2_1)
For what it's worth, irrespective of whatever it gets called, it would be great if this release would include the "DHCP6c before RA" fix, assuming it's been back-ported. I and others have been using it for quite a while and it's been solid. (I was using the "2.3.3" snapshot since early August, but switched to the 2.4 shapshot a couple of weeks ago.)
Indeed, that is in RELENG_2_3 but not in RELENG_2_3_2
-
The keys, perhaps, could be for security but not the widget settings, that's a feature. The _x releases are intended to be strictly security and significant bugs. Those changes make sense in 2.3.3 but not 2.3.2_x.
So much for _x releases being "intended to be strictly security and significant bugs."
Show system platform and serial / UUID
https://github.com/pfsense/pfsense/commit/27663052c2b5e199a96f4f5ea766abafa8f1ec08#diff-7f8270168d6aa91bbc90278269ffba9bMake serial/UUID bold
https://github.com/pfsense/pfsense/commit/27663052c2b5e199a96f4f5ea766abafa8f1ec08#diff-7f8270168d6aa91bbc90278269ffba9bAren't double standards great. Apply/enforce them when they suit, ignore them when they don't.
-
That was a bug in our internal tracker. That serial number readout was in the factory images but not the CE images, it was intended to be in both, and the code is well-tested.
-
That is so shallow. Those same kinds of justifications can be applied to other "bug" commits too.
Please note, the criteria is supposed to be STRICTLY SECURITY and SIGNIFICANT bug fixes. That is neither a security nor significant bug.
-
more what you'd call "guidelines" than actual rules
-
more what you'd call "guidelines" than actual rules
All the more reason many of these other fixes are just as valid to be included. Some of them even more so because they actually have functionality fixes/corrections. Not just WebGUI window dressing.
-
We have to draw a line somewhere, or 2.3.2_1 would practically be 2.3.3, which would be a lot more work. We need to get it built, tested, and out for security reasons which means being conservative in what we pull in. The ones that made the cut, made it. The rest can wait for 2.3.3 or maybe 2.3.2_2. The _1 release was built today, and is already being tested.
Could we have included more? Sure, but the time to advocate for that was much sooner than the day of/day before a release is to be built. If they were significant enough they should have been sent as PRs against RELENG_2_3_2 a while ago.
-
We did advocate for them much sooner. That's why we submitted the PR's. Why where they not include in 2_3_2 when they where merged? They should have been there was no significant reason for them not to be.
