Click here to see our release announcement.

Best of luck with exams (for those of you who still have them); I hope to have the chance to work with you again some day.

Different from most of you, our project started at IBM’s lab, not at the St. George campus. On our first morning, all of us were invited to their lab at Markham. The lab itself is a really cool place, and the IBMers have treated us well. But to be honest, it’s not exactly the greatest experience. We were basically given a crash course on DB2, then the TE (which is the foundation that our project is building upon), plus some unsuccessful troubleshooting session on how to get both working on a Mac and Linux. Because the amount of information is SO overwhelming, by the end of the day, all I was left with is frustration and question marks. Heck, I don’t really understand the porject that well to begin with, but then it feels like I understand that even less when we leave the labs. As everyone have already started doing some coding in the UT campus, I thought we would be doomed.

On the second day, things start to look a bit better. Matthew gave us a walkthrough of the TE codebase. Overwhelming, still, but we are starting at least starting to see what this is all about. (The lack of projector is really leaving something to be desired… six kids staring at a ultra-high pixel density laptop monitor… not even funny!) We also did, in my opinion, one of the most important things for our project. We set up or communication channel (Skype) and a meeting time (Tues, Thurs). Yes, it’s taking a lot longer than it should, and it could be done more efficiently, but I believe it’s well worth the cost, we’ll talk about this more in a bit.

By the end of the code sprint, most of us still haven’t got of systems set up probably. But then I started to understand more about our project and it seemed quite a bit more approachable.

As we splitted and returned to our home city, the first challenge is to get things working on our end. This marks the first collebration of our team. Within days, the wiki is populated with detailed instructions on how to get things working and what works and what doesn’t. We also helped each other out on Skype. Perhaps it’s the frustration we have in common that really bonded the whole team together, and this helped to smooth things out a lot for the rest of the term. It still takes a few more weeks and a lot of help from IBM (esp Paul, you’re awesome!!) before our systems are truely functioning, but can at least start doing some useful work now.

My first assignment is to investigate the recurssive queries issue. Basically, I need to write a recurrsive query that saturates the CPU. It took me quite a while to figure out what that even means. This is pretty much my first official encounter with the massive DB2 system, so I spent a good amount of time researching and learning how to fight this little monster. After a lot of trial and error, I have sucessfully created a recursive query that does some interesting things. However, the result is quite disappointing. Although it took me days to write that query, it only took the database 5ms to execute it. Matthew suggested that DB2 might be doing some crazy optimization behind the scene for me. Although this attempt turned out fruitless, it was a good experience and allowed me to get myself familiar with the DB2 system.

I was then reassigned to work with Mike on his locklist overflow scenario. His scenario worked beautifully on his machine, so I took up the task to reproduce and record that on my laptop. However, after a night of trial and error, I still cannot reproduce the problem on my own machine. I did some extra research and concluded that the behavior might under this situation is undefined, so it varies wildly across machines. I looked into the nature of the problem and proposed some changes to the scenario (changed from locklist overflow to lock escalation). Although we didn’t end up using this scenario, we did some serious work reseearching that problem, and left some pretty good foundation for other people to pick that up in the future.

To avoid slowing down our progress due to the extra work needed for the lock escalation scenario, I picked up on Sylvian’s lock wait scenario because it’s much simplier to reproduce and understand. We then continued our work based on this senario and ultimately produced a working version of our scenario and attached it in the final delieverable.

What I have learned…

1. Reading other people’s code

By far, I think this is the most valuable experience for me. In the real world, developer documentation is a luxary for lot of open source projects. Having the experience of reading and understanding other people’s code will allow me to contribute to a wide range of open source project in the future.

2. Working within a distributed team

This is probably one of the most important that Greg planned this course for us. I realized how important it is to maintain good communication with the team. What makes our team unique in UCOSP is that we have two weekly meetings, one via conference call, one via Skype chat. Although this could be overwhelming at first, I do find this highly valuable and would recommend other teams in UCOSP to do the same.

3. Asking help

Without the help from IBMers like Matthew and Paul, we wouldn’t have gone this far for this project. I learned to ask help when you need it, and more importantly HOW to ask help. Describing a complicated problem clearly (but overwhelming) could be challenging and this course turned out to be an excellent opportuinty for practicing that.

What I liked…

