ch-ch-ch-changes

If all goes well with our FTP mirrors (I'm still waiting to find out) we should have ourselves a 1.7 Alpha release on Monday.

I've finished up with the re-design of the What's New in Mozilla 1.7 Alpha page and I think it looks decent in winOpera and winIE, although the margins are a little funky in Opera. I also tested on Safari, which looks fine, and Konqueror which does OK except for chopping off the tops of some of the "legend" tabs. This page does get a lot of eyeballs each release and serves as a basis for much of the press coverage so I wanted it to look a bit sharper and to work in as many browsers as possible. Overall, I think it's good enough.

If you're using a browser I didn't test and you're seeing problems, feel free to let me know here in the comments or via e-mail. Comments are especially welcome if they come with a patch :-) Thanks to Bob Clary and Arno for the help.

Also, I've finished with the "rough changelog", a listing of bugs that were probably fixed during the 1.7 Alpha cycle. I say probably because it's not much more than a few smart Bonsai and Bugzilla queries and I haven't verified that each of those bugs was actually fixed during this release cycle.

A few people have asked me how I put that list together so here's the basic process I use:

I query Bonsai for all the changes between the 1.7a trunk opening and the 1.7a release tag. Using Jesse's wonderful "collect buglinks" bookmarklet, I convert the Bonsai list into a Bugzilla buglist. This list is pretty noisy and actually includes quite a few fixes that were present in the 1.6 release so the next step is to ask Bonsai for all of the changes that found their way onto the 1.6 branch, convert that into a buglist and subtracted it from the 1.7a Bonsai buglist. It's still pretty noisy so I take that list and sort on last changed date and cut a few bogus bugs at the top of the list that were just Bonsai linkification silliness (any number in a checkin comment gets converted into a Bugzilla bug link by Bonsai). I then run the list through Bugzilla a second time and trim out bugs where the resolution wasn't changed to fixed between the start and end dates of the 1.7a cycle and then further limit results to bugs which were still in the fixed state.

This gives me a pretty lean list but it usually misses quite a few bugs, sometimes as much as 20%. Commonly missed are bugs where the checkin comment didn't specify a bug number or there was a typo in the comment, bugs where a patch was checked in but the bug wasn't actually resolved (some bugs are held open for further changes,) and bugs which were fixed as the result of a checkin for a different bug. Because of these shortcomings in the Bonsai list, I also come at it from the Bugzilla side.

Now, a simple query for SeaMonkey bugs where the resolution changed to fixed sometime during the development cycle is really pretty noisy and so I do a few things to try to decrease that noise. The first thing I do is to query for the subset of bugs fixed during the cycle which have a patch attached with review flags. Then I make another pass on the list limiting it to bugs where at least one comment was made by someone who had checkin (Bonsai) activity during the development cycle. This helps to eliminate a lot of the bugs where a newbie bug reporter resolved his own bug as Fixed even though there wasn't a documented fix (or any developer activity, for that matter) in that bug. Finally, I subtract from this Bugzilla-generated list all of the bugs found in the Bonsai-generated list and do a quick glance at the summaries to see if any stick out as obviously bogus.

I combine the two lists, reformat a bit and post.

I'm sure I still miss a handful of bugs and I certainly include a few that didn't really get fixed during the cycle but I estimate between 90% and 95% goodness and I don't have the time to read through every bug on the list (about 870 this alpha cycle,) so without help it's not going to get a lot more accurate than this. Still, I think it's useful and if you're interested in what changed during the development cycle, it's probably the best place to start.

If any of you have suggestions about how to improve the list that won't cost me a lot of time -- or even better, that will save me some time, then feel free to let me know in the comments or via e-mail. Actually reviewing the list would be a good first step and if you've got time to help with that, I'll be glad to remove any you find that shouldn't be there. Thanks to timeless for his help clearing out a few bogus bugs over the weekend. Equally important, though, would be finding ways to get overlooked bugs onto the list. There may be some Bugzilla queries that could catch a few I'm missing, but the wider the net you cast, the noisier it gets, and the more time you have to spend weeding out the bogus bugs.

Well, there you have it, "What's New" and the "rough changelog" are done.

Posted by asa at February 22, 2004 11:48 PM