[00:42] <StevenK> Hmmmm
[00:43] <StevenK> Not really happy with this query
[00:43] <StevenK> And it seems BulkUpdate does not love list types
[00:44] <wgrant> Indeed, probably not
[00:45] <StevenK> I don't like the NULLs, either
[00:45] <wgrant> ?
[00:46] <StevenK> wgrant: http://pastebin.ubuntu.com/1422314/
[00:46] <wgrant> Right, those will want to be removed.
[00:47] <wgrant> (potentially by coalescing the potentially null array with an empty one)
[00:48] <StevenK> Hmmmm, can I just use COALESCE for that?
[00:49] <wgrant> Yes
[00:51] <StevenK> Hmmm, it will only return the first, though
[00:51] <wgrant> Hm?
[00:52] <StevenK> "The COALESCE function returns the first of its arguments that is not null."
[00:52] <StevenK> If I feed it an array of {NULL,0.9,1:0.9} ...
[00:52]  * StevenK plays
[00:53] <wgrant> Hmmmm?
[00:53] <wgrant> You'd either remove NULL from the resultant array, or coalesce a null array
[00:53] <wgrant> Not coalesce an array that contains null
[00:54] <StevenK> So my query as it stands is okay?
[00:56] <wgrant> Perhaps something like https://pastebin.canonical.com/80039/
[01:01]  * StevenK searches for his phone for 2FA
[01:07] <StevenK> [(1, '{0.9}')]
[01:07] <StevenK> Looks like success to me
[01:07] <StevenK> Except for that quoting
[01:08] <wgrant> It's probably because it's a debversion[], not a text[], so psycog2 doesn't know what to do with it
[01:12] <StevenK> TypeError: Expected unicode, found <type 'str'>: '{'
[01:12] <StevenK> That's the error I'm getting from the BulkUpdate
[01:13] <StevenK> But searchable_versions = List(type=Unicode()) because type=StringCol() didn't look right
[01:13] <wgrant> BulkUpdate may not cope with lists
[01:14] <wgrant> You'll need to check
[01:14] <StevenK> Yeah, I'm about to dig in and see what UPDATE statement it is creating, but I wasn't sure if my List() defintion was sane
[01:17] <StevenK> Hmmm
[01:17] <StevenK> Perhaps it's my fault, since it's barfing over my values list
[01:23] <StevenK> [[<storm.variables.IntVariable object at 0xa39b050>, <storm.variables.ListVariable object at 0x88cc738>]]
[01:23] <StevenK> Well, that's very handy, storm. Thanks.
[01:25] <bigjools> there's something oddly satisfying about typing "dput -fu"
[01:25] <lifeless> bigjools: you need to get out more :)
[01:25] <wgrant> poppy deserves it
[01:26] <StevenK> wgrant: I think you might be right.
[01:26] <bigjools> lifeless: said without a trace of irony :)
[01:26] <StevenK> (Pdb) p values[0][1]._value
[01:26] <StevenK> '{0.9}'
[01:26] <StevenK> Me thinks a ListVariable wants something more list-like
[01:26] <bigjools> trevormosey must be really famous
[01:26] <wgrant> bigjools: Heh, yes
[01:27] <wgrant> There's a bug for that
[01:27]  * bigjools blames the dput ppa script
[01:27] <bigjools> putting in that ~ by default was a huge mistake
[01:28] <StevenK> That always trips me up too
[01:31] <wgrant> bigjools: Well
[01:31] <wgrant> bigjools: It probably comes from the ppa.launchpad.net HTTP layout
[01:31] <wgrant> That was the first place to drop the tilde
[01:31]  * StevenK doesn't like the thought of results[1][1:-1].split(',')
[01:31] <wgrant> StevenK: No
[01:31] <wgrant> StevenK: Perhaps try casting the array to a text[]
[01:32] <wgrant> See if psycopg2 interprets it then
[01:32] <wgrant> If you manually parse the array I will strangle you :)
[01:32] <StevenK> wgrant: You'll have to get in line behind me
[01:32] <StevenK> I will strangle myself first
[01:32] <bigjools> wgrant: that was also stupid :(
[01:32] <wgrant> bigjools: Certainly
[01:33] <bigjools> my fault, sadly
[01:33] <wgrant> Really?
[01:33] <wgrant> It was very early in your time...
[01:33] <bigjools> I had the opportunity to fix it when we added multi-ppas
[01:33] <wgrant> True
[01:33] <StevenK> wgrant: ARRAY[]::text[] == bang
[01:33] <wgrant> StevenK: Bang?
[01:33] <StevenK> If that's what you mean
[01:33] <wgrant> That seems like casting the empty array
[01:34] <bigjools> yeah it was early in my time
[01:34] <wgrant> Which will fail because you're trying to append it to a debversion[]
[01:34] <wgrant> Cast the entire result array
[01:35] <wgrant> Multi-PPAs would indeed have been the best time to add them
[01:35] <wgrant> Although I thought that feature was somewhat influenced by the initial implementation that was removed before PPAs were released.
[01:35] <wgrant> If I recall correctly from my bug...
[01:36] <StevenK> Hmmmm
[01:37] <StevenK> http://pastebin.ubuntu.com/1422367/
[01:37] <StevenK> Holy fuck, it works
[01:37] <StevenK> Perhaps I shouldn't be so surprised
[01:38] <wgrant> Oh, so my BulkUpdate hacks just worked with a list when the type was correct?
[01:38] <StevenK> wgrant: So it seems
[01:38] <wgrant> I'm disappointed
[01:38] <StevenK> I put the entire block in ()::text[]  which I thought was dubious at best, but worked
[01:39] <wgrant> Well, we're stuffing them into a text[] column in the end, and we don't want to perform version comparisons on them
[01:39] <wgrant> So it's the right thing to do
[01:39] <StevenK> wgrant: Right, but I've not had to do manual casting in postgres before, so I was guessing
[01:40] <wgrant> Ah
[01:40]  * StevenK ponders commiting evil on DF
[03:07] <StevenK> wgrant: Didn't we have a PQM check that you couldn't modify anything outside database/ in a DB branch? Or did that die?
[03:35] <wgrant> StevenK: Sometimes you need to modify tests and similar
[03:35] <wgrant> We rely on people thinking about deployment
[04:12] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/improved-html_escape/+merge/138902
[04:13] <StevenK> 52-56 can be done without my eyes bleeding, surely?
[04:13] <wgrant> Not really.
[04:13] <wgrant> How?
[04:14] <StevenK> Looping over replacements?
[04:15] <wgrant> Mmm, it'll be slightly shorter.
[04:17] <StevenK> wgrant: What about invalid unicode for line 51?
[04:17] <wgrant> (or longer)
[04:17] <wgrant> StevenK: It's hideous but I didn't change it
[04:17] <StevenK> So you didn't
[04:17] <wgrant> We assume that all messages are a unicode or an ASCII bytestring.
[04:18] <StevenK> Because WCPGW, right?
[04:18] <wgrant> No
[04:18] <wgrant> Because what else can you do?
[04:18] <StevenK> Well
[04:18] <StevenK> Be sane
[04:18] <wgrant> It's a reasonable assumption, and it will crash if it's not valid
[04:18] <wgrant> Which is all that it's reasonable to do
[04:19] <StevenK> % bzr grep 'import cgi' | wc -l
[04:19] <StevenK> 30
[04:20] <StevenK> I guess they're next on the chopping block?
[04:20] <wgrant> Indeed
[04:20] <wgrant> But it's a big diff
[04:20] <wgrant> So it's a separate branch
[04:20] <wgrant> two weeks ago I moved this stuff into its own module
[04:20] <wgrant> This branch makes it usable generally
[04:20] <wgrant> The next two branches eliminate the other four escaping mechanisms
[04:21] <StevenK> wgrant: r=me
[04:21] <wgrant> Thanks
[04:22] <StevenK> wgrant: Adding "I will be destroying all other escaping mechanisms in terms of LoC gain in a future branch" would have been nice, but meh
[04:59] <StevenK> Dear mawson, where does it hurt?
[05:02] <wgrant> Well
[05:02] <wgrant> that's a few more test failures than I expected
[05:02] <StevenK> On buildbot?
[05:02] <wgrant> Yeah
[05:02] <wgrant> 110 or so
[05:02] <wgrant> Mostly due to apostrophes
[05:02] <StevenK> Oh yes, aren't you a naughty boy
[05:21] <StevenK> wgrant: You're working on the 111 bad tests?
[05:22] <wgrant> Yes
[05:22] <StevenK> wgrant: How do you feel about reviewing my +298,-60 garbo branch? :-)
[05:22] <wgrant> I may end up reverting, but I suspect I'll be able to fix the tests before anyone else wants to land stuff
[05:22] <wgrant> Maybe :)
[05:22] <StevenK> It depends on 40-1 being deployed before it can land, but I can work on making it wgrant-approved first
[05:28] <StevenK> 2012-12-10 05:28:29 DEBUG2  [PopulatePackageUploadSearchableVersions] Iteration 591 (size 2155.0): 5.698 seconds
[05:28] <StevenK> Daaaaaaaaaaaamn
[05:31] <wgrant> Right, no trigram indices and the rows should be much smaller :)
[05:31] <wgrant> Trigram indices are awful
[05:31] <wgrant> So they should only be used where necessary
[05:32] <StevenK> I am incredibly curious just how long it will take to create the index on DF when the columns are fully populated
[05:32] <wgrant> Yeah
[05:32] <StevenK> wgrant: They're awful for performance? But in this case good for searching performance?
[05:32] <wgrant> You'll probably want a GIN index on the searchable_versions
[05:33] <wgrant> StevenK: They perform awfully in all respects
[05:33] <wgrant> They're just less awful than a seq scan when doing a substring match
[05:33] <wgrant> That's the only respect in which they have any value
[05:34] <StevenK> Oh. So they're totally awful, but they're best we have for the problem.
[05:34] <wgrant> Right
[05:34] <wgrant> And it's not feasible to get much better
[05:34] <wgrant> It's a hard problem
[05:34] <wgrant> So it should be avoided
[05:34] <wgrant> By not supporting substring matches unless it's unavoidable
[05:38] <StevenK> wgrant: I don't have branches for the indicies yet, only a diff that gives me the TGRM for searchable_names
[05:39] <wgrant> Right
[05:43] <StevenK> wgrant: Hmmm, since searchable_versions is TEXT[], can I ask for rows where that column has more than one value?
[05:43] <wgrant> StevenK: Why do you want them?
[05:43] <StevenK> wgrant: Curosities sake, not for code
[05:44] <StevenK> Was wondering if there was a short cut
[05:44] <wgrant> a GIN index won't do that for you. You'd have to index array_length(searchable_versions) directly to do that efficiently.
[05:45] <StevenK> wgrant: You misunderstand. I only want to check rows on DF manually, not in the code at all
[05:45] <wgrant> Ah
[05:45] <StevenK> However WHERE array_length(searchable_versions) > 1 will probably work then
[05:45] <wgrant> WHERE array_length(searchable_versions) > 1?
[05:45] <wgrant> Yeah
[05:46] <StevenK> ERROR:  function array_length(text[]) does not exist
[05:46] <StevenK> ... but it's an array, you still DBMS?
[05:46] <wgrant> Oh
[05:46] <StevenK> s/still/silly/
[05:47] <wgrant> array_length(searchable_versions, 1)
[05:47] <wgrant> Needs a dimension
[05:47] <wgrant> (and it's 1-based, because who needssanity)
[05:48] <StevenK> Database developers are all insane, anyway
[05:56] <wgrant> blarfgghergherger
[05:56] <wgrant> manual escaping ftl
[05:56] <wgrant> some of these errors have been being double-escaped for years
[06:19] <wgrant> Applause
[06:20] <StevenK> Hm?
[06:20] <wgrant> Well
[06:20] <wgrant> LaunchpadValidationError is used by lots of fields
[06:20] <wgrant> It HTML-escapes all errors pushed through it, so you can push through markup if you need to
[06:21] <wgrant> But the fields are also used by eg. XML-RPC and email interfaces
[06:21] <wgrant> Where HTML-escaping is not right
[06:21] <wgrant> This has historically gone largely unnoticed, as only <, >, & were escaped globally
[06:21] <wgrant> And they're relatively rare characters
[06:21] <wgrant> s/And/As/
[06:22] <wgrant> For now I'm going to take the easy way out and change the error message to not contain an apostrophe...
[06:22] <wgrant> :)
[06:24] <StevenK> Naughty
[06:24] <wgrant> I try.
[06:28] <nigelb> TMI.
[06:41] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/populate-searchables-for-pu/+merge/138906
[06:52] <wgrant> 17 to go...
[06:53] <StevenK> Failures?
[06:53] <wgrant> Yes
[06:54] <wgrant> Ooh
[06:54] <wgrant> A real bug, finally
[07:02] <wgrant> 1920 lines of diff later and all but three should be fixed...
[07:06] <StevenK> Haha
[07:06] <StevenK> That's going to be fun to review
[07:08] <wgrant> StevenK: Do you perhaps want to split the garbo job into a separate branch?
[07:08] <wgrant> So it can be more easily reverted later
[07:08] <wgrant> And to make it easier to review
[07:09] <wgrant> (also, I'd say "addSearchableName" rather than "appendSearchableNames")
[07:11] <wgrant> addBuild is hideous; pls rewrite
[07:11] <wgrant> appendSearchable* will want to check that the given string isn't already in there
[07:12] <wgrant> It's probably best to parse the string into a set, then add the new names and reserialise
[07:14] <StevenK> wgrant: I can split out the two garbo jobs if you wish, but they're very well contained
[07:14] <wgrant> This is true
[07:14] <wgrant> They could also use a comment or two :)
[07:14] <StevenK> They have two each, I though?
[07:14] <StevenK> Well, the tests do. :-)
[07:14] <wgrant> Doesn't seem to
[07:14] <wgrant> It's just;
[07:14] <wgrant> MASSIVE BLOB OF THE MOST HIDEOUS SQL KNOWN TO MAN
[07:15] <wgrant> MASSIVE BLOB OF STORM MOLESTATION
[07:15] <wgrant> fin
[07:15] <wgrant> :)
[07:15] <wgrant> Although I guess they'll be gone soon
[07:15] <StevenK> s/BLOB/TEMPORARY BLOB/
[07:15] <StevenK> wgrant: I'm quite proud of the two SQL statements we cooked up.
[07:15] <wgrant> Speaking of which
[07:15] <StevenK> They are HIDEOUS and eat babies, but they work and are performant
[07:15] <wgrant> Why not do them both at once?
[07:16] <wgrant> THey're going to be rewriting the same rows
[07:16] <wgrant> Might as well do it in one hit
[07:16] <StevenK> wgrant: Because I went to change the SQL statement in Populate...SearchableNames and it nearly bit my hand off
[07:17] <wgrant> You should just be able to keep the two expressions separate, but in the same findspec.
[07:17] <StevenK> Mmmmm
[07:20] <StevenK> Right, so your complaints are: addBuild is terrible, and I should fix it, appendSearchable* should be renamed and parse the existing values if any to a set and then add the new bits, the garbo jobs should be put on a diet, IE, from two to one, and the new one could use some comments?
[07:21] <wgrant> Right
[07:21] <StevenK> Anything else?
[07:21] <wgrant> The comments are going to be useful for people wanting to write similar garbo jobs in future
[07:21] <wgrant> It otherwise looks sensible
[07:21] <StevenK> Except the comments will die shortly
[07:21] <wgrant> Though the bit that sets searchable_* from the PCJ could do with a comment saying the rest will be added when the PU. is added
[07:21] <wgrant> StevenK: Sure, but they'll be in history
[07:22] <StevenK> Perhaps I should put the comments in the caching job?
[07:22] <StevenK> Since that is sticking around
[07:22] <wgrant> Perhaps so
[07:22] <StevenK> wgrant: The rest will be added when the PU is? EPARSE
[07:23] <wgrant> StevenK: The PU[SBC]
[07:23] <StevenK> I don't think we call any of the three add methods on a PCJ'd PU
[07:24] <StevenK> The binaries from any builds will get a new PU
[07:24] <wgrant> Is that method only used for PCJs?
[07:24] <StevenK> Yeah
[07:25] <wgrant> Indeed
[07:25] <wgrant> That's fine, then
[07:35] <nigelb> Ooh.
[07:35] <nigelb> I finally upgraded.
[07:35] <nigelb> This means I can setup LP in an LXC.
[07:36] <StevenK> Haha
[07:38] <StevenK> I guess "Warning: Permanetly added the RSA host key for IP address '<IP of taotie>' to the list of known hosts." means my laptop hasn't hit up LP for a long while
[08:49] <cjwatson> wgrant,StevenK: we don't have a use case for substring matching on versions in the upload queue, but we do have a use case for exact matching.  Are you preserving that facility, or are we going to need to perpetrate a workaround?
[08:49] <wgrant> cjwatson: Exact matching is easy and cheap and is being preserved
[08:50] <cjwatson> Excellent
[08:50] <wgrant> I will strongly resist any attempt to preserve substring matching :)
[08:50] <cjwatson> (That use case being "queue accept -e packagename/version")
[08:50] <wgrant> yep
[08:50] <cjwatson> Which reminds me, I should flip the -e default in the queue client, maybe after all this lands
[08:50] <StevenK> After I'm done, source='foo', version='bar', exact_match=False will do a substring match for foo, but an exact match for bar
[08:51] <cjwatson> That's fine for our needs, yes
[08:51] <cjwatson> And I think what we were expecting to happen anyway
[08:51] <StevenK> It doesn't right now
[08:51] <wgrant> exact_match=True should be the default everywhere
[08:51] <wgrant> If your client does not already, pls fix :)
[08:51] <cjwatson> I know, it only doesn't because:
[08:52] <cjwatson> (a) it was a translation of the LP script which was insane
[08:52] <wgrant> Heh
[08:52] <wgrant> Yeah
[08:52] <wgrant> LP has some bad history there
[08:52] <wgrant> eg. getPublishedSources, IIRC
[08:52] <cjwatson> (b) exact matching actually turns out to be quite inconvenient without SPN matching on build uploads
[08:52] <StevenK> cjwatson: I'll be fixing b
[08:52] <wgrant> Ah, indeed
[08:53] <cjwatson> Exactly, so I should be able to flip the default after this lands
[08:53] <StevenK> 'This'
[08:53] <StevenK> It's a mess of seven branches :-)
[08:53] <cjwatson> I scoff at your attempt to impose reality on my grammatical choices
[08:54] <StevenK> Hah
[09:05] <czajkowski> aloha
[14:01] <benji> I am going to assume that bcsaller is not in this morning and that we can clear up any remaining issues with his review of https://codereview.appspot.com/6909046/ later and land my branch.
[14:01] <benji> and I am going to talk about it in the wrong channel, is that cool with everyone?
[14:07] <rick_h_> benji: that's cool and I approve
[14:07] <benji> rick_h_: good, now I have an excuse for my crosstalk
[14:43] <gmb`> benji, Morning. Is there any reason for me to not mark BjornT's merge proposal for lp2kanban as approved so Tarmac can land it: https://code.launchpad.net/~bjornt/lp2kanban/bugs-to-cards/+merge/135909
[14:43] <gmb`> ?
[14:43] <benji> gmb`: not that I know if.  I believe it is good to go.
[14:44] <gmb`> Awesome.
[14:44]  * gmb kills the imposter
[14:45] <nigelb> Oh dear.
[14:48] <gary_poster> gmb, as a poster I find that concerning.  on another note, are you helping BjornT land his lp2kanban branch?  If not I can try to do so
[14:49] <gmb> gary_poster, I thought lp2kanban was all Tarmac goodness these days.
[14:50] <gmb> If not, then I'm happy to take care of it.
[14:50] <gary_poster> gmb, dunno, forgot.  I was going to try to add BjornT to whatever group he needed to be in in order to land the code...
[14:51] <gary_poster> looking to see what that would be...
[14:51] <gmb> gary_poster, ~launchpad.
[14:51] <gary_poster> oh :-/
[14:51] <gmb> (Well, that's who owns the trunk branch)
[14:51] <gary_poster> right
[14:51] <gmb> So I'll land it now.
[14:53] <gary_poster> ok thanks gmb
[15:05] <gmb> Wow, rocketfuel-get takes a while... Remind me, why did we write all this code/
[15:05] <gmb> ?
[15:08] <sinzui> gmb, that reminds me...
[15:09] <sinzui> gmb, gary_poster is there a rule to remove tarballs from lp-sourcecode deps? I went to remove a few last week, then panicked when I realised other projects (not ~launchpad) use it
[15:10] <gmb> sinzui, Really? Which projects?
[15:10] <sinzui> oops tools
[15:10] <sinzui> maybe others
[15:10] <gmb> Urgh.
[15:10] <gary_poster> sinzui, I know of no rule.  The proper solution has always been to not use a branch and instead have tarballs hosted somewhere internally and never delete anything.
[15:10] <gary_poster> yeah I think other projects too
[15:11] <gary_poster> Robert wanted them to be shared
[15:11] <gary_poster> This is an unintended downside, I think
[15:35] <gmb> bac, I've added a section for Green Squad to the lp2kanban config; can you update it on the Canonistack instance please?
[15:36] <bac> gmb: sure, in an hour or two.  on standup now
[15:36] <gmb> bac, Sure, that's fine. Thanks.
[15:37] <bac> gmb: actually the config should be added to lp-tarmac-configs project not lp2kanban
[15:37] <bac> gmb: the one in lp2kanban is an example only
[15:38] <gmb> bac, lp-tarmac-configs is the one I've updated.
[15:38] <gmb> Sorry, didn't make that clear.
[15:39] <bac> gmb: just for fun, you could login, poweroff, and then bin/startmeup.  would be nice for someone else to exercise that path.
[15:40] <gmb> bac, I would if I could remember to what I should ibe logging in.
[20:52] <jcsackett> benji: you have time to review https://code.launchpad.net/~jcsackett/launchpad/no-private-releases/+merge/139092 ?
[20:52] <sinzui> benji, do you have time to review https://code.launchpad.net/~sinzui/launchpad/person-owned-teams/+merge/139091
[20:53] <rick_h_> jcsackett: wins!
[20:53]  * jcsackett laughs
[20:54] <benji> jcsackett and sinzui: sure, but first you invoked the rarely used simultanious review smackdown
[20:54] <sinzui> I am wearing glasses
[20:55] <sinzui> You cannot hit a four-eyed developer even if he is complete an utter bastard
[20:55] <jcsackett> sinzui: i am also four eyed. i think that nixes it. :-P
[20:55] <jcsackett> however, i like sinzui. if i must hit him to be reviewed first, i'll wait to be second. :-P
[20:56] <rick_h_> ok, then sinzui must hit you to be reviewed first
[20:56]  * jcsackett laughs
[20:56] <rick_h_> there must be smack in the smack down
[20:56] <sinzui> how?
[20:56] <sinzui> I shall invoke the one-hand clapping smack
[20:57] <jcsackett> tell you what. sinzui can drive down hear to smack me. in the meantime, benji can review my branch. :-P
[20:57] <jcsackett> s/hear/here/
[20:57]  * sinzui claps
[20:57] <benji> heh
[20:58]  * sinzui has pulled a muscel and may have broken a nail
[21:05] <benji> jcsackett and sinzui: both of your branches are reviewed.  I won't tell you which I did first.
[21:05] <sinzui> thank you benji
[21:05] <benji> my pleasure
[21:06] <jcsackett> thanks, benji.
[21:06] <benji> any time
[21:12] <lifeless> OOPS-3de41986b624ef0f542b92653ce1cfe8 <- ?
[21:14] <sinzui> lifeless, timout inserting a bug. looks like a row lock
[21:14] <lifeless> \o/
[21:14] <lifeless> bugs 1088650 and 1088651 appear either private or missing, to me
[21:15] <lifeless> I tried again and got ...2
[21:17] <sinzui> lifeless, I can see the first, not the second, and I don't have power to confirm if the private-is-404 rule
[21:17] <lifeless> interesting, cool.
[21:18] <lifeless> I am suffering cat-in-lapsy
[21:18] <lifeless> it is very distracting
[22:05] <wgrant> deryck: Hi
[22:31] <deryck> hi wgrant
[22:32] <wgrant> deryck: I see that a couple of your DB changes have model changes as well.
[22:32] <wgrant> That's forbidden because we can't confirm it's safe (we don't deploy DB and app changes at the same time)
[22:32] <wgrant> In particular, one of your branches makes a column not null at the same time as it sets a default in the model.
[22:32] <deryck> wgrant, I don't think my revs do.  but maybe abel's does.  I didn't look at his honestly, sorry.
[22:32] <wgrant> Ah
[22:33] <lifeless> 'royal your' :P
[22:33] <wgrant> Well, yes :)
[22:33] <deryck> wgrant, ah, no that is mine.  I checked with stub and thought it was cool.
[22:33] <deryck> wgrant, we already protect against in the model, and I did some query checks to make sure we were safe.
[22:35] <wgrant> zAh
[22:35] <wgrant> It's actually safe, because there's a default in the DB
[22:35] <wgrant> But we forbid model changes in the same branch to avoid any confusion
[22:35] <wgrant> And ensure that the devel code and db-devel DB can coexist
[22:35] <wgrant> Rather than having to reason about it manually
[22:36] <deryck> wgrant, ok, sorry about that. I assume it's okay to deploy this time, so long as I don't do it again? :)
[22:36] <wgrant> Indeed.
[22:36] <deryck> ok, thanks.  sorry again.
[22:36] <wgrant> abel's branch is also OK to deploy, but it's unnecessarily mixing DB and app changes, so it has to be manually verified.