One think to note here. Changes above are dependent on the commit @atul made: https://github.com/CommE2E/comm/commit/a04a84f3a156c218dd778a5f9d0905d2abf9910b. Currently master does not include those changes since they were reverted here: https://github.com/CommE2E/comm/commit/63233aa3f2f12801a07f96ff999761dab7aa346b. I locally cherry-picked the first one to implement and test those features. This is the first time I am dealing with diffs this way so I am not sure what is going to happen if I try landing and how we should approach that.

That's interesting. We should probably get @atul's opinion on this... probably he has this change locally, and will need to update his local patch. I'm guessing we won't be able to "land" this like we do normally (arc land, which does git push to master) but we can manually "Close" it once we're done.

In D4654#133747, @ashoat wrote:

That's interesting. We should probably get @atul's opinion on this... probably he has this change locally, and will need to update his local patch. I'm guessing we won't be able to "land" this like we do normally (arc land, which does git push to master) but we can manually "Close" it once we're done.

Yeah I have a local patch that I've been applying when making releases that adds this Redux/SQLite equality check.

Now that these changes have been "approved, "I can update my patch to include these changes and make a release... does that seem like a reasonable approach?

Yeah that makes sense to me, if the changes look good to you!

This looks good to me, will kick off build 138 momentarily.

Are we still using this patch in staff releases?