Mozilla Bug Process – 0.4 Release

These last 2 weeks have been a real doozy. Massive push for every student I know to get their work done on time, or at least done in some cases. In the end it all must get done and in my case, I had to make sure I finished my work for the bug Rename nsPLDOMEvent to nsAsyncDOMEvent.

The bug itself is very simple and really only required some simple search and replace in the files that mxr reported as containing references to it. Simple stuff really.

The patching processing is a whole other story however. Mozilla uses mercurial for their revisioning system over one like git, so for the rest of us sane people this creates issues when trying to get changes approved because we have to use some magic to to convert our patches to be something that’s compatible with hg (Okay it’s not REALLY magic, more like a handy alias found here).


[alias]
hgp = show --format=\"From: %an %n%s%n%b\" -U8

This handy little alias allows our patches to have an automatic format to them that’s acceptable for the hg patch system. After that the path has a fork in the road depending on how your development process has gone. If you made multiple commits at all (highly likely if you are working on anything that requires a lot of work, or in my case are forgetful), you will need to rebase your code first and use the fix-up command because this will squash each commit into one, making it all one big “patch”.

In my case I needed to submit this patch a few times because of different style’s than Mozilla is expecting. Unfortunately no one is perfect and it didn’t pass review the first two go tries because of indenting issues. The second one was because I missed one single indent problem that was actually present in the code originally and I just didn’t catch it. Like humph has said many times in open source you inherit the code of others, including their errors!

However I wasn’t done yet there. After the second patch they also asked me to go and change another subclass of nsPLDOMEvent; nsLoadBlockingPLDOMEvent. It wasn’t included in the original ticket but needed to be changed for the same reasons so might as well get that one done as well and kill two birds with one stone. The problems I had here was how I should be constructing my patch now. Should it be everything consolidated into one? Two patches, but both based off of the original mozilla-central code? Or, as I went with in the end, two patches where the latter “piggy-backs” off the changes of the first, meaning the second patch would be based off the I made in my repo based for the first.

The reason why it’s better to keep it separated into two patches is because well, it’s two different changes! Consolidating them into one can lead to potential issues and is simply harder to review so it made sense to do it like this.

At this point the ticket is just about done. My first patch is set to checkin? (basically awaiting confirmation) and my second patch has been set to review+ meaning it passed it’s review and is waiting to be checked in. This has been quite the exciting semester and I have enjoyed it a lot. I definitely feel that I have been able to grow a lot as a developer by being exposed to real world work and the kinds of expectations they have. Had a blast, however it’s not over!

See you in OSD700!

😀

Advertisements

One response to “Mozilla Bug Process – 0.4 Release

  1. Pingback: Implementing Mouse Lock, conclusion

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: