We earlier covered the appeals by Brazil, and by Venezuela and India.

South Africa's conclusion gives us a fine overview of its point of view:

In conclusion, South Africa challenges the validity of a final vote that we contend was based upon inadequate information resulting from a poorly conducted BRM. Moreover, we challenge the validity of a process that, from beginning to end, required all parties involved to analyze far too much information in far too little time, involved a BRM that did not remotely provide enough time to perform the appointed purpose of that procedure, and for which an arbitrary time limitation was imposed to discuss and resolve a significant number of substantial responses, despite the Directives not requiring any such limitation as to duration.

South Africa also believes that the process from beginning to end "has harmed the reputations of both ISO and the IEC" which in turn has also harmed the reputations of all member bodies. That is the saddest part, to me. ISO always had a fine reputation, and it has so many excellent people involved in standards work who have toiled for years tirelessly and competently. But it's a new day.

There's a SCO status report [PDF] in SCO v. Autozone also, as per the judge's recently order. No fireworks there, but maybe it's in comparison it seems so staid and dull.

The one detail that stands out is a foreshadowing of what SCO's appeal in SCO v. Novell is likely to be about. They stress the decision by Utah to hold a bench trial instead of letting SCO have its day in court before a jury of their peers.

Should there be any such.

Linus Torvalds released the 2.6.26 kernel on July 13 - somewhat later than most people had expected. At a full three months, this development cycle took longer than some others; that is especially surprising given that the number of patches merged and new features added is somewhat less than we have seen in recent development cycles. Still, at over 10,000 changesets, this is not a small release.

As always, I recommend that people wanting to know all about what’s in this release head on over to the KernelNewbies 2.6.26 page.

The new feature list for this kernel is huge. But there is a lot of good stuff there. One of my favorites is the incorporation of the kgdb debugger for the x86 architecture. Linus has been resisting the addition of an interactive debugger almost since the very beginning; he believes that such tools lead developers to focus on symptoms rather than understanding the underlying problem. But one of the things that makes Linus who he is is that he can, with effort, be convinced to change his mind. And so the developers who have long patched in kgdb from outside have finally gotten their point across: development tools help to make a better tool. Don’t expect Linus to use kgdb anytime soon, but he has at least let it into his kernel.

Now attention turns to the 2.6.27 development cycle; Linus has already started merging patches for this release. One of the more interesting things to watch will be whether the merge window process goes more smoothly this time around. 2.6.27 will be the first kernel cycle for which the linux-next tree was in full operation, so, in theory, much of the integration work has already been done. If linux-next has done its job, this merge window should come together with relatively little pain. See this article and this one for more information on the evolving role of linux-next.

And stay tuned: I’ll be back in about two weeks with a summary of what will be in the 2.6.27 kernel.

India, like Brazil, is bothered by not having the final text within a month, as per the JTC 1 directives, particularly when so many changes were voted on at the BRM. How can a national body know whether or not to appeal without a final text to analyze? So it asked that the window to appeal be extended, so that it had the opportunity to examine the final text. Venezuela challenges the entire process and says it undermines ISO's reputation. It raises the issue of a bad precedent being set, whereby large companies can exercise undue political pressure on a decision about a standard, instead of letting technical people work through and solve all the technical problems, which is what ISO normally has a history of doing quite well, from all I've heard:

The result of DIS 29500 has harmed the reputations of both ISO and the IEC, as well as all they member bodies, and has generated a terrible precedent in which the interest of large multi-national organization, both in favor or against an specific proposal, may dominate the debate instead of the technical discussions necessary to produce the optimal solution on every specific problem.

That really gets to the heart of the problem, in my book. So this was a first, as far as Venezuela is concerned, and one that it worries will start a new trend. It provides a list of comments on technical problems it raised, or tried to, that it feels were not appropriately handled at the BRM.