The checklist I ran through is in my personal bug tracker [0]. Almost
everything worked and almost everything went smoothly. Almost.
Here's some of the notes I made as things went along:
* Running make-wmf-branch on bast1001 needed a change to the build dir
because reedy already owns the default dir there.
** Since the first thing it does is `rm -rf` the dir I think we could
do something smarter in the script like prompt to delete after
completion and/or add the script pid to the dir name.
* Cutting the branch should be automatic. Jenkins could do this easily
and make the timing predictable for all parties.
* It seems like the php-1.XwmfY checkouts on tin could be either
shallow or single branch checkouts. I think Chad started playing with
having multiple working copies that share the same repository which
might be even nicer.
* Speaking of Chad's prototype work, /a/common/php-git makes
`updateWikiversions` throw a warning: "updateBitsBranchPointers: link
target /usr/local/apache/common-local/php-git/skins does not exist."
* I tried to make a script to automate copying security patches from
one branch checkout to the next. It worked sort of. `git apply` wasn't
smart enough to figure out that the patches I pulled off of the wmf15
checkout were already applied in the wmf16 branch. It would be nice to
figure this out and get it automated or find a better way in general
to manage security patches.
* Creating the on-wiki deploy notes is a PITA. I read the script a
couple of times and tried running on my own and with tips from Sam. I
never did get it to work for me (kept getting empty output). Sam ran
it and it worked fine but he said "I recall the script being
temperamental". We should definitely make this an automated job in
Jenkins or elsewhere. Nobody should have to babysit this kind of
communications process. (The cobbler's children have no shoes.)
* My ssh-agent (OS X 10.8.5) croaked badly when trying to run
sync-wikiversions. This seems to be triggered by the full fanout (not
batched) dsh call. Aaron had to step in and run both sync-wikiversions
for me.
* l10n sync went badly again. wmf16 got partial en l10n data and then
my `scap --versions php-1.23wmf16` to fix it blew up badly in the
scap-rebuild-cdbs step:
** Bug 62018 [1] - scap-rebuild-cdbs fails when scap called with
`--versions` command line flag - is in the python scap code I'm pretty
sure and I'll get on fixing that.
** Bug 51174 [2] - Scap broken for deploying new versions of MediaWiki
due to ExtensionMessage file not being created - looks like the things
I added in I5467ac8 [3] were necessary but not sufficient to fix this.
I stupidly didn't save a copy of the first .json files, but wmf16
didn't get full english l10n cache in the cdb until a second scap was
run. It seems likely to me that this is related to the "bootstrap" en
l10n build that I put in there to get mergeMessageFileList.php to run.
Things actually went pretty smoothly though. Thanks a lot to Chad and
Sam for helping me make a checklist and Aaron for being around to lend
a hand when I fell and couldn't get up.
[0]: https://github.com/bd808/wmf-kanban/issues/57
[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=62018
[2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=51174
[3]: https://gerrit.wikimedia.org/r/#/c/113260/
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
Sam was nice enough to help me put together a checklist for doing the
release tomorrow [0]. I'd love all of you to look it over just in case
I get hit by a bus between now and deploy time tomorrow. Plus you
might see something that Sam normally does that is either not needed
(not too likely IMHO), not efficient (possible), or not something that
you knew needed to be done.
[0]: https://etherpad.wikimedia.org/p/1.23wmf16_Deploy
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
The scripts that generate and read wikiversions.dat tolerate a wider range
of syntactical quirks than are actually seen in the file. Additionally, the
external version field may not be required at all any more.
Does anyone have a few cycles to spare to make the PHP implementation
simpler, by dropping the third field, and making the file format be JSON?
It would be up to you whether to drop the field from the CDB file as well
or whether to simply hard-code an empty value for it.
This would make it much easier for Bryan to have the Python implementation
match PHP in behavior.
---
Ori Livneh
ori(a)wikimedia.org
Hey all,
I just got this as an admin of our list.
It is apparently public, but without any use:
http://lists.wikimedia.org/pipermail/mediawiki-core/
So:
FIRST POST!!!!!!!!!1111
Anyways, just confirming with the list on this one. I think we agreed on
public/archivable, but there was a lot of confusion/bike shedding when
this list (and the google alias) was created last year. I could be
misremembering.
Greg
----- Forwarded message from mailman-bounces(a)lists.wikimedia.org -----
> Date: Sat, 08 Feb 2014 22:57:02 +0000
> From: mailman-bounces(a)lists.wikimedia.org
> To: mediawiki-core-owner(a)lists.wikimedia.org
> Subject: Uncaught bounce notification
>
> The attached message was received as a bounce, but either the bounce
> format was not recognized, or no member addresses could be extracted
> from it. This mailing list has been configured to send all
> unrecognized bounce messages to the list administrator(s).
>
> For more information see:
> https://lists.wikimedia.org/mailman/admin/mediawiki-core/bounce
>
> Date: Sat, 08 Feb 2014 23:57:00 +0100
> From: Gmane Admin <gowmc-mediawiki-core(a)m.gmane.org>
> To: mediawiki-core-admin(a)lists.wikimedia.org
> To: mediawiki-core-admin(a)lists.wikimedia.org
> Subject: mediawiki-core added to Gmane
>
> We have received a request for adding the
> mediawiki-core(a)lists.wikimedia.org mailing list to the Gmane
> mail-to-news gateway/archive. A subscription request message has been
> sent. If this is contrary to your wishes, please send a mail to
> admin(a)gmane.org saying so, and the list will be removed from Gmane.
>
> Gmane is a mail-to-news portal that never expires its messages. It
> therefore also functions as a mailing list archive. It's a
> bi-directional gateway, but Gmane verifies that its users' email
> addresses are valid before passing the messages through the
> news-to-mail gateway. (Groups can also be made "read-only", which
> means that Gmane won't forward any messages at all to the mailing
> list.)
>
> Gmane can encrypt addresses to make address harvesting difficult, and
> heeds X-No-Archive and related headers.
>
> If you wish to import older archives into Gmane, send a message to
> the Gmane administrators with the URL of a Unix mbox archive of the
> mailing list.
>
> In partnership with The Mail Archive, messages will be archived on
> that service as well. This provides redundancy across two archival
> services.
>
> The following parameters are set for this mailing list:
>
> * Newsgroup name: gmane.org.wikimedia.mediawiki.core
> * Mailing list address: mediawiki-core(a)lists.wikimedia.org
> * The gateway is bi-directional
> * Address encryption is on
> * Spam detection is on
> * The list is described as:
> "Wikimedia's MediaWiki Core team"
> * News URL: news://news.gmane.org/gmane.org.wikimedia.mediawiki.core
> * Web URL: http://dir.gmane.org/gmane.org.wikimedia.mediawiki.core
>
> This newsgroup will be created when the first message from the
> mailing list arrives.
>
> For more information about the Gmane project, go to
> <URL: http://gmane.org/>.
>
> For more information about The Mail Archive, go to
> <URL: http://www.mail-archive.com/>.
>
> This request was handled by
> asjo(a)koldfront.dk (Adam Sjøgren).
>
>
----- End forwarded message -----
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |