My uber-cautious checkin procedure

By | February 10, 2010

Since I see that checkin errors are fairly common, and a poorly controlled source of potential issues in Mozilla code, I developed my own written process that I follow whenever I do checkins. It’s probably over cautious, with a practice checkin locally before I do the real thing, but here it is in case anyone else is interested. This is my actual text, with little massaging for general audiences:

====
Check tinderbox for current checkin status and burns

(cd pristine/src) [This is a directory containing a clone of comm-central from mozilla]
hg pull –u

(cd mozpush/src) [This is a directory containing a clone of my local pristine repository]

hg pull –u

(If there are problems, create a new mozpush directory, and do
hg clone /s/tb/pristine/src src)

hg import /f/tb/patch/name.patch
(above starts notepad, give bug & approvals and save)
hg outgoing -p
(check that the patch and comment are correct)
hg push

(cd pristine/src)
hg pull –rebase
(if changes, you may need hg update, or hg rebase -s revision -d revision)
hg outgoing -p

(if everything looks good)
hg push

Go to http://hg.mozilla.org/comm-central/shortlog and get the diff link for the push, something like:
http://hg.mozilla.org/comm-central/rev/324e7b178ad7

(or http://hg.mozilla.org/releases/comm-1.9.1/shortlog )

Go to bug, comment on checked-in attachment with above link.

Mark resolved/fixed, and add the appropriate pristine/src Target Milestone.

(when you checkin to comm-1.9.1, please set the status-thunderbird3.0 field to “.1-fixed” (or whatever the appropriate dot release is)

Follow tinderboxes.