Thunderbird/Students/StatusUpdates/2010-02-26

This week’s Random Notes

Patch Development Process

A little help for the development and submission of your bug fixes.

First, about mercurial. Mercurial repositories have both a local repository and a remote repository. When you commit, you are making changes to the local repository. To update the remote repository, you have to do a push, which you don’t have rights to do, so don’t worry about messing anything up! Even if you do something drastic to your own repository, you can revert the changes.

Here is the link to the official patch submission page. Recommended reading for all. https://developer.mozilla.org/en/Getting_your_patch_in_the_tree

Before You Begin

You should install and use the pbranch addon for mercurial. This will help you track changes across multiple directories.

• get the master repo.

hg clone <repo>

• create a pbranch for our changes.

hg pnew <branch-name>

While developing

Be sure to commit your changes early and often. This is the whole principle of a versioning system!

• hack hack hack
• Make sure we've changed what we thought.

hg diff

• commit the changes to our branch.

hg commit  

• repeat the previous three lines as needed.

Posting Your Patch

When it's time to post your patch:

• move back to the default branch.

hg update default

• pull in the changes from the main repo and update our working copy.

hg pull -u

• Merge the changes into our branches.

hg pmerge --all

• move back into our branch

hg update <branch-name>

• Save the diff between the changes we made and the main repo.

hg pdiff > filename.diff

Then, attach that patch to the bug, and you're done.

For more info:

http://weblog.latte.ca/blake/tech/thunderbird/mercurial

http://weblog.latte.ca/blake/tech/thunderbird/pbranch

Status Updates

Tim Miller

Posted the information above about submitting patches.

So I've been worried that I won't ever get this patch to build and all the changes I've been bragging to everyone that I'm making will not actually happen. I've also been getting more and more frustrated with not being able to get this to work. So this week I spent a LOT of time working on this, and finally made some good progress.

One of my problems that was preventing me from compiling was that somehow the compile process did not recognize my new file and do what was needed with it. I decided there was another file that really should have had my new interface function in it in the first place and put it in there instead.

After doing so, I got all kinds of datatype errors. I eventually found the documentation for xpidl and found out there were only certain datatypes I could use in an interface file. However, I was able to forward declare some of the mozilla datatypes in the interface file and use them when they were not listed on that page, why couldn't I declare others? I never really found the answer for that, so I adapted my code to use what the datatypes that didn't scream errors at me.

In the quest to find out how to use the datatypes I wanted to use I searched through the cross reference site to see how they were used in other files. I ran across a function in another library that converted between the two types I wanted to use. I realized I was doing things wrong, and that I should have been using that function. Why my code compiled in the first place, I don't know.

I finally worked out the kinks with my datatypes, and using that function and casting was able to convert to what i needed to pass to the windows API function. And finally, IT COMPILED!!! I have to say, I had to look at the compile log like 3 times before I actually could believe that it had done so.

So I finally submitted a patch this week. I will be working on the tests for it next as i don't actually know if it works yet. lol.

Who’s writing the blog post this week?

Evan Stratford