Jeff describes how the whole MSBuild team locked themselves into a room for a week in order to fix bugs. This process is known as Hackathon (not part of the Jargon?) in the open source world and Jeff lists the most important ingredients of it: laptops and pizza.
From what he describes they've been quite successful, getting their bug count from 437 down to 264. As a comparison, there are currently 241 bugs and 444 enhancement requests logged against Ant, but we probably could do away with half of them (if not more) if we'd use WONTFIX more seriously/realistically.
Jeff's entry also sheds some light on how the team works, even more so than the blog of some students participating in a program called "Explore Microsoft".
could testers and program managers even fix bugs?
I hope his question was rhetorical. How about testers doing pair programming with developers to write unit tests? The whole separation of non-coding testers and developers is a very traditional picture that I wouldn't expect at Microsoft. I somehow expected them to be more "agile".
we don't yet know how many new bugs we introduced, or how the regression rate compares to the usual scenario when only developers are working on the codebase
You don't have an automated testsuite that would catch your regressions?
It looks as if they enjoyed their week, as if the testers (Jeff is one of them) got closer to the code and all of them learned a lot. If they keep discovering best practices that way, unit tests and continuous integration should be their next stops.
path: /en/dotNet/msbuild | #
In his blog entry about OSCON, Rob Mensching talks about his WiX presentation:
I finished up my presentation by noting that the entire demo had been done with the WiX toolset running on Mono. The look of amusement on everyone's face in the room was priceless. I'll provide more instructions how to build the WiX toolset to run on Mono in a future blog entry.
I'm really looking forward to this since this will help me to work on the WiX task for Ant that I've started to experiment with.
On a related note, I managed to make Ant's <ilasm> and <wsdl> tasks work on Mono (both using my Linux desktop and my iBook running MacOS X) - at least all unit tests we have pass.
path: /en/dotNet/wix | #
Leo writes about the different projects that try to build upon Ant and in particular on top of Ant's import task.
In a parentheses he suggests that there was a flamefest going on between Ant and MSBuild and points to my blog. I've already commented in his blog, but since people follow his link looking for some action, I must disappoint you, there is no flaming.
In internet time, MSBuild is old news. There has been quite a lot of bad blood on some of the very first published statements by Microsoft that compared MSBuild to (N)Ant, in particular the initial revision of Brent Rector's "Introducing Longhorn for Developers", but this has been rectified later by the people responsible for MSBuild.
I for one am very interested in MSBuild since it takes a few different angles to building stuff than Ant. While being rather similar at the surface, there are some philosophical differences between the two (three, we shouldn't forget NAnt here).
The items in MSBuild still interest me a lot and I've not given up the idea to get something similar along with pipes into Ant (1.7/8/9, who knows). Of course, I still believe that Ant's approach to dependencies is superior to MSBuild's file timestamp based mechanism.
path: /en/dotNet/msbuild | #
It seems that Alex Kipman, the MSBuild Program Manager, will start a blog.
Just trying to help John to increase the "peer pressure". ;-)
Alex subscribed to the developer lists for both Ant and NAnt when Microsoft announced MSBuild last year. He's done a lot to calm the situation by answering questions as well as correcting some statements made about Ant and NAnt by Microsoft Press.
I'm looking forward to read more from him.
path: /en/dotNet/msbuild | #
Jeff Callahan, a tester in Microsoft's MSBuild team, has started a blog. Welcome Jeff.
path: /en/dotNet/msbuild | #