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