On 1/18/22 2:51 AM, Amos Jeffries wrote: > On 8/01/22 05:02, Alex Rousskov wrote: >> On 1/7/22 9:34 AM, Amos Jeffries wrote: >>> Others include altering the fundamental AsyncJob API behaviour - >>> affecting every feature in Squid at their most fundamental levels. >> I disagree with the above summary. > This is not an opinion. It is impossible to tell for sure whether this is an opinion or a fact because the summary is using undefined terms like "every feature" and "most fundamental levels". To you, it may sound like a fact. To me, it sounds like gross exaggeration at best: Clearly, there are Squid features (for some reasonable definition of a "feature") unaffected by this change at "most fundamental levels" (for some reasonable definition of "most fundamental levels"). > The patch "part 2" makes logic changes to > AsyncJob - specifically destructors and swanSong. That touches > *everything* Squid does. The other parts touch I/O in similarly deep > ways and we have a history of unexpected weird side effects with I/O > refactorings. I do not think squid-users is the right place to debate complex development issues. I will just note that the commit in question does not, IMO, change AsyncJob methods in fundamental ways. It only shrinks the long-known gray area of what those functions should (not) do. Before this change, we did not know where certain actions should take place. Now, we (think we) do, and we have adjusted a few places to follow those newly discovered rules. Will this complex change have unexpected side effects? Yes, of course! I have disclosed that risk when posting the changes. No need to grossly exaggerate to agree on that point -- nobody is arguing against it. > I am seriously considering using our exceptional beta release process > for these changes once v5.4 bug fixes are out. FWIW, I see no need for a special process here. We have no reasons to believe that the change is making Squid v5 worse overall. All those who tested the change in v5 and master reported significant improvement in Squid stability. Moreover, since the last numbered v5 release was unstable (for many reasons), the bar for the next numbered v5 release is pretty low: We are not going from very stable to possibly unstable; we are going from very unstable to possibly less unstable. Said that, I am not trying to block the "exceptional beta release process" you want to use. I am just providing feedback. Most v5 actions are your call as a v5 maintainer, including special v5.x.y snapshots that have three numbers instead of the usual two. > IMO the best code to base your backport PR on would be the v5 HEAD after > 1st Feb when I post the "prep for 5.4" or similar QA for review. To avoid misunderstanding, when you have a commit SHA that the backport should be based on, please let me know that SHA, and I will start backporting from that point. That commit/SHA does not have to be in the official branch, of course. > That gives us 6 weeks for validation before v5.5 release decisions are > made. I seriously *hope* that is enough testing not to be hit later with > another one of these. FWIW, all other factors being equal, I doubt you would see more "beta" v5 testers than you would see without any special "beta" releases. If anything, the opposite is probably true. That is one of the several reasons I do not recommend using special procedures for releasing this important bug fix in v5. Again, this is your call. HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