• The semi-weekly meetings!
• IBMers are very helpful… and often respond within ours of us asking a question.
• The project was challenging, in a good way.

What could be better…

• The initial project definition was too vague… Because most students joining this team will not have the experience needed for understanding the project, I think it’d be a better idea for provide more guidance and make things more concrete for them at the beginning. Then, allow them to have more flexibility as they learned more about the project. (i.e. provide some clear and rigid goals, instead of allowing us to make our own goals right from the start, because we wouldn’t be able to take advantage of that flexibility at that time anyways)
• The pieces we are building upon wasn’t quite ready for prime time yet when we first started, which caused a lot of frustration as we spent most of our time debugging and setting things up in the first few weeks. I believe this has mostly been addressed by now, thanks to the new releases and the sandbox server.
• More documentation would be nice
• The code sprint was quite overwhelming for most of us.. maybe we can aim to do/learn a little less at the sprint..?

Again, I would like to thank the IBMers (esp Matthew and Paul) for providing us such an incredible experience!

Wei Xian has resolved his bug (restore session) and his patch has been pushed to comm-central. Also, he is going to prepare a “quick start guide” for future students who are going to work on Thunderbird. For myself, I have posted my revised patch and get the review from Blake. Now I have submitted a secondary review request and hopefully everything is going all right.  Evan is working on his own RFC 2425 parser to provide (de-)serialization of RFC 2425 directory entries into a data structure designed to support simple lookups on types and parameters. Now he is waiting for his patches to be reviewed. Zach is working on applying his patch and running mozmill test on his machine. There are still some issues for me to handle with the testing. Lindauson is still working on the menu items and seeking suggestions.

Khushboo has been wrestling with git and getting her branch(s) to push properly.  Some very informative posts can be found on her blog. She also continues creating build scripts for other python packages.

Fatima:

Fatima has been working on getting branch support in for Mecurial checkouts in pony-build, to go along with the new changes, she has also been working on tests. You can read up on all her research into the subject as well as her progress over at her blog.

Jack:

Jack has been continuing his work on his pony-client changes. During his work on this he stumbled onto another bug with forcing builds that he is looking in to also.

Max:

Max has implemented a fix for defaulting to an in-memory db for the server. He has also been working on some failure conditions within build steps under a certain context. He,however, has taken a break from the perils of subprocess timeouts until he can secure a windows machine for proper testing. You can mozy on over to his blog for more info.

Edit: When is pony-build going to get some love and have our own Category?

Paul and Alex have a little more time before official end of classes at UBC, and we’ll probably be hearing from them after the meeting this week.

Status updates:

• Bfiles auto-* integration
  • auto-status and auto-update have been accepted into bfiles
  • auto-put and auto-refresh are almost there
• Wendy and Tessa continued to improve on their warm-up projects:
• Paul has a working version of bfilesify which converts existing mercurial repositories to use bfiles. We are playing around with it to provide feedback.
• Alex has been working on his ever-popular case guard extension.
• I have started work on implementing my extended status proposal which aims to create closer integration between bfiles, subrepos, and core Mercurial code.

As always, you can find detailed status reports on our Wiki at https://ucosp.fogbugz.com/default.asp?W44

I believe this applies equally well to us: the real challenge of UCOSP is not the coding, it’s learning to work with a community. This is especially true for the Mercurial team because we are working with such a large, established, global community of developers. Working within our UCOSP team was alright for our initial warm-up projects where we built new Mercurial extensions or added isolated features, but it became very important when we started working on the bfiles extension. We collaborated extensively with Greg Ward, the creator of bfiles. Towards the end, he helped us extensively with combining and polishing our patches, and as a result, they integrated smoothly into his tree. The more we engaged the developer community, the more productive we became.

The post that I link to has some other great pointers for anyone new to an opensource project – not necessarily those doing it for credit or money. It’s worth a read.

It seems like several of us are having difficulties with unit tests, with myself and Zach having trouble getting working unit tests off the ground, and Wei Xian adding some polish to his previous unit tests.

Also, Tim and I are feeling the crunch of other courses so haven’t been productive over the last week.

Many of us, including Kefu, Tim, Evan, and Wei Xian have been working hard with Mozilla reviewers to make changes to their code. It’s nice to see that the project as a whole places such emphasis on code quality and correctness, and we’re all learning a lot from what they are telling us to do!

