C# Status: 2/18/2005

I was sick all last week, so this week started slowly for me as I fought fatigue and an onslaught of bugs and process issues. Our fix rates have definitely slowed this week, as we've only started accepting bugs that have a large customer impact are rigourously tested and dont have a high risk. This week we took some security fixes, a couple of crashes and some hangs in key scenarios.

Our QA team did a great job last week of testing all our fixes before we checked them in. They were a bit stressed out as they are doing a full test pass at the same time, but kudos to them, they've been working very hard all week and just being superstars in general.

We spent a good amount of time doing perf investigations this week. We've started looking extensively at ways to make our perf scenarios faster and we hope to make some good gains here.

We also began to cast our heads to the future and look at how to keep our next and final milestone RTM stable. We are going to triage our RTM bugs again, to make sure ones we dont need to fix are resolved. We are going to do some work to improve our checkin tests and run more tests to make sure its stable. Lastly we are probably going to have another ZBB on our bugs in the future.

Thats the quick summary for now. Hope everyone had a good week with their projects.

Shaykat

Comments

  • Anonymous
    February 21, 2005
    http://weblogs.asp.net/lorenh/archive/2005/02/18/376191.aspx relating log4net to the new Enterprise Library.

    I haven't personally done the perf tests reported here (at the bottom), but I had just read this post prior to reading yours about improving perf. If the numbers reported here are anywhere near accurate, there is a big disconnect (up to 900x) between what PAG considers "best practice" and performance in this scenario.

    I realize this test uses 1.1, but it might be interesting to test it against 2.0. Hopefully, it is just a fluke and the perf numbers were inaccurate for some reason.

  • Anonymous
    February 22, 2005
    "Our QA team did a great job last week of testing all our fixes before we checked them in"

    Can you explain how you do this?
    Do you have a two phase source control system where you check into QA initially, then when they are happy, they complete the checkin to the live system?

  • Anonymous
    February 28, 2005
    We have a two phase where we build private dlls for QA and have them test it out. Once they run tests to make sure the bug is fixed and nothing else is broken, we take the bug to our shiproom and ask for permission to check this in. Once the customer scenario meets the bar, and the bug is approved, it goes into the live bits.
    Hope that helps.

  • Anonymous
    June 09, 2009
    PingBack from http://insomniacuresite.info/story.php?id=7071

  • Anonymous
    June 15, 2009
    PingBack from http://mydebtconsolidator.info/story.php?id=15549