19:02 #startmeeting Ubuntu Developer Membership Board 19:02 Meeting started Mon Jun 17 19:02:03 2013 UTC. The chair is tumbleweed. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 19:02 19:02 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 19:02 can someone else volunteer to chair if I have network trouble again / have to run off? I'll handle the minutes etc. 19:02 * barry can 19:02 thanks 19:02 #chair barry 19:02 Current chairs: barry tumbleweed 19:02 #topic Review of previous action items 19:03 barry to send outcome of sweetshark ppu vote 19:03 done 19:03 everyone read and amend http://pad.ubuntu.com/dmb-ppu-membership-proposal, and sign up for the implementation tasks 19:03 Laney: care to drive this? 19:03 rather micahg did if he's here 19:03 ah, of course 19:03 * stgraber waves 19:04 (sorry, just got out of another meeting, it's that kind of day...) 19:04 :( 19:04 ok, seems not 19:04 so I think we're all agreed on the principle 19:05 that we shouldn't always require membership contributions 19:05 err wtf 19:05 membership levels of involement from new developers 19:06 the remaining questions are about precisely where we should set the new boundaries 19:06 like: 19:06 - which, if any, packagesets should this apply to? 19:06 - should it be open to all PPU? 19:07 and there's questions about how to design the application procedure (should considering membership be implicit?) 19:07 Laney: i wonder if we can start small and just apply it to ppu and not package sets (although there may be some overlap, but ignore that for now) 19:07 ah, I think it's non-controversial enough that we can deal with it all at once 19:08 and one thing I thought of is that we should probably say that all devs need to have signed the CoC I suppose 19:08 * bdrung nods. 19:09 our membership-monitoring thing already enforces CoC for all uploaders IIRC 19:09 right, but that requirement is implicit because of membership 19:09 we just need to say it 19:09 barry: I don't see much of a point to distinguish between PPU and packageset as the concerns at least for me are similar. e.g. I'd be oposed to give PPU to xserver-xorg to a non-member just as much as I'd to give xorg packageset rights to a non-member. Packagesets indeed are just a level of abstraction on top of PPU, so the two should be treated the same way. 19:09 I would think that CoC needs to apply to uploaders as well 19:09 i don't think it's a controversial suggestion - the smallest tweak of the lot of them really ... 19:10 let's take the packageset question 19:10 it's a standard for interaction with the community, not just a prerequisite for membership 19:11 I saw we just treat packagesets as a convenience aggregating PPU together 19:11 well, that's one type 19:11 but there are 'flavour' packagesets which are somewhat different 19:11 right, that's the other 19:12 and, package sets that consist of many (or entirely of) seeded packages 19:13 umm...well, I see that as one of the two other cases 19:13 they have a lot in common with flavour packagesets, without necessarily being flavour packagesets 19:13 tumbleweed, example pleasE? 19:13 flavor packagesets imply project level involvement 19:13 core was mentioned in the discussion earlier. xorg? 19:14 core, desktop-core, xorg, ubuntu-desktop, ubuntu-server, ... 19:14 we have a few of those 19:14 core packageset isn't a packageset for these purposes IMHO, that would be core-dev 19:14 I can't imagine entertaining an application for the first two 19:14 not without other changes anyway 19:14 right 19:14 the last 2 are flavors 19:14 xorg has seeded content, but that's aggregate PPU IMHO 19:15 and we'd be unlikley to give a new person upload access to it. But conceputally, it probably doesn't require membership 19:15 right 19:16 well, one way it could work is that the general rule is membership is not necessary for ppu. then we have a black list of packages for which membership *is* required. then if any of those packages appear in a package-set, the set is also blacklisted. it means the level of check/control is at the package level 19:16 haha 19:16 I'm not sure about which problem we're trying to solve here 19:17 would having all main packages in the blacklist too restrict? 19:17 yes 19:17 micahg-work: making it clear to applicants whether they need membership or not 19:17 If we are trusting them with upload rights for these important packages, we're inherently trusting them not to break stuff 19:17 tumbleweed, no, I mean the issue of packagesets like xorg requiring membership 19:17 yeah, agreed with you 19:18 having membership shouldn't improve that "trust" any 19:18 Right, we're not lowering any technical requirements here 19:18 so if they know everything they need to to upload then I don't see any need to require s&s on top of that 19:19 and if we're worried someone's going to break the archive during a milestone or what not, we probably shouldn't be giving them upload rights in the first place 19:20 ok, flavour packagesets? 19:22 flavor packagesets have project level scope IMHO and should require membership (in that we want flavors integrated into the main Ubuntu community and not islands amongst themselves) 19:22 yeah, my feeling too 19:22 same 19:22 for the same reason we'll continue requiring it for motu/core-dev 19:22 can we vote on this proposal, or is there anything else we need to hash out? 19:22 which criteria do we want to use for requiring significant & sustainable contribution? 19:22 stgraber, how do you feel about all this? 19:23 micahg-work: still not too happy about opening the possiblity of the DMB granting upload rights to critical packages without requiring membership. I know that the current DMB probably is reasonable about it, but I'm not thrilled about the documented new process being that open. 19:24 I guess I don't feel that membership is where concerns about individual developers are likely to be 19:24 it's going to be at their technical judgement 19:25 right, that's how I feel as well 19:25 well, I personally tend to like people who have upload rights to packages installed by default on my system to have been around for at least a whole cycle 19:25 I don't want non-member developers to be come a norm 19:26 stgraber, we can make being around a whole cycle a requirement without requiring membership (not requiring significant or sustained, just the time period) 19:26 would we be prepared to limit this to entirely non-main package (-set)s ? 19:26 so I'm happy to grant non-member PPU to some upstream dev maintaining their package in universe, but I'd prefer to have the process restricted in a way that ensures that 19:26 I think that any DMB the community has confidence in will be rigorous enough 19:26 micahg-work: then I think I'd be happy with that 19:27 what is 'being around'? 19:27 time from first upload to application? 19:27 we already require understanding of the release schedule for upload rights 19:27 being around a whole cycle, but not a member doesn't sound like a common scenario 19:27 indeed 19:27 Laney, well, either that or first contribution (bzr included) 19:27 Laney: either first upload or testimonial from a current dev that the applicant has been anoying them for over 6 months 19:28 just being exposed to the release process 19:31 how about if instead of requiring non-main, we added a sentence to the effect of: Upload rights to core (seeded) packages will require sustained experience in the project (usually meaning membership)? 19:31 +1 19:32 * tumbleweed isn't convinced that membership from forums would make us happy about upload rights to xorg, though :P 19:32 fine, but I don't see the point in singling packages out like that 19:32 I'd rather make explicit that we'll require a level of trust that is appropriate for the packages in question 19:32 tumbleweed, right, that's the catch, you can get membership for a lot of different things 19:32 so nethack not so much, binutils perhaps a bit more 19:33 Laney, I think that's fair 19:33 which is of course what happens already 19:33 right 19:33 Laney: the level of trust expectation is already there 19:34 level of trust doesn't mean experience of release process, which is what stgraber seems concerned about 19:34 tumbleweed, it does to some extent 19:34 especially WRT seeded packages 19:34 it's one of the components 19:34 well it doesn't say "you have to have been around for X months" indeed 19:34 but the DMB has to convince itself 19:35 * Laney shrugs 19:35 I'm fine with explicit vagueness if it solves the problem 19:35 if this is what we need to move on then so be it 19:35 clarity of our expectations would also be useful 19:35 OK, so while we consider this. What's next 19:35 mail final wording to TB for signoff? 19:36 can we get a final wording now? or this this meeting not going to do it for us? 19:36 we have an applicant to process, too 19:36 wording of what? 19:36 an announcement? 19:37 the proposal, if we want their signoff 19:37 I guess just edit the pad that I started already to reflect what we decide now 19:37 ok, I think we should move on now, we can revisit this later 19:37 then ask the TB to ack/nack it at their meeting 19:37 remaining action item: 19:37 laney to update DD-PPU process to say that any ubuntu-dev is eligible 19:38 yeah sorry didn't do that yet 19:38 ok, carried 19:38 but we got an applicant through it anyway 19:38 so seems ok 19:38 #topic Louis Bouchard's Contributing Developer application 19:38 caribou: hi 19:38 Hello everyone 19:38 tumbleweed: o/ 19:38 caribou: please introduce your application 19:38 https://wiki.ubuntu.com/LouisBouchard 19:39 My name is Louis Bouchard 19:39 I've been working on Ubuntu as my day job for a bit more than 2 years noew 19:39 but started using ubuntu in 2006 with Edgy 19:40 I will not repeat what you can read on the Wiki page 19:40 I come from the dark side of proprietary softwarea long long time ago 19:40 heh 19:40 I involvment with Ubuntu is mainly around bug fixing, SRU etc 19:41 I also do some mentored packaging on the debian side of things 19:41 great to hear 19:41 Since my involvment has been regularly increasing with Ubuntu, I thought it was appropriate to apply for UCD 19:42 I'm afraid I have to run off in a minute, but hopefully barry can continue chairing the meeting for me 19:42 caribou: when do you expect to be applying for upload rigths? 19:42 most of my involvment is around Foundation packages, with a bit of work on the kernel side 19:42 I want to get more exposure with merges and also participate in PlusOne to get more experience 19:42 * barry takes a seat 19:43 caribou: have you scheduled your plus-one yet? 19:43 no, not yet. I will need some hand-holding in that direction 19:44 but some of my colleagues have participated a few cycles already 19:44 so they can help 19:44 caribou: it's a great learning experience 19:44 barry: that's what I heard, which triggered my interest 19:44 merging is also something I'm curious about. 19:45 I see packaging from the debian side of things only right now 19:45 though it's a rather small package 19:46 I also think that PlusOne will help me in may daily activities 19:46 anything else I can outline for you ? 19:46 caribou: i saw that makedumpfile is arch restricted. is that intentional? 19:47 bdrung: there seems to be some issues currently with the ARM side of things 19:47 bdrung: there is an open Debian bug about it that needs my attention 19:48 bdrung: aside from that, I think that there is one specific PPC patch laying around that might explain it 19:48 caribou: but shouldn't it work on all architectures (besides bugs)? 19:49 afaik makedumpfile do make some assumptions regarding specific architectures 19:49 bdrung: as it works in a kexec triggered kernel boot that is somewhat different from a regular boot environment 19:50 ah, okay 19:51 bdrung: that might come from debian's inheritance as well, since I don't think we do specific changes to the package on Ubuntu 19:51 I see it listed for amd64, i386, ia64 and powerpc only on Debian 19:52 caribou: thanks. i think we're ready to vote 19:52 #vote should caribou become an ubuntu contributing developer? 19:52 Please vote on: should caribou become an ubuntu contributing developer? 19:52 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) 19:53 +1 19:53 +1 received from bdrung 19:53 tumbleweed extends a +1 19:53 +1 19:53 +1 received from barry 19:53 +1 19:53 +1 received from Laney 19:53 +1 19:53 +1 received from stgraber 19:53 +1 19:53 +1 received from micahg-work 19:54 and scottk is absent today, so 19:54 #endvote 19:54 Voting ended on: should caribou become an ubuntu contributing developer? 19:54 Votes for:5 Votes against:0 Abstentions:0 19:54 Motion carried 19:54 caribou: congratulations 19:54 barry: & everyone else, thank you very much 19:54 looking forward to see you again for the next step 19:55 \o/ 19:55 caribou: indeed! enjoy the +1 :) 19:55 & all the work in the meantime 19:55 get on that sponsorin' train 19:55 Laney: will do 19:55 we have no more applicants today 19:55 #topic AOB 19:55 anything else folks want to bring up today? 19:56 I don't know how we are carrying the PPU thing on 19:56 Laney: i think we have to continue on the mailing list 19:57 ok 19:58 if there's nothing else, i think we're done 19:58 #endmeeting