And of course, while working on tests and getting past code reviews, some of us are trucking along working on other tasks – Lindauson is hard at work trying to get menu items to behave the way he wants them to, Wei Xian is working on standalone message window behaviour, and I am working on listening to folder compacting events so that they properly display themselves in the activity manager.

• Technology Explorer for IBM DB2: https://db2mc.svn.sourceforge.net/svnroot/db2mc/UCOSP/release/final
• WMD workload profiles: https://db2mc.svn.sourceforge.net/svnroot/db2mc/UCOSP/release/final/config_files%20in%20WMD/
• Document on how to add new scenarios: https://sourceforge.net/apps/mediawiki/db2mc/index.php?title=Adding_new_Scenarios
• Document on how to use TE to test a person: https://sourceforge.net/apps/mediawiki/db2mc/index.php?title=Testing_a_person_DB2_diagnostic_knowledge_using_the_Technology_Explorer
• Document of graphical indicator: https://sourceforge.net/apps/mediawiki/db2mc/index.php?title=Action_-_indicator
• Final video of locklist tutorial:
  • URL1: http://vimeo.com/10569706
  • URL2:  to be uploaded to sourceforge.net
• Final video of IO tutorial:
  • URL1: http://reseau.twisto.ca/io.m4v
  • URL2: http://www.youtube.com/watch?v=RLgOBTtMyvs
  • URL3: to be uploaded to sourceforge.net
• Individual reports:
  • Diane: http://dianetam.com/dev/blog/
  • Lenny : http://hanlenny.wordpress.com/
  • Jean: to be submitted individually
  • Sylvain: to be submitted individually
  • Godfrey: to be submitted individually
  • Michael: sent earlier via email

Status

• Looked further into Bug 303420: Simplify the user experience when renaming a type from the pop-up menu. This may not actually be a task I can accomplish before the code freeze, taking into account the other things I had also intended to finish before then.

Final Steps

• Look into Bug 303420: Simplify the user experience when renaming a type from the pop-up menu.
• Go back to Bug 299342: "New Java Package" option should automatically create a Java Project, to use the NewJavaProjectConstructor to create the default project.
• Address Bug 303427: Can’t specify a source folder in the Package Wizard.
• Complete final report.

Roadblocks

• Last week involved several major deadlines for other courses, but I can now focus this week on finishing up my ongoing goals for Eclipse..

Cory

Status

• Added some additional comments to Bug 301327 (Creating a src folder when creating new Java project – This bug may not be applicable anymore) and to Bug 302362 (Support for java applets – This bug may also be obsolete now).
• Overall, I did not have a productive week with regards to IDE4EDU. Still waiting on feedback from Wayne, and at least 50%+ of our bugs require some form of feedback, committing, closing, or additional information. So, I took this opportunity to work on my many other projects and their fast approaching deadlines, with the hope that when Wayne gets back I will be able to dedicate more time towards IDE4EDU.

Final Steps

• Of the bugs left that aren’t in 1 of the categories above, I think I might take stab at Bug 302360 (importing projects into javalite) or Bug 303584 (Linking javalite explorer with editor). In both cases, there is existing JDT functionality that we want to emulate, so they sound feasible given our remaining week before the code freeze.
• Unless of course we get feedback from Wayne, in which case I will attempt to address those potential issues, etc.

Roadblocks

• (I know its a broken record… but) Other classes.
• Feedback would be appreciated on pending patches. (We are here to help! Let us help!)

Miles

Status

• Worked on simplifying the menus using the activities extension.
• Managed to hide all but 2 or 3 things that I wanted hidden.
  – Simplified the toolbar significantly.
  - Really happy with how this turned out. Makes Eclipse much less intimidating.

Final Steps

• Simplify the menus and toolbar to the list of items I suggested in bug 299848.

Roadblocks

• Nothing major. Everything is working out pretty well on this bug. I’d like to control the order of the toolbar buttons but I can’t figure out
  how to do that yet. Also, I’d like a couple of the menus to go away when they don’t have any items in them like the Run menu.
• I’d love to hide the Navigation menu but it seems to be hardwired to the Workbench or something. I think we’d need to create an RCP app to
  completely get rid of it.
• We need to create a better Run and Debug button but that is too big a job for the time we have left on this project. I’ll add another bug for this.