This week’s Random Notes

Patch Development Process

(By Tim Miller)

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. When you do so, set "Review" to "?", and put ":bwinton" in the text field beside it so that Blake will get an email and can review your code. You can access those settings via the 'Details' link next to the attachment in your post if you forget to do so.

For more info:

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

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

Status Updates

Zach Church

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.

Marcel Guzman

Kefu Zhao

This week I was trying to get the headers information of an email because I need the "Delivered-To" header to decide which "From" address to use.

Basically, the first method I tried is to call MsgHdrToMimeMessage() to get (aMsgHdr, aMimeMsg) variables, which can get me "Delivered-To" headers by calling aMimeMsg.getAll("Delivered-To"). Actually, this method works very well except that it's an asynchronous method that is executed at the backend. As a result, it doesn’t really fit the current code structure in that the method getIdentityForHeader(), in which MsgHdrToMimeMessage is used, will return an empty string representing the “Delivered-To” header because MsgHdrToMimeMessage still doesn’t finish executing.

This week I am going to try some other ways to get the headers. Currently I am trying to use nsMimeHeaders that can extract header information by calling nsMimeHeaders.ExtractHeader(). Hopefully I can get some luck here.

Lindauson Hazell

Evan Stratford

Finally! After two weeks' hiatus, I've continued my work on vCard import:

• Took the time to figure out pbranch. Since I hadn't been using it before, this took a quick run through the usage tutorials to get acquainted with pbranch, an hg diff to get my changes thus far, a complete rebuild (in retrospect, hg backout might have saved time), patch to apply the changes again, and hg pnew to get the changes into a patch branch. Despite the fairly involved process, I'll echo bwinton's sentiment that pbranch is awesome: it brings the process of simultaneously working on multiple bugs much closer to what I'm used to from git branch.
• Posted the patch.
• Incorporated some feedback from Standard8: removed nsVCardStringBundle and replaced it with an nsStringBundle member in nsVCardImport, removed some unnecessary comments and debug code, and moved some other debug code into nsVCardImport.h. I haven't switched over to string-based indices for the message bundles yet; I'm hoping to get to that next week.

Wei Xian Woo

This week has been the busiest week of the term so far for me with all my courses having midterms this week, and I also have a 4-hour external exam tomorrow (Saturday). However, I have been able to work on the changes suggested by Blake in his review of my first patch. In my first patch, I implemented test cases that tested only the "good" cases, but there are no test cases for when things go wrong. I have been working on a few of those.

I anticipate that my revised first patch will be ready by late tomorrow or Sunday.

Who’s writing the blog post this week?

Evan Stratford