kea-dhcp6 crashes
-
I mean soon is a relative term.
(but it really should be, new bugs aside) -
Well, the Redmine roadmap page changed. It's no longer showing 24.08 release. It seems something really is happening
https://redmine.pfsense.org/projects/pfsense-plus/roadmap
-
@juanzelli said in kea-dhcp6 crashes:
https://redmine.pfsense.org/projects/pfsense-plus/roadmap
Ah yes. Well, by looking at the open bugs (which are the same as they were in the 24.8 release) obviously the 24.08 has been merged into 24.11 which is due in ~20 days from now
So an rc version can be expected really soon, followed by the official 24.11 within November. -
Like I said above, we’ll see.
24.08 was being tested back in frickin May, and now its not even being released and now its 24.11.
Heck, this could get pushed and become 25.03.
Until I see a release, I’m not holding my breath. I dont know why you would just completely drop a release and roll it into another release.
Just release something, and then work on the next one.
-
Well releasing something broken would be the worst thing we could do IMO!
By new image I mean a new public snapshot for testing.
-
@behemyth said in kea-dhcp6 crashes:
Until I see a release, I’m not holding my breath. I dont know why you would just completely drop a release and roll it into another release.
Just release something, and then work on the next one.
Releases don't really mean a lot, especially when they are not bound to a specific feature set.
So as long as the product is secure, and released features work as expected, date bound releases aren't that critical.
I could say that working towards a 3 or 4 per year releases as a target is nice, but setting dates becomes unrealistic, especially when new great features come into the pipeline (in this case, cloud management of multiple devices).Perhaps naming the release as "next", and renaming it into the month it is finally released is better.
-
@stephenw10 said in kea-dhcp6 crashes:
Well releasing something broken would be the worst thing we could do IMO!
I'm not saying release broken images, that is bad.
We were told there would be 4 releases a year, this (if it happens) will only be the second.
-
3 a year is the target but when the changes are as significant as they are for this release it can take longer.
-
@behemyth said in kea-dhcp6 crashes:
We were told there would be 4 releases a year, this (if it happens) wi
And why is this important ? Keeping infrastructure at current version isn't exactly easy.
Two releases is already a lot for production.Firewalls are not meant to be rebooted or migrated often, since they are cornerstone to many other things.
-
@netblues said in kea-dhcp6 crashes:
And why is this important ? Keeping infrastructure at current version isn't exactly easy.
Two releases is already a lot for production.Firewalls are not meant to be rebooted or migrated often, since they are cornerstone to many other things.
This is not true. My team and I reboot hundreds of firewalls in my corporate environment monthly, sometimes weekly depending on vulnerabilities that are found.
I'm also sure I am not alone in this aspect. Firewalls are just another piece of network gear, and should be treated as such. They just serve a different role than a router/switch.
If your following good design, and building out HA, rebooting production equipment doesn't matter.
-
@behemyth said in kea-dhcp6 crashes:
sometimes weekly depending on vulnerabilities that are found.
Yes, of course. But vulnerabilities in pfsense are addressed as patches and NOT versions.
Testing out a patch is rather trivial.
Testing a new version with new functionality is another. And quite often, its not the bug, its the feature than makes things go flaky.No one professional enough, is running mission critical workloads without HA, BUT HA must also be tested.
Changing major versions sometimes incur new things, for example single cast for carp instead if multicast.
What I'm saying is that patching is something that a network team does and just needs small maintenance windows for that.
Changing versions and introducing new functionality is another story.So, again, why 4 (or) 3 versions per year is important for you?
