Subject: Bowing out, and thanks - msg#00001

List: windows.dotnet.ccnet.devel

Date: Prev Next Index Thread: Prev Next Index

Hi CCNet community,

After nearly 4 years I've decided to 'officially' step away from my
role as one of the project leads for CruiseControl.NET . CCNet is a
big project now, with a big community, and I don't want to impede it
by my lack of ability to contribute these days.

It's been a great 4 years though, and for that I thank all of you. I
know Owen wouldn't mind me saying this - the project wouldn't have had
close to the success it has had without the support and contributions
from the larger community. Even with shrink-wrapped CI offerings from
the likes of great companies like Atlassian and Jetbrains, I still
think that CCNet is one of the most complete tools out there for the
job.

As of a few weeks ago I'm managing a team of Java developers here in
my new home of New York City. I'd offer you all a job, but you're .NET
guys, right? ;) As such it's unlikely that I'll be using CCNet much
myself, but then again maybe I'll try and get mono running on one of
our dev servers and who knows what may happen then.

I hope the project continues to grow in strength. My biggest
contribution (at least in terms of effort!) was the re-write of the
Dashboard with its own custom web framework. I still think it was the
right decision to move away from the untestabilty of ASP.NET web
forms, but there are now community led projects (like Castle,
http://www.castleproject.org/) which might be a better option. I would
be more than happy to see all my code replaced with something that
offered an easier way forward to the project.

Anyway, I'll still be lurking on the lists, so don't blame *too* many
problems on me. :)

Cheers, and all the best,

Mike

--
mike roberts | http://www.mikebroberts.com/

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

[ANN] Beta 5 for CI Factory 0.8.0.121

Announcing Beta 5 for CI Factory 0.8.0.121. It can be downloaded here and the release notes can be viewed from here. Well the suprise that I was hoping for last week never happened; maybe this week. So what is new in this release? There are some significant changes. The Analytics Package and the Alerts Package (used to be the Threshold Package) are complete. The dashboard has started to get a facelift. The VSTSVersionControl Package is complete too, with installer. Some smaller but important changes were: Getting NCover and MSTest to play nice, you no longer have to choose between coverage and app.configs for your test assemblies. A couple of new targets in the Scratch.Lib.xml: SwitchToMuchBetterUnit and SetProjectOutputDirectory. The first will switch NUnit projects to use MbUnit. The second will switch Projects back and forth between a common bin and bins per project per config. If you have alot of projects it can speed up the build to have them compile to one common directory.read more...-- Jay Flowers---------------------------------------------------------------------- http://jayflowers.com---------------------------------------------------------------------

Next Message by Date: click to view message preview

ProjectIntegratorTest.Abort() didn't like IntegrationRequestQueueTest.WaitForRequestShouldBlockUntilNewBuildIsR equested()

Hi! ProjectIntegratorTest.Abort() was consistently failing on my machine[1] when run as part of the whole test suite[2]. When run alone, it passed. I tracked it down to an interaction with IntegrationRequestQueueTest.WaitForRequestShouldBlockUntilNewBuildIsRequested(). Which I will now call "the offending test". The offending test was spawning 400 threads, and not bothering to clean them up. I'm not entirely sure why this caused Abort() to fail, but it was very consistent. It feels like the test thread was being starved long enough that the Latch's timeout expired. I'm about to commit a fix that waits for all the threads to Join(). It's expensive though: it takes up to 15 seconds to clean up all the threads on my machine. It's also still fragile because the test will fail if the threads don't clean up quickly enough. I'm sort of dubious of the value of the test. Does it really need 400 threads? Does it really show that WaitForRequest() blocks? A Blame isn't useful, because the tests were moved in CVS and the history was lost (or at least, I'm not sure how to recover it or if it is recoverable). I was hoping someone else could take a peek at the offending test and offer an opinion. The full path for the test in question is: project\UnitTests\Core\IntegrationRequestQueueTest.cs and the method is: WaitForRequestShouldBlockUntilNewBuildIsRequested Looking forward to any and all input! Dave [1] A quick note that my machine is a bit bizarre at the moment. It's a Centrino Duo, but I have the dual core "disabled" in BIOS. This is described as "the cpu won't appear as two cores to the os," which sort of suggests it is still maybe doing things concurrently, but just not telling windows? [2] The failure text from nant is: [exec] Failures: [exec] 1) ThoughtWorks.CruiseControl.UnitTests.Core.ProjectIntegratorTest.Abort : System.Exception : Latch has not been signalled before the timeout expired! [exec] at ThoughtWorks.CruiseControl.UnitTests.UnitTestUtils.LatchMock.WaitForSignal() in c:\code\ccnet-ircache\project\UnitTests\UnitTestUtils\LatchMock.cs:line 69 [exec] at ThoughtWorks.CruiseControl.UnitTests.Core.ProjectIntegratorTest.Abort() in c:\code\ccnet-ircache\project\UnitTests\Core\ProjectIntegratorTest.cs:line 155

Previous Message by Thread: click to view message preview

Next Message by Thread: click to view message preview

Re: Bowing out, and thanks

Mike, Since I haven't seen anyone else saying it yet, I'd like to say a great big thank-you on behalf of the community. Your knowledge and insight will be missed, but I am sure we all understand that as time goes on other parts of life (family in particular) need to take priority. With very best wishes for the future, Richard

Loading Comments...