19:03:45 <micahg> #startmeeting
19:03:45 <meetingology> Meeting started Mon Feb 25 19:03:45 2013 UTC.  The chair is micahg. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
19:03:45 <meetingology> 
19:03:45 <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:04:00 <micahg> welcome to the DMB fortnightly meeting
19:04:06 * stgraber waves
19:04:13 <Logan_> Hey. :)
19:04:34 <micahg> #topic review previous action items
19:04:43 <micahg> #subtopic Micah to announce the poll results
19:04:50 <micahg> not yet, will do after the meeting
19:05:04 <micahg> #subtopic Iain to do the paperwork for the kernel PPU team delegation
19:05:19 <micahg> as Laney is absent, we'll carry this forward as I don't see anything for it yet
19:05:36 <micahg> #topic MOTU Applications
19:05:50 <micahg> first up, wendar
19:05:57 <wendar> hi
19:06:00 <micahg> #link https://wiki.ubuntu.com/AllisonRandal/MOTU
19:06:06 <ScottK> \o
19:06:13 <micahg> wendar: please introduce yourself
19:06:22 <ScottK> dmb ping needs to be updated
19:06:33 <micahg> ScottK: ubottu was offline :)
19:08:18 <wendar> Not sure what to put in an introduction. I'll go with: Hi, I'm Allison Randal, I've been involved in Ubuntu in various ways since 2005.
19:09:04 <wendar> I am an upstream developer on the Parrot project, so have always paid close attention to those packages.
19:09:47 <wendar> But, mostly see Ubuntu as an integrated whole system. (And from that perspective, parrot plays a very small part.)
19:10:36 <wendar> My packaging work is often in the area of battling complicated failures in C or Perl packages.
19:10:44 <wendar> With a few Python packages mixed in.
19:11:00 <wendar> I mostly avoid Java. :)
19:11:23 <wendar> end-of-intro
19:11:28 <tumbleweed> wendar: hi, yeah, just been looking through some of your recent uploads
19:11:37 <tumbleweed> and https://launchpadlibrarian.net/87347747/syncmaildir_1.2.2-1_1.2.2-1ubuntu1.diff.gz caught my eye
19:11:56 <tumbleweed> was that forwarded upstream? it's useful to add DEP-3 headers indicating things like that
19:12:24 <tumbleweed> I see the upstream is essentially the debian maintainer, but I see no bug in the BTS
19:13:25 <wendar> That was a while ago now, so I don't actually remember if I forwarded that one upstream.
19:13:35 <wendar> Most of the fixes I made that month I did push up to Debian.
19:13:54 <tumbleweed> ok, in that case this might be a reminder to bounce it to the Debian maintainer :)
19:13:59 <wendar> It's possible I forgot on that one, or that it's already been integrated and closed.
19:14:17 <wendar> I'll make a note and follow up on it.
19:14:35 <tumbleweed> so any ideas on making sponsorship less painful?
19:15:26 <wendar> I'm not sure it is painful for newbies.
19:15:49 <bdrung> the build fix is not integrated in the Debian, yet
19:16:19 <wendar> But, for me I think it boils down to 1) limited time from sponsors, and 2) I tend to work in areas that are quite complex C code, and not all sponsors can even understand the fixes.
19:16:31 <tumbleweed> hah
19:17:00 <micahg> well, if the patch is accepted upstream, it makes it easier for a sponsor
19:17:08 <wendar> Following a normal progression, where you're new, and mostly work on typos and such, I think it's likely that you'd find plenty of ready sponsors.
19:17:24 <barry> wendar: i wonder if patch pilots help much here or whether pilots tend to avoid complicated code in areas they don't know well
19:18:12 <wendar> micahg: Yes, my conclusion over the past couple of months is that just working straight in Debian is often the right answer. Even if I found the problem through an Ubuntu FTBFS.
19:18:44 <micahg> right, Debian or further upstream (if it exists)
19:19:03 <wendar> barry: Patch pilots help enormously with the common case. But, perhaps not with more "advanced" sponsorship needs.
19:19:32 <bdrung> i assume that it's not hard to find a sponsor for a patch that was accepted upstream
19:19:42 <bdrung> even if the patch is complicated
19:20:06 <wendar> bdrung: If it's not critical, I usually just leave the Debian fix to flow through to Ubuntu through normal means.
19:20:19 <wendar> bdrung: So, yes, no effort at all :)
19:20:23 <micahg> well, probably depends if there's an Ubuntu diff already or not and how different the package is on our platform
19:20:55 <wendar> micahg: Fortunately, I find that most universe packages are very close to Debian.
19:21:16 <micahg> well, I think we're a tad over 75%
19:21:19 <wendar> (At least, in personal experience, I've never done a full package scan.)
19:21:38 <micahg> https://merges.ubuntu.com/universe-now.png
19:21:58 <tumbleweed> ^ I see Logan_ has been busy
19:22:22 <tumbleweed> wendar: you are subscribed to ubuntu-devel-announce?
19:22:23 * ScottK has no questions.
19:22:24 <wendar> micahg: sweet!
19:22:31 <Logan_> :P
19:22:52 <tumbleweed> wendar: and I assume we don't need to quiz you about the release schedule
19:22:54 <wendar> tumbleweed: I think so...
19:24:01 <wendar> tumbleweed: ah, yes, I filter it into the ubuntu-devel folder
19:24:33 <tumbleweed> good. it's suprising how many applicants aren't
19:24:36 <bdrung> wendar: there are only 13 uploaded packages listed on launchpad. most of your contribution doesn't seem to be visible there.
19:24:40 <wendar> tumbleweed: :) we could get into a conversation about whether skipping alphas has been helpful, but that might be distracting
19:24:48 <micahg> wendar: I've noticed limited activity in sponsored uploads aside from the +1 stint in 2011, can you speak to that point?
19:25:17 <wendar> micahg: yes, I've been thinking about that since January
19:25:39 <wendar> micahg: it basically boils down to "project benefit for time spent"
19:26:06 <wendar> micahg: There are many areas I can contribute. And packaging is one I'm very good at.
19:26:15 <wendar> Especially around nasty C/Perl failures.
19:26:51 <wendar> But, when I spend 4 hours fixing a problem, and then 1-2 weeks getting the fix approved, it makes me wonder if that's the best use of my time.
19:27:09 <wendar> And frankly, frustrates me to the point that I avoid it.
19:27:31 <wendar> I can't say I'm proud of that fact, but it is a fact.
19:27:54 <wendar> In Dec 2011 I had a dedicated sponsor, and zipped through a stack of tricky packages.
19:27:59 * ScottK completely understands.  I have had the same issue with trying to fix Ubuntu docs.
19:28:04 <micahg> well, surely in most cases, the fix can be forwarded to Debian and then have  a sync requested to pull it in (otherwise, pinging the patch pilot if you need something to go in can be helpful)
19:28:50 <micahg> I can certainly understand the frustration, but "sponsored" contributions are standard before any type of "commit" rights are given
19:29:06 <wendar> Sure, but going through Debian is the "well, maybe it'll get applied, eventually" kind of fix.
19:29:33 <ScottK> It's the same problem actually just substitute maintainer for sponsor
19:29:38 <wendar> micahg: Indeed, and I think that natural progression is the right path.
19:30:02 <bdrung> does it really take so much time to get the fix in? letting the patch sit in the sponsoring queue doesn't consume time.
19:30:04 <micahg> and saying that one doesn't like the process and avoiding it for that reason doesn't seem right as most of us did have to go through that same process to get upload rights
19:30:19 <wendar> micahg: I think that if you compress my "sponsored" uploads over the past 6 years, they add up to about what would be reasonable for an upload application.
19:30:44 <micahg> I see 12 here: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=allison+randal&sponsoree_search=name
19:30:49 <wendar> micahg: I suspect most contributors would do that in 6 months, and then apply.
19:31:41 <micahg> compared to our next applicant (who's number is a bit high) http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=logan+rosen&sponsoree_search=name
19:33:39 <bdrung> so you can get 13 patches into the archive in four days
19:34:11 <wendar> Logan_: well done!
19:34:24 <Logan_> Thanks. :)
19:34:31 * ScottK thinks numbers are not very relevant.
19:35:30 <wendar> michag: Sorry, was that a question?
19:35:53 <micahg> #voters micahg ScottK stgraber Laney bdrung barry tumbleweed
19:35:53 <meetingology> Current voters: Laney ScottK barry bdrung micahg stgraber tumbleweed
19:35:59 <ScottK> +1
19:36:07 <tumbleweed> ScottK: not quite yet
19:36:10 <micahg> ScottK: hold on :)
19:36:14 <ScottK> OK
19:36:32 <micahg> #vote Please vote on Allison Randal (wendar) becoming MOTU
19:36:32 <meetingology> Please vote on: Please vote on Allison Randal (wendar) becoming MOTU
19:36:32 <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:36:38 <ScottK> +1
19:36:38 <meetingology> +1 received from ScottK
19:36:41 <barry> +1
19:36:41 <meetingology> +1 received from barry
19:36:43 <stgraber> +1
19:36:43 <meetingology> +1 received from stgraber
19:36:43 <tumbleweed> +1
19:36:43 <meetingology> +1 received from tumbleweed
19:37:05 <bdrung> +1
19:37:05 <meetingology> +1 received from bdrung
19:37:21 <micahg> +0 I would've liked more varied contributions beforehand
19:37:21 <meetingology> +0 I would've liked more varied contributions beforehand received from micahg
19:37:32 <micahg> #endvote
19:37:32 <meetingology> Voting ended on: Please vote on Allison Randal (wendar) becoming MOTU
19:37:32 <meetingology> Votes for:5 Votes against:0 Abstentions:1
19:37:32 <meetingology> Motion carried
19:37:40 <micahg> wendar: congratulations
19:37:45 <Logan_> wendar: Congrats!
19:37:45 <ScottK> wendar: Congratulations.
19:37:47 <stgraber> for the record, Laney also gave a +1 by e-mail
19:37:49 <wendar> thanks :)
19:37:53 <barry> wendar: congrats!
19:37:55 <tumbleweed> congrats
19:37:59 <stgraber> wendar: congrats!
19:38:05 <bdrung> welcome wendar
19:39:16 <micahg> #subtopic Logan Rosen's MOTU application
19:39:23 <micahg> #link https://wiki.ubuntu.com/LoganRosen/MOTUApplication
19:39:30 <micahg> Logan_: please introduce yourself
19:39:52 <Logan_> Hey guys. I'm Logan Rosen, and I've been contributing to Ubuntu for a while now. I mostly work on bug triaging (as part of the Bug Squad), merging packages in from Debian, requesting syncs, and merging in new upstream releases of packages to Ubuntu.
19:41:17 <Logan_> I applied for MOTU from the encouragement of a sponsor, who thought that my numerous contributions/sponsored changes were substantial enough to be a MOTU.
19:41:33 * ScottK thinks that's a very good reason to apply.
19:42:28 <Logan_> Being a MOTU would allow me to push fixes to packages more quickly and reduce deltas between Ubuntu and Debian as much as possible, which is what I already do through sponsorship.
19:43:21 <Logan_> I really enjoy working with people in the Ubuntu community, and they have all been very encouraging and helpful. Whenever I have a question, I can count on someone being on IRC to help me out.
19:43:37 <tumbleweed> Logan_: I see you've been taking an interest in our ubuntu-only packages
19:44:04 <tumbleweed> any ideas on how we can get other people to do so? they are often terribly unde-maintained
19:44:11 <Logan_> I have - I feel that those are sometimes neglected (hence the neglected Ubuntu-only packages report on ubuntuwire).
19:44:25 <tumbleweed> glad someone finds it useful
19:45:04 <Logan_> I'm not sure exactly how to engage people in maintaining Ubuntu-only packages, but one way would be to publicize that report more, so that people see the packages that are left behind in the dust.
19:45:36 <Logan_> At one point, I was going through a bunch of them and checking lintian for warnings/errors and fixing them accordingly - just one way to ensure package quality.
19:46:18 <tumbleweed> hrm, so maybe providing reports on these packages is working to draw attention to them
19:46:28 <tumbleweed> Logan_: what's happening with https://launchpad.net/ubuntu/+source/lxsession-edit ?
19:46:29 <micahg> UEHS is nice
19:46:39 <tumbleweed> err I meant https://launchpad.net/ubuntu/+source/lxsession-edit/0.2.0-3ubuntu1
19:47:13 <Logan_> Ah, yes. The issue is that I didn't realize at the time that lxsession-edit is provided by the lxsession source package in Ubuntu as well, so the migration scripts got angry, saying that a newer version (from git) was already in the archive.
19:47:33 <tumbleweed> what are we gonig to do about it?
19:48:16 <Logan_> I initially filed a bug against lxsession in Ubuntu, recommending that the lxsession-edit binary be removed (so that we can be in harmony with Debian), but they decided against that.
19:48:58 <Logan_> It's possible that the lxsession-edit source package will just be removed from Ubuntu (and added to the blacklist, if necessary). I personally prefer minimizing the delta, but there are reasons behind that decision, I suppose.
19:49:40 <tumbleweed> well, removing the binary wouldn't help users to downgrade to 0.2.... binary
19:50:26 <Logan_> True, but we could then update lxsession-edit in Ubuntu to that git snapshot.
19:51:08 <tumbleweed> right
19:51:24 <tumbleweed> Logan_: you're subscribed to ubuntu-devel-announce?
19:51:36 <Logan_> I just did, about half an hour ago.
19:51:41 <tumbleweed> :)
19:52:30 <bdrung> Logan_: do you want to join the sponsoring team?
19:53:18 <Logan_> If you think that would be a good fit for me, then sure. :)
19:55:00 <tumbleweed> Logan_: so, what stops you forwarding things to Debian?
19:55:08 <bdrung> i think it makes sense to help newcomers after having benefited from the sponsors.
19:55:44 <tumbleweed> yeah, keeping the sponsorship report down to 0 items is a valuable job
19:56:28 <Logan_> tumbleweed: If it is an Ubuntu-specific change that wouldn't make sense in Debian, then I won't forward it.
19:56:29 <bdrung> tumbleweed: i helped reaching it zero once, but then never got enough time to do it again
19:57:03 <tumbleweed> bdrung: yeah, I used to sponsor a lot, when I had the time...
19:57:03 <Logan_> (Such as something upstart-related, which usually tends to just be in Ubuntu.)
19:57:12 <micahg> Logan_: WRT to the last point, I don't see a bug in the BTS for the remaining diff here: https://code.launchpad.net/~logan/ubuntu/raring/tandem-mass/20121001-2ubuntu1/+merge/149920
19:58:08 <tumbleweed> Logan_: right. there are debian maintainers who will accept ubuntu-specific changes if it means their package can be in sync on Ubuntu. They are quite rare, though
19:59:03 <Logan_> micahg: Yeah - I figured there must have been a reason not to forward it at the time of the change, but I'll forward that to Debian (it might require a +dfsg?).
19:59:33 <micahg> Logan_: well, that's one solution which I think Debian might prefer
19:59:53 <micahg> but I think they certainly care about not from source binaries
20:00:04 <Logan_> I also find UDD to be much more intuitive than forwarding debdiffs, although the submittodebian tool from ubuntu-dev-tools attempts to minimize the pain from that.
20:00:39 <micahg> submittodebian is nice, /me hugs bdmurray
20:01:09 <ScottK> As a DD though I sometimes seen bugs from submittodebian that are very confusing.
20:01:25 <ScottK> You need to make sure what it produces is sensible/useful for the maintainer.
20:01:40 <micahg> bdmurray: oh, sorry, I thought you had a hand in writing it for some reason
20:01:52 * barry usually extracts the diff and submits from a debian vm ;/
20:02:31 <bdrung> micahg: Soren Hansen and Steve Langasek wrote it and tumbleweed did a lot about it lately
20:02:44 <micahg> Logan_: sometimes people figure they'll file the bugs later and then forget about it
20:03:44 <Logan_> Yeah, that's definitely happened to me.
20:04:07 <Logan_> It would be nice if Debian used Launchpad (wishful thinking?).
20:04:21 <bdrung> that's very unlikely to happen
20:04:41 <micahg> Logan_: so, I remember at one point, you were non-maliciously hijacking merges without discussing with people, I was wondering if you indeed had a talk with the previous uploader about https://code.launchpad.net/~logan/ubuntu/raring/piuparts/0.49ubuntu1/+merge/149918 before proposing the merge
20:06:07 <Logan_> I didn't discuss that one with Andrew, but, with the feature freeze coming up, and considering that the new Debian version came out over a month ago, I figured it would be safe to perform the merge myself.
20:06:24 <Logan_> It was also a pretty simple merge.
20:07:23 <stgraber> Logan_: how well do you know the Ubuntu release schedule?
20:08:02 <Logan_> I'd like to say that I know it pretty well. I mostly focus on the Debian Import Freeze and the Feature Freeze dates, as those are the ones that affect what I do the most.
20:08:39 <Logan_> I filed a number of FFEs in the Quantal cycle, I believe.
20:08:45 <stgraber> are universe packages affected by milestone freezes?
20:08:58 <Logan_> Yup.
20:09:57 <stgraber> all of them or just a subset?
20:10:52 <Logan_> Only the ones that are included on the CDs, as milestone freezes are for ISO testing, I believe.
20:11:06 <Logan_> *DVDs (Quantal <3)
20:11:10 <stgraber> correct
20:11:19 <stgraber> how do you know whether a source is safe to upload or not?
20:11:39 <Logan_> Sorry, in what context?
20:12:21 <stgraber> milestone freeze
20:12:39 <stgraber> how do you know whether something will affect what's on a media
20:13:24 <Logan_> Check the reverse dependencies?
20:14:17 <stgraber> that'd be a pretty tedius process to figure out whether something is on a media or not
20:14:29 <stgraber> did you ever here of the seeded-in-ubuntu tool?
20:14:52 <Logan_> I've seen it, but I'm not sure about its functionality. Isn't it one of the ubuntu-dev-tools scripts?
20:15:04 <stgraber> it's
20:15:16 <bdrung> s/here/heard/
20:15:30 <stgraber> you can basically use it, passing the name of the source you want to upload and it'll tell you whether it's on a media
20:15:35 <Logan_> Ah, gotcha.
20:16:18 <tumbleweed> (figured out from the last daily build logs)
20:16:18 <stgraber> now a tricky one, what about vlc, if we're in milestone freeze, can you upload it safely?
20:17:47 <Logan_> Well, it looks like it's on the Mythbuntu ISOs...
20:18:18 <stgraber> correct but is mythbuntu participating in standard releases?
20:18:45 <Logan_> I actually learned last week while triaging bugs that Mythbuntu recently switched to only LTS releases of Ubuntu.
20:18:52 <Logan_> So, I guess it depends on whether or not it is an LTS.
20:19:04 <stgraber> correct
20:19:16 * Logan_ wipes his forehead.
20:19:18 <stgraber> you can upload that package during any non-LTS release while in milestone freeze
20:20:10 <bdrung> Logan_: don't worry, vlc is in my tight hands. ;)
20:20:29 <Logan_> Haha, I'll leave vlc to you in that case.
20:21:48 <bdrung> Logan_: you seem to be a generalist. will you stay that way or are you interested in specialising?
20:22:35 <Logan_> I like being a generalist because it means that there's always work to do in Ubuntu, and I'm not restricted to a certain set of packages. If I were part of a team, though, I'd definitely consider specializing in certain packages.
20:22:41 <micahg> Logan_: so, back to my point about merges, there are two things, one is to not duplicate work, the assumption is that if someone has a merge they'll do it or orphan it on merges.ubuntu.com, if you're worried about something getting in, a note is nice, the other thing is that there's no shortage of work to be done, so if someone is already taking "responsibility" for something, it's usually good to let them do that and find something neglected
20:22:41 <micahg> to fix, now there are merges left at the end of the cycle that aren't touched usually, I believe tumbleweed had a list somewhere of neglected merges
20:23:19 <tumbleweed> yeah, on ubuntuwire somewhere
20:23:35 <micahg> http://people.ubuntuwire.org/~stefanor/ubuntu-neglected-packages/
20:24:05 <Logan_> micahg: Okay, I'll definitely make note of the merges I'm working on in the future.
20:26:26 * Logan_ hopes that someone will eventually take up Bug 611121.
20:26:27 <ubottu> bug 611121 in ubuntu-dev-tools (Ubuntu) "add a requestmerge script" [Wishlist,Triaged] https://launchpad.net/bugs/611121
20:27:05 <bdrung> Logan_: patches welcome. :)
20:27:05 <tumbleweed> patches are welcome
20:27:12 <micahg> #vote Please vote on Logan Rosen becoming MOTU
20:27:12 <meetingology> Please vote on: Please vote on Logan Rosen becoming MOTU
20:27:12 <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)
20:27:25 <tumbleweed> +1
20:27:25 <meetingology> +1 received from tumbleweed
20:27:28 <barry> +1
20:27:28 <meetingology> +1 received from barry
20:27:30 <ScottK> +1
20:27:30 <meetingology> +1 received from ScottK
20:27:32 <bdrung> +1
20:27:32 <meetingology> +1 received from bdrung
20:27:37 <micahg> +1
20:27:37 <meetingology> +1 received from micahg
20:27:39 <stgraber> +1
20:27:39 <meetingology> +1 received from stgraber
20:27:45 <micahg> #endvote
20:27:45 <meetingology> Voting ended on: Please vote on Logan Rosen becoming MOTU
20:27:45 <meetingology> Votes for:6 Votes against:0 Abstentions:0
20:27:45 <meetingology> Motion carried
20:27:50 <micahg> Logan_: congratulations
20:27:56 <Logan_> Thanks so much!
20:27:58 <ScottK> Congratulations Logan_.
20:28:04 <bdrung> Logan_: congrats
20:28:15 <barry> Logan_: congrats!
20:28:23 <tumbleweed> welcome to MOTU
20:28:28 <bdrung> tumbleweed: Logan_ bug reminds me to do a u-d-t release.
20:28:36 <tumbleweed> bdrung: err, yeah
20:28:47 <micahg> #topic Review of previous action items
20:29:00 <micahg> #subtopic Iain to do the paperwork for the kernel PPU team delegation
20:29:15 <micahg> I see Laney did this here: https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu_Developers_.28from_delegated_teams.29
20:29:16 <ScottK> He seems to have escaped.
20:29:25 <Logan_> Gotta run - thanks again!
20:29:25 <micahg> so that's done
20:29:37 <micahg> #topic AOB
20:30:30 <ScottK> Nothing from me.
20:32:42 <micahg> #subtopic Decouple PPU from Ubuntu membership (what needs to be done?)
20:33:46 <micahg> so, IIRC, the TB was ok with the concept, so I guess we need documentation + figuring out team changes?
20:34:07 <micahg> s/changes/structure/
20:35:32 <pleia2> micahg: I never did ask, will we be grandfathering in folks who already are PPU members? (which would probably mean directly adding them to the ubuntumembers team)
20:36:11 <tumbleweed> I would say so
20:36:19 <pleia2> would hate for people to be depending upon membership for some reason (or one of the benefits) and lose that without realizing what happened
20:36:32 <micahg> pleia2: I think we'll still want a developer only membership without upload rights that recognizes contributions, but that the person isn't quite ready to work without a net, having said that, I think that yes, we'd grandfather those previous ubuntu-dev members in
20:36:49 <bdrung> our changes should only affect future applications
20:37:05 <tumbleweed> micahg: that's ~universe-contributors, isn't it?
20:37:38 <bdrung> yes, that's ~universe-contributors. maybe we should rename that team
20:37:39 <micahg> tumbleweed: yeah, I think we need to restructure all of this to bring it into the present though
20:37:42 <pleia2> ok, great
20:37:44 <tumbleweed> which has no reason to be universe-related
20:38:10 <bdrung> it used to be universe-related, but isn't any more
20:38:25 <tumbleweed> I can't think of a sane name for a team for ubuntu developers who are members
20:38:46 <bdrung> Ubuntu Contributing Developers
20:39:10 <tumbleweed> ok I like that
20:39:45 <tumbleweed> although
20:39:48 <stgraber> UCD makes sense, we've been using the name for a while now, it's just the team name that doesn't make any sense. We should just rename it and be done with it.
20:39:56 <tumbleweed> ~universe-contributors isn't a member of ubuntu-dev
20:40:07 <ScottK> I thought UCD were members who got membership via development, but weren't ready for upload rights yet?
20:40:09 <micahg> ok, so can we get someone to draft the new team names/structures and someone to draft new documentation?
20:40:13 <micahg> ScottK: correct
20:40:20 <tumbleweed> those peolpe don't have upload rights so they don't get bug-control
20:40:28 <tumbleweed> (etc.)
20:40:35 <ScottK> So those are members without upload rights.
20:40:48 <tumbleweed> yes, but we currently call that team Ubuntu Contributing Developers
20:40:51 <ScottK> Don't we need somthing new for upload rights without membership?
20:41:01 <tumbleweed> ubuntu-ppu ?
20:41:10 <micahg> yeah, something like that
20:41:11 <tumbleweed> upload rights without membership are only going to be PPU
20:41:20 <ScottK> Yes.
20:41:23 <barry> tumbleweed: +1
20:41:43 <stgraber> hmm, it's going to get tricky...
20:42:05 <stgraber> so we want PPU without membership to be part of some kidn of team so we can track them, yet not have any kind of membership
20:42:05 <micahg> tumbleweed: no, I can see some packagesets fitting into that as well
20:42:14 <stgraber> and those that have PPU + membership need to be somehow part of ~ubuntu-dev
20:42:23 <stgraber> but UCD members shouldn't be part of ~ubuntu-dev
20:42:51 <bdrung> what is ~ubuntu-dev used for?
20:43:03 <stgraber> ~ubuntu-dev means you can vote for the DMB/TB/...
20:43:04 <tumbleweed> https://launchpad.net/~ubuntu-dev/+participation
20:43:12 <stgraber> and is probably used in a few more places for additional rights
20:44:42 <micahg> I think we can have ~ubuntu-uploaders and ~ubuntu-contributing-developers as base teams for ubuntu-dev, the former has upload related teams (bug control and such), the later has membership related (cloak, planet)
20:44:46 <barry> ~ubuntu-contributors is a subteam of ~ubuntumembers which is a "group of people who vote to confirm new appointments to the Ubuntu Community Council"
20:45:29 <stgraber> barry: right, which isn't the same group as those voting for DMB+TB IIRC :)
20:45:40 <micahg> ubuntu-dev inherits the permissions, and people can move there once they have both permissions
20:46:59 <micahg> wait, does ubuntu-dev require general membership or dev membership?
20:47:09 <ScottK> Yes
20:47:16 <tumbleweed> so should ubuntu-ppu just be a separate team for people who get PPU without upload rights?
20:47:21 <micahg> (i.e. can someone be a loco rockstar, get PPU and then be able to vote for TB/DMB)
20:47:25 <tumbleweed> it doesn't sound like it cas easily fit into any tree
20:47:43 <micahg> tumbleweed: yeah, I'd call the team ubuntu-uploaders as a base team
20:47:49 <ScottK> micahg: Yes.  Membership is membership.  There's really no such thing as a developer membership.
20:48:24 <ScottK> The current situation is that if you're PPU and have membership, you can vote for TB.
20:48:26 <stgraber> micahg: member + some-kind-of-upload-right => ubuntu-dev (either directly for PPU or indirectly for motu/coredev/package-set)
20:48:46 <ScottK> Now that's currently all PPU, but in the future, we probably have to retain that.
20:48:59 <micahg> stgraber: right, that was my question, but I guess now that Debian has non uploading DDs, I guess the point isn't as valid
20:49:23 * ScottK wonders how that is relevant.
20:49:36 <stgraber> yeah, not sure what's the relation with non-uploading DDs
20:49:42 <micahg> the basis of the question was at what point does an uploader have enough experience to have a say in how development activities are done
20:50:58 <micahg> (i.e. electing those people to decide those policies)
20:51:19 <stgraber> when an uploader also becomes a member they're able to vote, not before that
20:51:32 <stgraber> and members who can't upload don't get to vote for DMB/TB
20:52:00 <tumbleweed> http://paste.ubuntu.com/5565892/ ?
20:52:16 <micahg> right, I was wondering if the sustained development aspect was important (we in theory have this now)
20:52:56 <ScottK> It's sustained contribution.
20:53:12 <micahg> tumbleweed: I wouldn't put all packagesets under ubuntu-dev, the flavors for sure, not sure about the others
20:53:15 <ScottK> If someone was already a member, you don't re-review that.
20:53:33 <micahg> I guess that's true
20:53:51 <tumbleweed> micahg: they're already there
20:54:12 <tumbleweed> micahg: where do we put them then? are we not giving them automatic membership?
20:54:45 <stgraber> any team giving upload rights, except for the special non-member-PPU needs to be a member of ubuntu-dev
20:54:53 <stgraber> that's how it's currently and that's how it should stay
20:55:43 <tumbleweed> we do tend to create a packageset for any non-trivial PPU application
20:56:04 <tumbleweed> so argubly there'll be people who don't meet membership criteria
20:56:17 <stgraber> I'd also restrict the non-member-PPU stuff to non-packageset PPU
20:56:17 <micahg> tumbleweed: we are at the moment, I'm suggesting that be restructured as some packagesets might work better as PPU in that we don't look for sustained contribution (in fact, I think I'd prefer that to lower the bar, so that just ability is gaged)
20:56:46 <tumbleweed> it can be hard to see ability without sustained contribution
20:57:05 <tumbleweed> but yes, I'm fine with saying that this is for PPU only
20:57:11 <ScottK> Isn't packageset versus individual package PPU a matter of administrative convenience?
20:57:33 <micahg> this is what I was thinking: http://paste.ubuntu.com/5565912/
20:57:46 <tumbleweed> ScottK: yes
20:58:27 <tumbleweed> micahg: that's neater than mine
20:59:19 <micahg> oops, that shouldn't say PPU people under contributing devs, but non-PPU dev members
20:59:22 <tumbleweed> except that you got ppu members and ppu people the wrong way around
20:59:32 <barry> micahg: that makes more sense ;)
20:59:48 <micahg> must have seen something shiny while typing ;)
21:00:09 <ScottK> If it's just an administrative convenience, we shouldn't make it more than that.
21:00:31 <micahg> here's with it fixed: http://paste.ubuntu.com/5565921/
21:00:44 <tumbleweed> ScottK: until the uploaders team for it has more than one member
21:00:50 <bdrung> i like micahg team structure proposal
21:01:30 <tumbleweed> micahg: surely line 3 is unecessary
21:01:35 <tumbleweed> included via ubuntu-dev
21:01:43 <stgraber> if we had a very good reason to give packageset upload to a non-member, we could create a second team for the packageset containing non-members
21:01:51 <micahg> tumbleweed: hrm? line 3 is the PPU without membership
21:02:10 <stgraber> that'd prevent them accessing branches owned by the main team though, so I certainly won't +1 any such application if there's an active team of members
21:02:13 <tumbleweed> oh, I misread sorry
21:03:16 <micahg> stgraber: I was thinking that non-flavor packagesets could be judged on ability only to lower the bar (i.e. cli-mono, input-methods)
21:04:06 <tumbleweed> +1 micahg's scheme
21:04:08 <micahg> whereas flavor packagesets are inherently membership based
21:04:09 <stgraber> micahg: I certainly wouldn't want non-members being able to get kernel, server or desktop packageset rights
21:04:33 <micahg> stgraber: kernel might be the exception here, but they're delegated now
21:04:43 <micahg> everything else is a flavor
21:05:15 <micahg> I'm fine grouping kernel with the flavor packagesets
21:05:34 <ScottK> I think kernel uploaders should be members.
21:05:40 <stgraber> micahg: what I mean is that I don't really care for non-seeded but I'm reluctant to give upload rights to seeded packages to non-members
21:05:59 <micahg> stgraber: seeded = flavor :)
21:06:02 <stgraber> micahg: to take a better example, I wouldn't give non-member upload rights to the ubuntuone set
21:06:10 <micahg> oh, hrm
21:06:17 <stgraber> micahg: nope, we have quite a few package sets containing seeded packages that aren't flavors
21:06:49 * stgraber grabs a list
21:06:55 <ScottK> How can there be a seeded package that isn't in a flavor set (or core)
21:06:55 <micahg> are we willing to give PPU for something seeded without membership?
21:07:13 * ScottK doesn't see how it matters.
21:07:23 <micahg> I think the answer is yes (the membership aspect is about sustained contribution, not trust IMHO)
21:07:38 <micahg> so, I don't see a problem with ubuntuone
21:07:38 <stgraber> ScottK: packages can be in multiple sets
21:07:59 <ScottK> Right, but to be in an image, it needs to be in at least one.
21:08:39 <stgraber> ScottK: based on what micahg said before, he'd be fine granting someone upload rights to the xorg set for example without requiring membership. But all packages in the xorg set are in main and seeded on all media.
21:08:55 <ScottK> Right.
21:09:14 <ScottK> So that's core though.
21:09:15 <stgraber> same goes for some stuff in bzr, input-methods, kernel, langpack, mozilla, ubuntuone and utouch
21:09:22 <micahg> here's my example, some DD became proficient in Ubuntu One packages after introducing them into Debian and would like to have the packages flow through Debian where possible, we'd need to make sure that the person was obviously in touch with the Ubuntu U1 members and understands the release cycle, but I don't see why membership is needed
21:09:41 <ScottK> Agreed.
21:10:02 <barry> micahg: i agree.  ppu is about trust and competence.  membership is about sustained contribution (on top of that)
21:10:14 <micahg> we won't grant PPU to begin with if we think someone is going to make a mess of things, image or not
21:10:15 <ScottK> As another example, I've got no problem with giving some people who work on X in Debian PPU rights in Ubuntu as long as we make sure they know a few things.
21:10:42 <ScottK> I don't see how seeded or not affects the decision.
21:11:53 <ScottK> We've probably done about enough for one meeting.
21:12:02 * bdrung nods.
21:12:06 <stgraber> I think we'll find that it's most often linked as "sustained" will often mean trusted and ready to contribute to core parts of Ubuntu.
21:12:08 <ScottK> micahg: Could you write up your proposal and send it to the list?
21:12:30 <micahg> ScottK: for the team structure, sure, could someone offer to write up the documentation proposal?
21:12:41 <stgraber> but I guess I'm fine with not making it a requirement and will instead just -1 those applications until they'd be fine by me to be members too.
21:12:44 <micahg> or is this all inclusive?
21:14:44 <micahg> stgraber: well, with core areas of Ubuntu, I'm more concerned with ability and trust than sustained contribution TBH, though trust a lot of time manifests itself as sustained contribution, but are not necessarily one in the same
21:15:12 <micahg> (not core-dev, PPU)
21:16:02 <micahg> #action micahg to write up proposal for new team structure and send to DMB list
21:16:02 * meetingology micahg to write up proposal for new team structure and send to DMB list
21:16:37 <micahg> ok, so unless there's anything else, I'll end the meeting as we're at 2+ hours
21:16:38 <stgraber> micahg: my experience is that you build trust over time, and it happens that the time I use to consider "sustained" and "trusted" happens to be pretty much the same ;)
21:19:03 <micahg> stgraber: I can think of cases where they need not be one in the same and would prefer the flexibility to play it by ear
21:19:36 <micahg> but we can take it to the ML
21:20:05 <micahg> unless you think there's something more we can do right now
21:20:35 <stgraber> nope, I'm happy to get back to work now, wasn't a terribly productive day for me so far ;)
21:20:44 <micahg> heh, I can relate
21:21:09 <micahg> next chair, Laney with stgraber as a backup
21:21:11 <micahg> #endmeeting