18:04:34 #startmeeting 18:04:34 Meeting started Thu Oct 6 18:04:34 2011 UTC. The chair is pitti. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot. 18:04:34 18:04:34 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 18:04:45 #topic recruiting new members for the ARB 18:05:42 I admit I haven't read it yet, shall we allow some minutes to read/digest it? 18:05:46 (release crunch, sorry0 18:06:57 I've always found the lack of a requirement to be a developer troubling. 18:07:23 ScottK: "evidence of activity" isn't really as strong as _being_ a developer 18:08:11 I find that a bit troublesome as well; being able to spot problems in these packages requires at least some packaging experience 18:08:28 we've talked about that, in the current group, and generally assume that we will make it a requirement in the future, so for this cycle we looked for applicants who are Ubuntu developers 18:08:39 hopefully this will be ensured by the voting/application process, but perhaps it could be made explicit? that an applicant should at least be a PPU? 18:08:41 I find it particularly troubling given it's enabled in the default install. 18:10:05 pitti: member of ~ubuntu-dev should match all PPU/MOTU/Core-dev (unless we forgot to add some members to that team) 18:10:18 the only reason we haven't already made it a requirement, is that we're unsure how to handle the fact that half the current ARB aren't Ubuntu Developers, and we're already hurting for bodies 18:10:26 aside from that the proposal seems straightforward and clear to me 18:10:48 but, we could make it a requirement now, with a transition plan 18:11:04 wendar: is that becuase these members aren't generally interested in Ubuntu packaging? do they want to become ubuntu devs? 18:11:15 I certainly do :) 18:11:28 I'm pretty sure the other ARB member does too 18:12:07 how about making it policy now, but allow for existing members to be allowed with the stated intention that they are working towards dev? 18:12:20 I'm fine with that. 18:12:38 sounds good 18:12:39 the requirements to these packages are quite a bit different to 'ordinary' packages, with /opt and all that, but one should at least be familiar with packagign basics 18:13:02 kees: that sounds good; I certainly don't intend to invalidate the current board 18:14:09 so the proposal is 18:14:12 - Ubuntu membership 18:14:20 + https://launchpad.net/~ubuntu-dev membership 18:14:29 * kees nods 18:14:51 Is Ubuntu membership required for PPU? 18:14:59 stgraber: WDYT? 18:15:19 pitti: +1 18:15:36 As long as Ubuntu membership is required for PPU, I think that's good. 18:16:01 ah, I'm fine with making that explicit and just have both requirements 18:16:15 ScottK: technically I think ubuntu membership is a consequence of being in ubuntu-dev 18:16:16 also, all 3 current applicants we (as in ARB) have on our list are members of ~ubuntu-dev 18:16:34 Hmm, i thought PPU was an avenue to get membership? 18:16:38 but I'm not entirely sure whether the DMB requires that as a prerequisite, or grants it together with PPU 18:16:39 (via ~ubuntu-dev?) 18:17:02 IIRC we (as in DMB this time) simply grant it by giving PPU 18:17:13 that was my impression, too 18:17:15 Not a point worth spending a lot of time on then. 18:17:37 wendar: so, are you okay with adding ~ubuntu-dev membership as a requirement? 18:17:45 yup, reload the page 18:17:58 wendar: heh, says ~ubuntu-de 18:18:14 I'm afraid teaching everyone to speak German is a little too much effort 18:18:21 :) 18:18:25 edited again 18:18:33 thanks 18:18:43 #vote TB signoff of https://wiki.ubuntu.com/AppReviewBoard/Restaffing 18:18:43 Please vote on: TB signoff of https://wiki.ubuntu.com/AppReviewBoard/Restaffing 18:18:43 Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me) 18:18:47 +1 18:18:47 +1 received from pitti 18:18:48 +1 18:18:48 +1 received from kees 18:19:35 stgraber: ? 18:19:45 +1 18:19:45 +1 received from stgraber 18:20:22 we only have bare minimum quorum today, but my feeling is that this is pretty unanimous 18:20:25 (sorry, was looking through the list of ~ubuntumembers) 18:20:33 #endvote 18:20:33 Voting ended on: TB signoff of https://wiki.ubuntu.com/AppReviewBoard/Restaffing 18:20:33 Votes for:3 Votes against:0 Abstentions:0 18:20:33 Motion carried 18:20:47 I'll reply on the TB list, and other TB members can then weigh in 18:20:49 wendar: thanks! 18:21:04 thanks all! 18:22:14 #topic next chair 18:22:28 we usually follow alphabetically, which would be soren 18:22:33 alphabetically? yup. 18:22:40 but as he hasn't been in any meeting yet, I propose that we skip him this time 18:22:58 stgraber: ready to chair the next one? :) 18:23:06 sure 18:23:07 stgraber: do you want to chair the next one? I can guide you to what to do after the meeting 18:23:15 pitti: that'd be great 18:23:17 heh 18:23:33 oh, these hundreds of hours on the typewriter and pasting stamps 18:23:52 #topic AOB 18:24:05 nothing else from me; stgraber, kees, wendar, ScottK? 18:24:13 Nope. 18:24:15 nope 18:24:29 nope 18:24:29 Not unless you want an off the cuff sru exception request 18:24:58 I'd like to keep uploading postifx bug fixes post-release, but didn't have time to prepare anything. 18:25:23 pitti: nothing from me 18:25:38 This is the upstream that says, "We don't have a bug tracker because we don't leave known issues unfixed." and does it. 18:25:40 ScottK: is there usually something in them which goes beyond a mere aggregation of individual "we want these" fixes? 18:26:06 #topic postgres SRUs 18:26:09 erk 18:26:13 #topic postfix SRUs 18:26:15 silly autofingers :) 18:26:29 Yes. There's two primary upstream developers who have a strong vision for the product. 18:26:58 Most bug reports turn into "Where in the documentation does it promise it's supposed to work that way?" 18:27:06 one thing that we need to fix there first are the eternal debconf questions on upgrade which potentially destroy your config (haven't checked, I always just say "no config") 18:27:14 So it's very strongly spec'ed. 18:27:14 Shouldn't lamont be in this discussion? 18:27:23 lamont and I have discussed it. 18:27:46 pitti: I don't recall those being an issue in a long time (I don't get the questions) 18:27:55 ScottK: so do you think the problem is that there are changes which are debatable, or that the problem is on the validation side? 18:28:12 ScottK: oh, wow; maybe I should file a bug then, I get them everytime 18:28:36 Users have an expectation of how an MTA should work and they are often wrong. 18:29:01 Post-release, postfix sticks to not changing functionality based on it's extensive documentation. 18:29:15 They are very, very picky about it. 18:29:57 i. e. you want to establish a permanent microrelease exception for postfix? 18:30:02 Yes. 18:30:14 If they are happy with it, it is very safe for us. 18:30:14 I would support that 18:30:34 so I assume this is for not verifying all changes individually, but have a way to regression-test the entire update 18:30:58 Upstream regression tests the upstream code before releasing. 18:31:01 kees: how much coverage does the qa-regression-test bzr have for postfix? 18:31:19 I think we need to mostly make sure the packaging works and there's nothing major wrong. 18:31:24 pitti: it's fair, let me double check 18:31:24 we still need some amount of testing the actually installed package, to guard against misbuilds, packaging errors, etc. 18:31:27 pitti: every regression I have seen in a micro-release update of postfix has been introduced by the debian/ubuntu packaging 18:31:33 I've been backporting postfix for a long time and I've never had an issue. 18:31:45 lamont: yes, that's what I'm concerned about :) 18:31:59 ScottK: I've never had an issue with Wietse's work. my own is the only concern 18:32:08 we had the weirdest things in SRUs, no-change uploads breakign completely, and the like 18:32:09 That's generally obvious in the normal level of SRU testing we do. 18:32:12 pitti: fwiw, that has usually been me adding in my own other bugfixes and getting it wrong 18:32:28 when I just grab the latest upstream and stuff, it's always been beauty 18:32:32 pitti: mostly it tests authentication mechanisms and basic delivery/forwarding 18:32:49 My view is that if that works, it's 99.9% good. 18:32:56 kees: qa-regression bzr is integration testing on the actually installed .debs, right? 18:33:07 pitti: correct 18:33:24 kees: is there any existing wiki documentation how to run this? or do we need a special page for postfix? 18:33:27 pitti: it expects packages to be installed, but does its own configuration manipulations to attempt various auth methods and delivery methods 18:33:37 if we could just link to it on the MRE page, that'd be good 18:34:00 pitti: there is no general docs on running the tests, no, but there is a pretty common methodology to it, and each test is documented on how to run it in the header comments 18:34:24 I've never had a problem figuring them out from the comments. 18:34:25 I'm using postfix both on server as well as on my workstations, and never really had a problem with it except those annoying debconf prompts, I'm fairly convinced of its quality 18:34:41 kees: right, I mostly mean where to get it, how to run it, etc. 18:34:57 as long as the proposer of the SRU (lamont/ScottK) know how to run it, it's fine for me 18:35:03 lamont, ScottK: ^ do you? 18:35:12 I know how to tell ScottK to run it. 18:35:15 http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/test-postfix.py 18:35:21 I didn't run the postfix one before, but I run the clamav one all the time. 18:35:26 I'm sure it's not an issue. 18:35:30 my gut feeling is that an MRE is fine, provided that validation entails running the upstream regression tests (which already is done by upstream), and the existing integration tests 18:35:37 lamont: delegation FTW! 18:36:49 pitti: to be fair, my normal approach to postfix is to take the latest upstream, build it, install it, send email, and upload. If I actually do any work, that's when I get all pedantic about testing it, ever since I broke it that one time 18:36:54 ScottK: is there a pending microrelease which we would SRU? 18:37:04 yes. 18:37:21 There's a backports request pending that we'd direct at -proposed instead. 18:37:35 so perhaps we could do this as a model case, see how much changes these carry, and how validation works, etc. 18:37:43 * kees nods 18:37:49 sounds good 18:38:16 but in general I'm fine with this proposal; upstream's stable policy and regression testing is certainly appropriate for our SRU criteria 18:38:38 It would be -proposed for natty only. 18:38:52 Lucid/Maverick released with 2.7, so those will still go to backports. 18:38:56 ah, no 2.7.x updates any more? 18:39:10 There are some of those I'll need to go back and look at too. 18:39:12 then I'm even less concerned 18:39:29 most postfixes which really matter certainly run on LTSes 18:39:33 No, we can do them too, just referring to the current backport request. 18:39:43 but doing this on natty now gives us a nice trial period for precise 18:39:58 So we'd keep 2.7 up to date in -proposed for lucid and 2.8 in backports. 18:41:37 ScottK: can we try that SRU once, and when it's done, come back to TB and discuss the general MRE when we all have more experience how that worked? 18:41:50 OK. 18:42:13 I'm sure it will be okay, but I'm a bit uncomfortable with saying "+1" before seeing it in action 18:42:19 might just be me being a wimp, of course 18:42:27 kees, stgraber: WDYT? 18:42:54 right, I prefer SRU history, then MRE 18:43:03 I'm signing up for reviewing that SRU 18:43:08 but this looks to be a good trajectory 18:43:19 I'm fine with this. 18:43:31 nice 18:43:55 trying with one SRU osunds good 18:44:08 *sounds 18:44:31 #topic AOB 18:45:01 going once.. 18:45:35 going twice.. 18:45:54 sold! 18:45:58 thanks everyone, have a good night! 18:46:03 thanks pitti! 18:46:09 will send notes / update report. etc. now 18:46:12 #endmeeting