It's been very buggy for a while, has limited usefulness compared with
unread counts, and profiling over the weekend indicates that it's very
slow.
(imported from commit 716fe47f2bbec1bd8a6e4d265ded5c64efe2ad5c)
Now we have 2 different Zulip apps out there, and they are signed with
two certs: Zulip and Dropbox. The Dropbox-signed apps are going to need
to be sent APNS notifications from the appropriate APNS connection
(imported from commit 6db50c5811847db4f08e5c997c7bbb4b46cfc462)
The feedback bot needs to be included in the OG_ZULIPER_EMAILS so users
can send feedback.
(imported from commit b0c3295379d0f062a912f8b6c957419335be1c48)
This needs to be deployed on both prod and lb0 to be functional
DEPLOY INSTRUCTIONS: restart carefully
(imported from commit d97a450754608357418c80e5b3c7b3bbcd1d09fb)
I don't think this matters a ton, but there's no reason for
the two muting files to come before setup.js.
(imported from commit c18231b633fba6acccaf5bc180c7605f7591462e)
This experiment has been disabled for everyone for a while: if we
bring something like this back, it is not likely to be exactly the same,
and will be different enough to require a different implementation.
As it is, the summarization code was making a few code paths (rendering
especially) more complex, and is worth removing for simplicity's sake.
(imported from commit 6ac8cdc9f7077a5a1da01ab4268aba3db0bc43f8)
Before we deploy this commit, we must migrate the data from the staging redis
server to the new, dedicated redis server. The steps for doing so are the
following:
* Remove the zulip::redis puppet class from staging's zulip.conf
* ssh once from staging to redis-staging.zulip.net so that the host key is known
* Create a tunnel from redis0.zulip.net to staging.zulip.net
* zulip@redis0:~$ ssh -N -L 127.0.0.1:6380:127.0.0.1:6379 -o ServerAliveInterval=30 -o ServerAliveCountMax=3 staging.zulip.net
* Set the redis instance on redis0.zulip.net to replicate the one on staging.zulip.net
* redis 127.0.0.1:6379> slaveof 127.0.0.1 6380
* Stop the app on staging
* Stop redis-server on staging
* Promote the redis server on redis0.zulip.net to a master
* redis 127.0.0.1:6379> slaveof no one
* Do a puppet apply at this commit on staging (this will bring up the tunnel to redis0)
* Deploy this commit to staging (start the app on staging)
* Kill the tunnel from redis0.zulip.net to staging.zulip.net
* Uninstall redis-server on staging
The steps for migrating prod will be the same modulo s/staging/prod0/.
(imported from commit 546d258883ac299d65e896710edd0974b6bd60f8)
The file test_runner.py has our subclass of DjangoTestSuiteRunner
and various methods that help it work.
(imported from commit 8eca39a7ed3f8312c986224a810d4951559e7a8b)
Before deploying to staging, create the tutorial bot:
email: welcome-bot@zulip.com
name: Zulip Welcome Bot
(imported from commit 2f337a00ffac888b121975bdb95a89cf2f8ab3a7)
Add javascript to handle the button clicks and update the status based
on the subscribe and unsubscribe events from the server.
(imported from commit 6b9c0b40d9084e3d8b64bed701ebc786bef6d432)
The one call we were making to it was actually unnecessary since highlighting is
no longer done client-side.
(imported from commit 7644a5961ca48cd57f4b65c6f698083677e0a130)
Make our dev setup more similar to prod by using compiled.js,
instead of AJAX-ing templates on the fly and compiling them
with non-node code. This will make our dev environment more
consistent with prod (to avoid surprising bugs), plus it should
be faster (fewer AJAX calls).
This change also means we don't have to keep two copies
of static/third/handlebars/handlebars.js around.
(imported from commit d8d584b9aa13adcdcce7e424033610d77d2df79b)
Tim Abbott
Zev Benjamin
Leo Franchi
Jason Michalski
Luke Faraone
Steve Howell
Waseem Daher
Allen Rabinovich
Leo Franchi
Zev Benjamin
Jessica McKellar
Luke Faraone