Project Update: Bugs, bugs, betas and breakages

So much for a monthly update with hints and tips. Been a year and more! So I guess this post should start again by covering what has been going on over this past year. “Not much and far too much” just about covers it …

 

Bugs …

Business as usual has seen a steady parade of upgrades from earlier versions up to 3.0 and 3.1. Bringing with it a steady stream of bug reports for all sorts of varied things overlooked or not yet fixed. The increasing number of reports people are giving of old bugs that have annoyed them without being reported is pleasing in a way. I hope this means less overall and display stuff is relatively easy

Some people have had shocks; bugs reported over a year ago being fixed suddenly and some new reports not lasting the day. I can’t stress enough how important your help in researching the problems is.

The oldest bugs are simple “Squid is doing X”. Um, yeah well, we can assume what the expected behaviour was (sometimes). After prodding (a day or so later) up comes a version number and build options.

For example; I was looking at a typical old bug today. Still open from 2007 that never got any further than build options and behaviour description despite several requests for more info.  One day somebody is going to have to setup several machines build 3.0 a couple of times with multiple features on or off and try to replicate the described problem.  Then build 3.HEAD and try to replicate X all over again starting with the same tests. Then try to figure out how its happening and whether a fix might be possible.  Well, thanks for the report anyway, at least we know to watch for it meanwhile.

Every few months like today, I trawl through these, just over 100 bugs now, looking for ones which I could maybe replicate in less than a few days. Today I’m slightly happy. One died as invalid, and two died as no longer fixable. The whole area of code they might have been in is dead.

 

… bugs …

The shorted lived bugs by comparison, are reports that version a.b.c. is doing X when it should be doing Y. They include in the case of crashes and segmentation faults a backtrace of the code (with symbol names). They include header or packet traces if the problem was communicating to some other software. Some even came with information tracking down which feature and piece of the code was going wrong. Found, tracked, patched, tested, and fixed in the main code in mere hours of work.  A HUGE thank you to everyone who reports bugs like this.

 

… betas …

Squid-3.2 has started its beta releases this year. Following the fluffy “grand plan” of being a bit more predictable:  branch in Jun with monthly betas through until a stable series probably appears Dec or Jan.

The fluffy part is caused by some more structural cleanup projects we really really want to make the code easier to work with. Well, late Oct and about half of the cleanups have been done. The stable part is today looking more like next Jan/Feb provided the rest are done and working soon.

Another post closer to 3.2 stable release will cover whats going on there in the features. Some cool stuff. If you want a sneak preview the release notes are already available.

 

… and breakages.

Ah, well. Some may recall 3.1.5.1 and friends. The background there for the inquisitive is that two feature changes clashed head-on and killed stability for two months.

I have irregular but available contact with nine of the maintainers packaging Squid for popular systems. It started slowly, growing until half of them had informed me that important sections of their users were being hit by the lack of IPv6 split-stack support in 3.1.

It surprised me a bit how many people and what in situations are insisting that IPv6 be turned off, but only partially. This was a big problem for early 3.1 series since the build process actively probed IPv6 capabilities and turned various capabilities on or off inside Squid. So an essentially simple change was made, moving the active testing into Squid startup process. Squid builds with IPv6 anywhere and runs it when available. No such luck on simple, enter all the little quiet bits assuming IPv4-only or IPv6-only sockets.

The other feature change that made the recovery even messier was a version bump to libtool in our package bundling system. In short a very simple basic upgrade omission on our part broke the tarball package. A veritable storm of hacks appeared to work around the broken tarballs and extended the fix time as testers disappeared with “it works for me now” leaving the systemic problem unresolved.

3.1.8 finally got some pedantic methodical testing before release and a fix for both problems.

 

Background to all this drama we have had an increase in focus on HTTP/1.1 support over the year from The Measurement Factory. Many of the minor behaviour bug fixes made it into the 3.1 series and the last of the big changes being held back to 3.2.