[01:03] Tear down canonical.testing.layers.TwistedAppServerLayer in 3 minutes 0.938 seconds. [01:03] this seems excessive :( [01:03] probably swapped out [01:04] yeah [01:32] mwhudson: got a few minutes to talk about test strategy for a change I ahve [01:32] ? [01:34] thumper: sure [03:04] As what DB user do the tests run by default? [03:04] wgrant: launchpad [03:05] mwhudson: Ah. Thanks. [03:05] Hm. [03:53] * thumper gains even more dislike of the librarian for tests [03:53] Because it takes FOREVER to start up, or something more sinister? [03:53] singleton.slow. functional-not-unit. [03:54] or maybe because you have to commit all over the place when using it? [03:57] failed to shutdown in this instance [03:58] also for those other reasons, but in this particular time, for failing to die [04:01] that's a lot of reasons for hate between us [04:01] There are more. [04:21] * thumper EODs for dinner making [04:36] programming can be terrible some times [04:37] What's going wrong? [04:38] oh just zope.interface crap [04:38] Ah. [04:50] The librarian could be mocked for many tests - the transaction rules are well documented and the interface simple. Nobody has bothered though (since it is a per test-run cost rather than a per-test cost?) [04:52] stub: I think you mean stubbed (no pun intended) - Mocks are not suitable for keeping true to the transaction rules. [04:53] * wgrant tries to remember the URL to that stubs vs. mocks. vs. fakes thing that was around a while ago. [04:55] wgrant: all are test doubles; mocks assert a sequence of calls with seeded result values [04:55] Ah. [04:55] I can never remember which is which. [04:55] stubs are generally limited functionality doubles that do stuff [04:55] and fakes do even less [04:56] anyhow, the rule to remember is 'mocks do not meet contracts' - each and every test has its own mock, or they aren't actually mocks. [04:56] on the upside you can create a mock by decorating a realobject and recording the input/output sequence it sees. [04:57] which can be a good way to make mocks, and with a little glue, turn them on/off on a per-run basis [04:57] to let one validate that the mock hasn't altered test validity asynchronously. [05:01] it's on mumak.net somewhere i currently can't find [05:12] _so many_ places reference next_mirror_time :( [05:14] stub: hi [05:14] stub: we were just talking about you earlier [05:15] and mostly for lame, or at least non-intent revealing, reasons [05:15] Talking about me for lame and non-intent revealing reasons? O_o [05:17] I decided I can either do more crappy documentation in the 30min I'll be awake, start reading an article I need to do a presentation on, tweak my bot some, install stumbleupon and use it, or..... do nothing.... Problem is that none of them sound appealing [05:18] stub: I was asking about stu and thumper thought I was talking about you. But then we did talk about you and I realized we like the same kind of ice cream [05:19] stu flavoured ice cream? This is getting more dubious. [05:20] lol [05:21] * mwhudson eods [05:25] stub: Can you have a quick glance at http://pastebin.ubuntu.com/307257/ and tell me if i'm doing anything horrifyingly forbidden ? I'd really really like to get this in before 3.1.10, and need to discuss it with Soyuz people tonight. Basically, I need a way to restrict permissible source package formats by distroseries. This is it. [05:27] wgrant: We normally use a integer/enum instead of a string where there is a fixed set of allowed options, and strings for free text. I suspect 'format' is not free text and should be an enum. [05:29] wgrant: The table name sounds a little dubious, but that will shake out in discussions with soyuz. Is this table defining the formats that are allowed for a distroseries or the formats that have been used in a distroseries? [05:29] stub: Right, I wondered about that. But to be consistent, that would mean migrating a column (sourcepackagerelease.dsc_format) from a string to an enum too. [05:30] stub: It's the same scheme used for ComponentSelection and SectionSelection, but I will discuss it with Soyuz. It defines the formats allowed in a distroseries. [05:30] We are inconsistent in many places - if you are correct, adding a comment in comments.sql is fine rather than migrating the column now. We can't be as agile with the DB schema as we are with Python. [05:31] a string field might be fine in this case if it is 'whatever apt or tool x tells us' rather than some value Launchpad needs to actually understand. [05:31] All values in that column should currently be identical, but it still sounds messy. [05:32] It does have to be understood. [05:32] At the moment there is only one valid value. After my branch, there will be three, defining different sets of allowed files in the sourcepackagerelease. [05:33] The formats are defined by dpkg. [05:35] So in general with the Python code we want to avoid "if format == '1.0'" and instead have "if format == PackageFormat.WHATEVER" [05:36] If it turns out in discussion that a string is the right choice for this column, I'll want some vague justification. [05:36] But no babies will die either way. [05:45] What's the best way to do this? Define the DBEnumeratedType and then a dict mapping '1.0', '3.0 (quilt)' etc. to its items? Or does DBEnumeratedType have some builtin way to do this, like lazr.restful seems to use? [05:49] got an error to run > make schema [05:50] sridher: Which error? [05:52] http://paste.ubuntu.com/307272/ [05:52] sridher: Python 2.6 is not supported. [05:53] sridher: Only 2.4 (and nearly 2.5, but it's not merged yet) at this point. [05:53] ok thank you sir [05:54] sridher: Did you use the rocketfuel-setup script as described on https://dev.launchpad.net/Getting? [05:55] yes sir [05:56] i got error that "developer-dependency" package not found [05:56] sridher: Which version of Ubuntu are you using? [05:57] karmic [05:57] That should just work. [05:57] Try running rocketfuel-setup again. [05:57] ok sir [05:58] Package `launchpad-developer-dependencies' is not installed and no info is available. [05:58] apt-get update [05:58] ok [05:59] http://paste.ubuntu.com/307275/ [06:03] sridher: You have the launchpad PPA enabled (probably in /etc/apt/sources.list.d/launchpad-dev.list)? [06:04] yes sir [06:05] sridher: pastebin the output of 'apt-get update' [06:06] http://paste.ubuntu.com/307278/ [06:07] I do not know what the problem is. [06:07] Unless you are using something other than i386 or amd64. [06:07] iam amd64 [06:08] What is in /etc/apt/sources.list.d/launchpad-dev.list? [06:09] deb http://ppa.launchpad.net/launchpad/ppa/ubuntu karmic main [06:09] deb http://ppa.launchpad.net/bzr/ppa/ubuntu karmic main [06:09] That's fine. [06:13] is it work with python 2.4? [06:14] sridher: Yes. I presume you modified your copy to use python2.6 manually? [06:14] al-maisan: Morning. [06:14] good afternoon wgrant, how are things? [06:16] after getting an 2.4 error i changed /devel/Makefile version to 2.6 [06:16] al-maisan: Not too bad. Just finishing off my v3 source format branch. One thing I came across in the tests was that the 'absolutely-anything' upload policy doesn't accept PPA uploads -- do you know if this is deliberate? I need it to for my tests, and enabling PPA uploads in it doesn't break other tests in lp.archiveuploader. [06:16] But who knows what other tests might lurk elsewhere. [06:17] wgrant: I don't know off-hand but will take a look. [06:18] al-maisan: (this branch recently became very important, as Debian has started uploading 3.0 (quilt) sources) [06:18] wgrant: gotcha. [06:19] wgrant: would the importance be diminished in any way of we sunc'ed lucid from testing as opposed from unstable? [06:20] s/of/if/ [06:21] al-maisan: That would delay it by ten days at most, and with the current backlash it's unclear exactly what is going to happen to Lucid syncs. [06:21] wgrant: I see. [06:29] wgrant: re. the 'absolutely-anything' upload policy I find this snippet in AbstractUploadPolicy.rejectPPAUploads(): [06:29] """Reject uploads targeted to PPA. [06:29] We will only allow it on 'insecure' and 'buildd' policy because we [06:29] ensure the uploads are signed. [06:29] """ [06:29] wgrant: why would it be so important for PPA uploads to be signed? [06:29] al-maisan: Seems like absolutely-anything (only used in tests) should be safe, however. [06:29] http://paste.ubuntu.com/307284/ [06:30] al-maisan: I don't know. It works OK once I enable it in the policy, so the code is fine with unsigned uploads. [06:30] There is some special signature treatment with PPA uploads (stripping signatures from stored .changes), but that seems to handle a lack of signature fine. [06:31] wgrant: if the policy in question is only used in tests then I guess "It's better to beg forgiveness than ask permission" applies ;) [06:32] al-maisan: OK. Thanks. [06:48] Morning [06:49] Morning noodles775. [06:53] Hi wgrant :) [06:53] noodles775: Almighty RM, I need your advice. [06:54] thumper: your branch is rc-approved... (just in case you didn't see the email). [06:54] wgrant: for the v3sources? [06:54] noodles775: Right. Debian has started uploading them, so it's pretty important no. [06:54] +w [06:55] yep, definitely. But it's also the kind of thing that I'd like to have tested on dogfood thoroughly before r-cing, which means it might be best as a CP... but bigjools will be around later... [06:55] noodles775: The branches are pretty much done (save a conversion from a string to an enum in one place, which I'm finishing off now), but they're bigish. [06:55] Right. [06:56] But there are DB changes (safe) that are needed. [06:56] He'll be able to check your branch on df... [06:56] ouch [06:56] btw: Thanks so much for gettin in there and fixing those! [06:56] But assuming those get into 3.1.10, there are CPs required on Soyuz machines and appservers. [06:57] Plus somebody needs to get the new dpkg on the buildds and Soyuz machines... not sure who to talk to about that. [06:57] But lucid won't open for a few days, and the v3 packages can be survived without for a while, so that's not quite as critical as the DB changes. [06:58] right. Have you got a branch with the db changes ready for review? [06:58] Not on its own yet, as I need to convert a column to an enum. [06:59] There is a new table, plus some new enum values on SourcePackageFileType that will cause appservers to explode if they don't know about them. [06:59] appservers and builddmaster, that is. [07:01] OK. So assign the db changes to stub+jml, bigjools can take a look when he's in and plan the best course of action. [07:02] Will do. Thanks. [07:02] Thank you! [07:05] noodles775: Any recommendations for what to rename the table listing permitted formats by distroseries? I've currently called it SourceFormatSelection (because of ComponentSelection and SectionSelection), but I'm sure that's suboptimal. [07:07] wgrant: re-name? [07:07] noodles775: Well, to you it's just naming it. [07:07] :) === noodles775 changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.10 Release Critical - release manager is noodles775 (flacoste, BjornT)| I am Zero OOPS and So Can You! http://is.gd/4fkLl | PQM is OPEN | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/ === noodles775 changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.10 | PQM is release-critical Release Critical - release manager is noodles775 (flacoste, BjornT) | I am Zero OOPS and So Can You! http://is.gd/4fkLl | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/ === noodles775 changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 4 of 3.1.10 | PQM is release-critical only - release manager is noodles775 (flacoste, BjornT) | I am Zero OOPS and So Can You! http://is.gd/4fkLl | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/ [07:10] wgrant: SourceFormatSelection seems fine to me - if it's suboptimal, it's because of the other columns that you've based it on. The db reviewers will be in a better position to comment. [07:10] noodles775: Well, stub said to ask Soyuz... [07:11] wgrant: ah ok. so, as I said, SFSelection seems fine to me. bigjools will comment later I'm sure . [07:21] noodles775: ta [07:28] What's the Storm equivalent of an EnumCol? [07:29] StormMigrationGuide has that as an unanswered question down the bottom. [07:36] wgrant: I haven't used it, but http://twistedmatrix.com/users/radix/storm-api/storm.properties.Enum.html [07:36] gr, no, that's not a db enum. [07:37] Looks like it is. [07:37] I see it used for that purpose in PackageCopyRequest, with a utility to convert the DBET. [07:37] Great. [07:37] Thanks. [07:37] np. [07:40] noodles775: Looks like canonical.database.enumcol.DBEnum is what I actually want, as it supported DBETs directly. [07:41] wgrant: good to know. [07:41] wgrant: can you update the migration guide (if you haven't already). Thanks! [07:41] noodles775: Will do. [08:23] good morning [08:25] Can I look up a DBItem given a DBEnumeratedType and the item's title? [08:26] Good morning adeuring [08:27] hi al-maisan! [08:37] wgrant: why not use the actual enum? Like PackagePublishingStatus.PENDING? (but you can do PackagePublishingStatus.getTermByToken('Pending') too?). [08:38] noodles775: I need to convert a string representation of a format from the .dsc (eg. '3.0 (quilt)'). [08:38] I'll try that. [08:38] Great. [08:38] I thought that would go the other way. [08:48] Oh, woops. Was wondering why my enum was throwing strange SyntaxErrors. Then realised the names started with digits. [08:48] FORMAT_1_0 rather than 1_0, perhaps? [08:58] wgrant: good , I hear you're working on https://bugs.edge.launchpad.net/soyuz/+bug/293106 [08:58] Bug #293106: does not support debian v3 source formats

[08:58] bigjools: Good morning. I am. Shall we discuss the plan? [08:58] please do [08:59] is it blocking anything in the distro that you know of? [08:59] I assume some v3 packages need to be synced now? [08:59] Not right now, but Lucid will open in a few days, and the first v3 packages have appeared in Debian. [08:59] Then it will be blocking things, although not critically to start with. [08:59] Now, the code is done and works. [08:59] ok can this bump to the 3.1.11 milestone? [08:59] I don't think it can. [09:00] massive changes 2 days before a release make me very nervous [09:00] However, if we get some safe bits in now, the rest can be CPed to Soyuz machines at your leisure. [09:00] /o\ [09:00] I love coming back from holidays! [09:01] All that needs to be applied everywhere is a new table, a few new SourcePackageFileType values, a trivial function on DistroSeries, and four lines in CopyChecker. [09:01] wgrant: what have you done to fix it? [09:01] The big invasive changes are only needed on cesium, germanium and cocoplum. [09:02] have you got a branch I can see? [09:02] https://code.edge.launchpad.net/~wgrant/launchpad/distroseries-source-format-selection has it all. I'm just finishing off a change recommended by Stuart. [09:02] and why can't it wait a month, do you expect a lot of v3 packages? [09:03] I don't know. But distro people were eeking about it, and Lucid will freeze very early. [09:03] I don't think anyone can say how many v3 packages will appear in the next month and a bit. [09:04] is there a workaround to sync them if we can't upload v3? [09:05] They should be convertible to 1.0 with a little effort, I guess. [09:08] wgrant: why the new table? [09:08] bigjools: To restrict which series can have the new formats. [09:08] why is that needed? [09:09] I don't know anything about the new format BTW :/ [09:09] bigjools: Only >= karmic's dpkg supports the new formats. [09:09] ok [09:09] So the old chroots will be very unhappy (and maybe chrootwait; I'm not quite sure) [09:12] could we control the source format selection w/o a schema change, at least initially? [09:12] i.e. by a piece of python logic that ascertains "Only >= karmic's dpkg supports the new formats" [09:13] You could hardcode the series name, I guess. [09:13] ew [09:13] Yes. [09:13] .. and clean up things in 3.1.11 [09:14] I'm not sure what that would buy us, it's still an invasive change [09:15] no question about that [09:15] but we'd at least avoid "last minute" db schema changes [09:16] Absolutely awful timing, I know, but Debian only revealed its intentions at the end of last week :( [09:18] I am still -1 on this going in unless someone from distro steps in and says it must [09:18] Right. [09:18] I'm talking to them now. [09:18] where "someone from distro" = cjwatson :) [09:19] this is a 4k diff branch - that's just insane to put in at this stage [09:19] err wait [09:19] diff fail [09:19] Last I checked it was 1.6klines [09:19] 1581 lines of diff [09:19] still a massive change [09:19] And a tiny fraction of that is needed *right now*. [09:20] But yes, it is big. [09:20] ok now I am diffing against db-devel :) [09:20] Ahaha. [09:20] That would do it. [09:21] wgrant: your sample data change changes the archive table, why? [09:21] bigjools: external_archive_deps change wasn't in there previously. [09:21] ah you can blame me for that [09:21] Yup :P [09:22] SourceFormatSelection is changing to an enum at the moment. [09:22] you're removing the table? [09:22] No. [09:23] It's just going to use an enum rather than a string for the format. [09:24] wgrant: from canonical.database.enumcol import DBEnum [09:25] bigjools: By that I mean I'm rerunning the tests after completing the change. [09:28] wgrant: what's different with the 3.0 format then? [09:29] bigjools: New types of files. [09:29] And massive incompatibility. [09:30] And new compression formats. [09:30] (although we're following dak and not supporting lzma, only gzip and bzip2, at cjwatson's direction) [09:31] lzma dropped entirely? [09:31] interesting [09:31] Right. Trivial regex change to bring it back if we need to. [09:31] (lzma deb support remains) [09:33] Oh. Curses. SourcePackageFormat already exists. [09:34] Any suggestions on what to call it? [09:35] SourceUploadFormat? [09:36] That's even more of a lie than the old SourcePackageFormat. [09:36] It's a property of the source package, and nothing really to do with the upload. [09:37] yeah [09:37] * bigjools -> OTP [09:38] OTP? [09:39] This #ubuntu-devel is going to get messy! [09:39] +discussion [09:43] (my best idea is to rename the old SourcePackageFormat to SourcePackageType or something like that, as it is only mentioned on 7 lines, but I guess that would get me even more murdered than I will anyway) [10:06] wgrant: ok back (On The Phone BTW) [10:06] bigjools: Oh, right. [10:06] wgrant: +1 on renaming SourcePackageFormat [10:07] bigjools: Great, 'cause I've done it. [10:07] heh [10:07] SourcePackageType ? [10:07] That's the one. [10:07] perfecto [10:07] one day we might even start using it for something useful and support RPM [10:07] Perhaps. [10:10] Hm. [10:10] FS corruption. [10:10] That is not good. [10:11] (product.py started complaining of SyntaxErrors, when I hadn't touched it. it is now full of garbage) [10:11] I wonder what else just got eaten. [10:14] ext4? :) [10:14] indeed. [10:14] But the file size changed. [10:15] So it's not the OMG KITTENS ARE DIEING BUT ONLY THREE PEOPLE HAVE REPORTED IT bug. [10:32] bigjools: Can I safely raise an UploadError in one of NU's error generators if I want to reject the upload and stop right there, or do I have to move the check to another function? [10:32] good question [10:32] * wgrant traces it all the way up. [10:32] suck it and see I guess [10:33] Just this last failure case to handle... [10:33] wgrant: EarlyReturnUploadError [10:34] bigjools: Ah, handy. Thanks. [10:34] (NU is too convoluted) [10:34] no kidding [10:35] it was refactored big-time a couple of years ago [10:35] I recall. [10:35] But that didn't get finished. [10:35] and it improved things a lot, if you can beloeve that [10:35] I cannot. [10:35] :) [10:35] Maybe I will revert the tree later and realise how lucky I am. [10:37] ahh, nascentupload [10:37] jml: You were privileged to be able to experience it before leaving engineering. [10:38] wgrant, indeed. [10:38] wgrant, I hope I made an improvement [10:38] * wgrant isn't touching those bits. [10:41] NU might not be so bad if it was properly tested, too. [11:00] Morning, all. [11:10] bigjools: OK, it seems that most of the rest of my FS survived. I've just finished off that change. [11:12] wgrant: most of? :) [11:13] bigjools: Well, I've only found that one eaten file. All the packaged files check out fine, my branches are fine, and fsck is happy, so I presume most of it is OK. [11:13] But it seems odd that there would be only file, given that I haven't written to it. [11:14] yes [11:52] bigjools: Broken sample data is currently being fixed :/ [11:53] wgrant: what's broken? [11:54] bigjools: There is a firefox-0.9.2.orig.tar.gz used in tests (note the '-' in place of '_'). That previously worked, as the type check just looked for endswith('.orig.tar.gz'). But now it uses a regex which needs a '_'. [11:55] wgrant: this is in the data/suite/* stuff? [11:56] bigjools: No, no. archiveuploader would never accept that. This is in a doctest that grabs an existing LFA and SPR.addFile()s. [11:56] ah ok [12:17] * wgrant directs significant volumes of hate at even more crackful sampledata. [12:29] jml, you seem to know a lot about rickspencer3's whereabouts. do you know where in the world is rickspencer3 today? [12:30] leonardr, if I had to guess, I'd say he's in the west coast of the continental united states of america. [12:30] hmm [12:30] i will hunt him down! [12:45] leonardr, I only half-followed your recent conversation with al-maisan -- is exposing a dict over the API really that tricky? [12:45] * al-maisan cocks up one ear [12:45] jml: it's never been done before. making the lazr.restful changes to expose a dict should not be *that* difficult [12:46] but al-maisan wanted to expose a dict _of lists_ [12:46] leonardr, why is that important? [12:46] Wasn't it a dict of Entries? [12:47] al-maisan can correct be, but i believe it was a dict that mapped a person to a list of strings [12:47] there are now two interesting branches of this conversation :) [12:48] leonardr, isn't a dict of lists a fairly standard json construct? [12:48] leonardr: actually it was a dict {pocket : object } .. let me check again [12:48] al-maisan, it was mapping a pocket enum to a branch object iirc. [12:48] that would be right [12:49] i don't remember this. i remember people mapped to the types of reviews they'd been assigned to [12:50] anyway, the problem is that the arguments to a named operation have to be described in wadl, and recursively defined data types are difficult to define in wadl [12:50] leonardr, ahh, I see. [12:50] a recursively defined data type is a sign that things are getting too complicated and you should rethink your resource design [12:51] leonardr, I can see the point [12:51] Ahhhh. Tests pass a little better when one of the data files used in a few tests *hasn't* been corrupted by a stupid filesystem. [12:51] as much as I like "for your own good"-style design. [12:51] *dislike* [12:51] (one of them Freudian mothers) [12:52] leonardr, jml: this is what I was trying at that time: http://pastebin.ubuntu.com/300148/ [12:52] jml: what i've said is kind of seat-of-pants stuff. my knowledge of that part of lazr.restful is cached on disk. [12:53] leonardr, heh === henninge is now known as henninge-lunch === Ursinha-afk is now known as Ursinha [12:54] somewhat literally, in that i would have to go into the code and re-learn it [12:54] leonardr: : so, the problematic part in this case was the return type of the collection returned. === noodles775_ is now known as noodles775 [12:55] anyway, since that did not work I resorted to: https://code.edge.launchpad.net/~al-maisan/launchpad/352094 === barry` is now known as barry [13:30] leonardr, I know the feeling. === bigjools is now known as bigjools-lunch === henninge-lunch is now known as henninge [14:17] What's a "package set"? [14:19] I see and , but they don't seem to mention what a package set is [14:20] mpt: https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#packagesetacl [14:20] ahh, security [14:20] thanks al-maisan [14:21] you are welcome :) [14:21] hey bigjools-lunch :) can you tell me what's exactly the meaning of the pending milestone you have in soyuz? after getting back from lunch, of course :P === bigjools-lunch is now known as bigjools [14:32] Ursinha: one word: "Celso" [14:32] bigjools, oh crap [14:32] bigjools, but do you know his rationale behind it? [14:32] Ursinha: it was a place for him to put stuff he didn't want to forget about [14:32] bigjools, I see [14:32] bigjools, you're not using it? [14:33] and it turned into a general pool of bugs that we need to sort out [14:33] sort of [14:38] bigjools, I see [14:39] bigjools, I asked because I have some bugs that are depending on others to be fixed, not our bugs, and as we don't have a Pending status I considered using a Pending milestone [14:39] Ursinha: as you know, things have changed focus recently so it's fallen to the side a little. But its general concept will be re-used for LP generally soon. [14:39] ah [14:40] go for it [14:40] cool [14:40] thanks bigjools :) [14:40] any time [14:44] bigjools: hi! I have this on my QA page from Francis. Am I right that I can push it over to your guys' page? "r9807 [r=adeuring][ui=none][bug=458833] Protect Build attributes using launchpad.Edit. (Landed on behalf of Julian.)" [14:45] gary_poster: yes please do [14:45] bigjools: cool thanks [14:49] gary_poster: are you going to stick it on my QA wiki page? [14:50] bigjools: sorry yes. Trying to reply to mthaddon on a nother channel then was going to do that. If you want to do it before me, feel free. ;-) [14:50] gary_poster: yeah I can do that, what's your test plan URL? [14:51] bigjools: thanks https://dev.launchpad.net/FoundationsTestPlan/3.1.10 [14:51] shoulda guessed that really :) [14:51] :-) [14:52] gary_poster: umm release yer edit lock :) [14:52] bigjools: sorry done [14:52] ta [14:52] done [15:13] bigjools: Have you a definitive answer from cjwatson? [15:13] wgrant: not definitive, but there's no clear requirement that I can see for putting this in 3.1.10 [15:14] wgrant: if the default dpkg format changes then he points out that we're fucked [15:15] bigjools: Right. And that was planned to happen. [15:15] But might not be any more... hard to tell. [15:15] bac: EdwinGrubbs: barry: I was able to test the product-release-finder. 1 bug is fixed, the other is not. I am going to work on the bad item [15:16] wgrant: did stub review your db changes [15:17] bigjools: He commented that the table name was a bit odd, but that it was a Soyuz decision, and also that it should use an enum rather than a string. [15:17] The latter is done, and you seem fine with the former. [15:18] wgrant: yeah it follows some convention I guess [15:18] wgrant: so I am thinking that we should land the schema changes only, in case the brown smelly stuff hits the fan this month [15:18] The cut down (that is, without the big archiveuploader changes) diff (excluding sample data) is ~500 lines. [15:20] sinzui: cool [15:20] wgrant: we don't even need that, we can just land the sql patch on db-devel [15:20] that's the thing that would stop a CP if it came to that, so this increases our options [15:21] True. [15:22] so if you can make a separate branch with that, create an MP, get jml and stub to review it, I'll land it for you === james_w` is now known as james_w === deryck is now known as deryck[lunch] [16:48]