Source Repos

We can use either github or hg for this. They can both support the necessary usecases, however, the main differentiating issue here is that github will NOT allow us to have a central repository not controlled on one of our github accounts (this is due to their terms of service agreement).

So here are the workflows:

• Merge the three repos into one.
• Mozmill
  • jsbridge
  • mozrunner
  • mozmill

Structure of directories inside these repos will remain the same. Having them all together in one repo will help make this tool easier to version and maintain, particularly when it comes to code maintenance.

Branch Logic (for both repo solutions)

The main repo will have one main branch:

• trunk
• release_<relnumber>

We will create a new release branch for each released branch of code and small fixes will go into that release branch for the "next release" as well as any backports to that release.

Let's pretend we had this code structure right now. Then "hg branches" or "git branch -r" (you have to use -r to see remote branches, which is how they will appear in your fork) will output:

• trunk
• release_1.4
• release_1.4.1
• release _1.4.2

Once we develop on trunk to a point where we will release, we create the release branch at that time.

Once we decide to do a backport release (a release based off a previous release) we branch to the new backport release name. For example, when we decided to embark on 1.4.2, we'd have created the release_1.4.2 branch at that time.

Github Central Repo Issue

We create the new repo on Mikeal's github account (or merge everything into the existing mozmill one). All extraneous branches are removed. In some ways it will be easier to simply create a new repo on his account and add in our stuff there. Alternatively we can create the new repo on my account and we can go from there.

• Regardless of where the "master" lives, Commit rights go to: harthur, jhammel, whimboo, ctalbert (that may be difficult if we keep it on Mikeal's repo, I haven't talked to him about it. But I'm sure that he'll agree to this).

Workflow

Our workflow that we are using in git has a name: Integration Manager. You can read all about it here.

Github workflow

How do you commit to it?

• git checkout <relbranch>
• git branch <feature/bugfix>
• git checkout <feature/bugfix>
• do your code for your feature or bugfix
• git commit -a -m "commit message"
• git push origin <feature/bugfix> # pushes branch to your forked repo on github
• submit pull request/patch (see below)
• Once the patch is accepted, you can delete the branch: git push origin :<feature/bugfix>
• The git maintainer of the central repo has to pull your change, merge, and push to the central repo.

Hg Central Repo

It's trivial for us to create a central repo for mozmill on hg.mozilla.org/automation. Every person on the current list already has commit access to that area since it is covered under Level 2 commit access. Each person's "clone" of the repo becomes their own fork.

We of course lose the nice diff viewers and the comment ability and feed/notification stuff you get with github.

Hg Workflow

Here's how to work with branches in Hg

• hg update -r <relbranch>
• hg qnew <feature/bugfix>
• do your code for your feature or bugfix
• hg qrefresh -e
• hg qdiff > mypatch.diff (submit patch for review, see below)
• hg qfinish -a
• hg push # This puts your change into the central repo

The subtle difference

There is a subtle difference here. In the interim when you're working on a patch, with github you can push it to your local fork on github.com, so the code is off your computer. With hg, this is possible by publishing your mq to your local user hg repo, but you don't get that feature automatically and it would take a few more steps. That's a subtle difference, but an important one.

Git pushes the work of integration with the main line of code into the hands of the maintainer, which gives it a single point of failure. This is why I want to give everyone currently involved on the project write access to the central repo. With hg this is not the case. But if your computer dies and isn't backed up (and you didn't publish your changeset or put it in bugzilla) then that's gone. Most of the time, things end up in bugzilla patches pretty quickly so this isn't too important, but it's worth calling out.

Patches, Pull Requests and Keeping track of Reviews

The primary notification system we have to notify people of "patch is ready for bug x" will continue to be bugzilla. The github workflow is not well matched for use in bugzilla. You can get a patch as follows:

• git format-patch <headbranch> --stdout > mypatch.patch
• Example: Let's say I'm working on feature foo2:
  • git checkout release_1.4.2git format-patch release_1.4.2
  • git checkout foo2
  • do your stuff, do some commits
  • git format-patch release_1.4.2 --stdout > foo2.patch

You can then attach that patch in bugzilla. I'd say for big reviews where we need people's attention, that's the way to go (or for reviews by people who don't use github). For small things and "feedback" reviews, I think the paradigm we've been using of posting the diff link/commit URL into a bugzilla comment works fine.

For hg, you get a patch doing hg diff or hg qdiff (whether or not you're using mercurial queues). You can attach that to bugzilla, and we handle like we do normally.

Bug Tracking

There are a hundred thousand ways to track something in bugzilla. Half of them are convention and the other half do something like what the bugzilla devs actually meant them to do in our b.m.o hack.

• Target Milestone & Version - these are Product level fields that are specific to a product. That means that the entire testing product would have to be modified to have specific data about versions and target milestones of mozmill. I don't want these numbers getting in the way of the other Testing Components which could well (and will soon, I hope) have their own versions. Beyond that there are other issues with these fields:
  • Target Milestone - I've seen this argued up and down several mountains in the time I've been on the project. It always seems like overhead, everyone except QA forgets to set it, and it rarely means what you think it should. Consider this: "If a bug is fixed on 1.4.2 is it fixed on trunk? Probably, but not if it is in the editor code because that's all been replaced and the original bug might still be a behavior in Bespin for all we know." I think we should not worry about it. Furthermore these are Product level fields
  • Version - is this the version the bug is found in? Or the version the bug is fixed in?
• Flags - these can be done on a component by component basis within a product. If the existing convention of whiteboard flags are not sufficient, then we can look at using these to achieve the level of tracking desired from the TargetMilestone and version fields. Although I really don't see how the whiteboard flags are not sufficient.