21:00:05 <cjwatson> #startmeeting 21:00:05 <meetingology> Meeting started Mon Feb 4 21:00:05 2013 UTC. The chair is cjwatson. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 21:00:05 <meetingology> 21:00:05 <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired 21:00:13 <stgraber> yeah, he then forwarded the e-mail with the right address 21:00:21 <cjwatson> Agenda: https://wiki.ubuntu.com/TechnicalBoardAgenda 21:00:26 <cjwatson> Who's here? 21:00:28 <kees> \o 21:00:36 <stgraber> o/ 21:00:38 <smoser> o/ 21:00:41 <pitti> me too 21:00:48 * smoser is standing in for roaksoax 21:01:07 <cjwatson> Thanks. Will just wait a minute for any latecomers ... 21:01:26 <pitti> I met mdz at FOSDEM yesterday, he's presumably still travelling 21:01:42 <cjwatson> Ah, yes, that would make sense 21:02:01 <cjwatson> #topic Action review 21:02:06 <cjwatson> None that I can see from the last minutes 21:02:10 <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-January/001007.html 21:02:27 <cjwatson> #topic MAAS SRU 21:02:43 <cjwatson> I followed up by mail a few minutes ago 21:02:52 <pitti> FWIW, I found slangasek's reply quite on-the-spot 21:03:02 <cjwatson> Me too. I understand that Steve's recommendations are already being implemented? 21:03:25 <cjwatson> (In fact, perhaps we should record the general principles he outlined somewhere more permanent) 21:03:25 <smoser> cjwatson, hm... could you forward me your response? archive is not udpated, an di'm not subscribed. 21:03:26 <pitti> I agree with bundling newer versions and new packages into the new maas 21:03:30 * kees nods 21:03:39 <cjwatson> smoser: It wasn't anything interesting, just concurrence with Steve and otherwise general approval 21:03:51 <smoser> yeah, we're perfectly fine to package the bits inside maas. 21:03:56 <pitti> the three django fixes should be properly SRUed, though (at least at first look) 21:04:37 <smoser> pitti, we're open to that. 21:06:23 <cjwatson> I notice that ScottK has rejected bug 1081391 and bug 1081388 from the SRU queue 21:06:26 <ubottu> bug 1081391 in python-django (Ubuntu) "[SRU] Backport GenericIPAddressfield from 1.4" [Undecided,Fix released] https://launchpad.net/bugs/1081391 21:06:27 <ubottu> bug 1081388 in python-django (Ubuntu) "[SRU] Backport prefetch_related from 1.4" [Undecided,Fix released] https://launchpad.net/bugs/1081388 21:06:28 <smoser> ScottK raised concern with some of the django changes, suggesting that furthre review (done here) was necessary. so surely he'd be OK with that. 21:06:30 <stgraber> I'm also happy with the proposal with slangasek's proposed changes. Personally I'd tend to prefer having yui3 and python-tx-tftp as new sources rather than bundled in, but I'm not an SRU team member and I can live with those sources being bundled. 21:07:12 <stgraber> (I have a vague interest in that new tftp module for python which I may want to use for some projects I'm involved with, and having it in the archive for 12.04 would be convenient. I don't care much about yui3 though.) 21:07:13 <cjwatson> I find it difficult to disagree with his review on the face of it. Is it possible to work around the django problems in maas? 21:07:22 <pitti> bundling them exposes them less to other "unintended"/unsupported usage, though 21:07:52 <cjwatson> (And it is *definitely* true that the test cases in those bugs were incomplete.) 21:08:16 <cjwatson> At the very least they'd need much more regression testing. 21:08:19 <stgraber> pitti: right, the main advantage of just bundling them is that they will be able to push newer features or API changes to those in future SRUs. Which we wouldn't allow if those were individual sources. 21:08:43 <stgraber> pitti: but if it's not likely to happen with those packages (and it doesn't appear it's), I'd prefer to have separate sources. 21:09:12 <smoser> stgraber, i think i personally prefer slangasek's suggestion of bundling them in. 21:09:26 <cjwatson> I'm not sure I know enough about django to be able to offer a confident review. It would be nice if somebody non-maas-related who knew django well could investigate. 21:09:35 <pitti> stgraber: I'd rather minimize the exposure of new packages, but I don't have a solid objection against introducing them as NEW ones, so I'm fine with letting the server team decide about that 21:09:55 * kees agrees with pitti 21:09:58 <cjwatson> If they really are non-invasive then it probably isn't worth the hassle of trying to move the fix around; but I would like to have an unbiased assessment of that. 21:10:08 <cjwatson> stgraber: I'd rather bundle too. 21:10:12 <smoser> cjwatson, i'd have to look further to see which of the django changes are required. 21:10:14 <stgraber> ok ;) As I said, I don't mind very much, I just have a vague interest in the tftp bit and it'd have the nice advantage of saving me an upload to my PPA, but that's about the extent of how much I care ;) 21:10:23 <slangasek> the maas package currently in precise depends on the external python-django package; so switching it to bundle now would seem to be a bit of a regression on that score 21:10:42 <cjwatson> Yes, I'm not currently offering an opinion on bundling or otherwise of django 21:11:04 <cjwatson> I'd like to have the smallest change with lowest risk; it's not clear at this point where that lives 21:11:22 <slangasek> while the python-django changes don't meet the letter of the SRU policy as ScottK says, it's not a wholesale backport or anything... I think the django SRU approach makes sense 21:12:09 <cjwatson> And for the record I think the "my way or the highway" approach evidenced in bug 1081392 is entirely inappropriate for a technical discussion in a bug report. 21:12:11 <ubottu> bug 1081392 in python-django (Ubuntu Precise) "[SRU] Include upstream fix for bug 15496" [High,New] https://launchpad.net/bugs/1081392 21:12:19 <cjwatson> (from the maas team) 21:13:30 <smoser> clearly that could have gone better. i dont think anyone would disagree. 21:13:54 <cjwatson> It may be the right thing to do, but let's try reasoning rather than assertion :-) 21:14:24 <slangasek> if the TB generally feels it's warranted to override the SRU policy here, I'm happy to dig into the details of the python-django SRU and assess it (as I have some familiarity with django) 21:15:05 <smoser> i can make sure the maas team offers help / guidance to slangasek there. 21:15:22 <pitti> my gut feeling is that these sound small enough to warrant an SRU exception, but it hasn't been made clear how these can be regression-tested 21:15:26 <cjwatson> I would like to have some notion of how we can regression-test this for other django users 21:15:36 <pitti> i. e. with prominent python-django rdepends 21:16:10 <kees> agreed. I only know the simplest of django uses, and I don't think that's sufficient. 21:16:11 <pitti> and it would be great if these two SRU bugs could get patches attached for review 21:16:13 <slangasek> pitti: I believe, but have not yet verified, that the new features don't change the behavior of existing code 21:16:24 <pitti> it's always easier to judge regression potential by looking at what actually changd 21:16:33 <slangasek> thats my recollection of the previous discussion around that SRU 21:17:21 <pitti> e. g. if that just adds a new function to the API, it'd be harmless 21:17:27 <pitti> which may very well be the case here 21:17:30 <stgraber> At least the addition of GenericIPAddressfield sounds to me like it could be done in the maas code without requiring shipping a whole copy of django, so maybe that's another way to get the feature without having to SRU new features into a stable release? 21:17:36 <cjwatson> Has GenericIPAddressField been security-reviewed (this is on a security boundary, right?)? Does it handle database migration? 21:18:24 <stgraber> I'm not terribly familiar with Django, but it sounds like this is just a convenience type which ends up being mapped to an int in the DB, so surely this can be done without patching the core? 21:18:24 * ScottK mostly felt django was a TB decision, not just ubuntu-sru. 21:18:29 <ScottK> If you're happy, I'm happy. 21:18:43 <cjwatson> I could see prefetch being suitable - it would improve perf for other users, presumably - but it's a fairly complex change I can't review 21:18:59 <smoser> stgraber, you're probably correct. i'm sure we can find some way to get the same functionality inside of maas. 21:18:59 * pitti feels he has too little data to decide whether he should be scared or happy 21:19:20 <cjwatson> If it's had qualified code review and has some kind of plan for regression-testing then I'd be OK with the prefetch change 21:19:21 <smoser> the ipv6 code there, just ends up taking the same path as other suggested chaanges. 21:19:40 <smoser> as to whether it should be shoved inside maas (and not available to others) or incorporated into sru for others to benefit. 21:19:43 <cjwatson> I guess I'm more or less agnostic about GenericIPAddressField 21:19:58 <cjwatson> "not available to others" shouldn't be a consideration we apply in SRUs, though 21:20:08 <cjwatson> Least-risk is pretty much an overriding criterion 21:20:10 <smoser> fair 21:20:19 <cjwatson> Same logic as yui3/raphael 21:20:27 <stgraber> right, prefetch seems way harder to keep inside maas, so I think this one may be fine for an exception provided sufficient testing and guarantee it won't affect existing code (that it's just an addition that only maas will use as far as packaged software goes) 21:20:29 <smoser> right. which is what i was trying to say. 21:22:47 <cjwatson> Any more comments? I'd be happy to hand off detailed review to slangasek's judgement 21:23:17 <smoser> only comment is that everyone involved is aware that this is not "traditional SRU" 21:23:40 <smoser> the overriding interst is in getting something useful to ubuntu users to live on 12.04. 21:24:04 <cjwatson> ScottK: FWIW (re 1081392) if you *wanted* to push for a wholesale update of owncloud on the basis that the old version is completely useless, I don't know that I'd be completely opposed; I actually wondered why nobody was doing that 21:24:26 <ScottK> It would have required backporting a bunch of other packages. 21:24:36 <kees> apologies, I have to run away early... 21:24:48 <ScottK> If it was just owncloud, that's the direction we'd have gone. 21:25:12 <cjwatson> maas was pretty immature in precise, which was a problem in itself at the time. Indeed, it's not a traditional SRU; but I can see the value in it. 21:25:20 <cjwatson> ScottK: Ah, fair enough 21:25:20 <stgraber> ScottK: and I assume those are big/complex enough that you couldn't get away with the same bundling game as MAAS? 21:25:21 <cjwatson> kees: thanks 21:26:54 <smoser> the maas and ubuntu server teams will do whatever is necessary to do this right. 21:26:55 <stgraber> anyway, for the actual discussion topic, I'm happy having this be a one-off thing for MAAS and I trust ~ubuntu-sru to enforce the rigorous testing this will require (especially for the django bits), so I'm happy having slangasek and the ubuntu-sru team do the review and have this move along 21:27:39 <pitti> yeah, I agree for MAAS itself; that's sufficiently a "leaf" package, and the rationale makes sense to me for an LTS 21:27:46 <cjwatson> Yep. Do we need a vote (is there any dissent), or shall we carry this by acclamation? 21:28:15 <cjwatson> kees sounded in general agreement 21:28:33 <pitti> to me it seems we by and large agree; we all want to see a regression test plan for django and maas itself, and bundle the others 21:28:36 <stgraber> I don't think I heard anyone being explicitly against it, we're really just discussing some of the implementation details which I'm sure the SRU team can take care of ;) 21:28:56 <cjwatson> OK, let's move on then; I'll distil this into the minutes 21:29:04 <smoser> thanks all. 21:29:06 <pitti> ScottK: I want to say thanks for following the proper process here 21:29:26 <ScottK> pitti: Thanks. 21:29:35 <cjwatson> I see nothing new on the list 21:29:46 <cjwatson> And no open bugs 21:29:49 <cjwatson> #topic AOB 21:31:23 <pitti> a quick FYI, no further responses to the brainstorm reviews 21:32:44 <cjwatson> Oh, hell, I haven't done mine yet 21:32:50 * cjwatson sticks that on kanban in an attempt to remember 21:33:12 <pitti> I'll send a followup reminder email 21:33:16 <cjwatson> also: 21:33:38 <cjwatson> #action cjwatson to amend SRU/MRE documentation to reflect slangasek's comments about bundling 21:33:38 * meetingology cjwatson to amend SRU/MRE documentation to reflect slangasek's comments about bundling 21:33:43 <cjwatson> if that's OK with everyone 21:33:52 <pitti> oh, thanks 21:33:59 <stgraber> yep, thanks 21:34:35 <cjwatson> going once 21:34:50 <cjwatson> going twice 21:35:42 <cjwatson> sold to the developer in the orange hat 21:35:44 <cjwatson> #endmeeting