My uber-cautious checkin procedure
February 10, 2010 – 9:50 amSince 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.