=== DWonderly is now known as DarkwingDuck
=== doko_ is now known as doko
=== ejat- is now known as ejat
=== seeker_ is now known as seeker
=== med_out is now known as medberry
=== Guest69226 is now known as Zic
roadmrHey everyone!15:00
roadmrReady for the Ubuntu Friendly meeting?15:00
roadmr#startmeeting Ubuntu Friendly meeting15:00
meetingologyMeeting started Mon Sep 12 15:00:54 2011 UTC.  The chair is roadmr. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot.15:00
meetingologyAvailable 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 #votesrequired15:00
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Friendly meeting Meeting | Current topic:
roadmrWelcome everyone! The official agenda for today is short, but if you have something you'd like to discuss regarding Ubuntu Friendly, we'd be happy to hear about it.15:01
roadmrDon't forget to use "o/" if you'd like to comment on something. Also, please follow the convention of using ".." on a separate line when you've finished what you want to say.15:01
roadmrWe'll go over agenda topics first, so here goes:15:02
roadmr#topic Questions about the program posed during Ubuntu Global Jam15:02
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Friendly meeting Meeting | Current topic: Questions about the program posed during Ubuntu Global Jam
roadmrakgraner was kind enough to post a great report of Ubuntu Global Jam, along with a series of questions that came up regarding Ubuntu Friendly.15:03
roadmr#link http://akgraner.com/?p=102015:03
roadmrvictorp took a minute to reply to most of them earlier today (and yes, checkbox 0.12.6 should be available now), but if some quick clarification is needed on some of those this might be a good opportunity.15:04
roadmrguess I'll follow the convention too :15:04
roadmranyone? :)15:05
roadmrlast chance!15:06
victorpgoing once15:06
roadmrlooks like the answers are so far OK then :)15:08
roadmrI'll o/15:09
roadmrI'd just like to say that adding this to the UF FAQ may be worthwhile, akgraner's blog is a fine spot due to her contacts in LUGs15:09
roadmrbut keeping stuff like this in a central location also makes sense, we probably shouldn't scatter the information around too much, makes it harder to find15:10
roadmrAnyway, if more questions pop up or you can think of something to add to this, you're quite welcome to post on the mailing list.15:11
roadmrSo let's move on!15:11
roadmr#topic Any Other Business15:11
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Friendly meeting Meeting | Current topic: Any Other Business
roadmrWould you like to discuss anything else today?15:11
roadmrnothing? :) nobody?15:13
* charlie-tca thinks it must be close to a perfect project, now ;)15:14
roadmrspeak now or forever (or at least until next Monday) hold your peace?15:14
roadmrcharlie-tca: heheh we welcome praise as well :)15:15
roadmrlast chance, any takers?15:15
roadmrOK, so let's wrap this up then. Remember, you can always speak up on the next meeting, or on the ubuntu-friendly mailing list. We like to get feedback! try the new checkbox! file bugs! give us suggestions!15:16
roadmrIt was a quick meeting today, still, thanks for being here, do take the System Testing app out for a spin and let us know how useful you think the tests are.15:17
roadmrSee you next time, Monday September 19th at 15:00 UTC!15:18
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology
meetingologyMeeting ended Mon Sep 12 15:19:14 2011 UTC.15:19
meetingologyMinutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-09-12-15.00.moin.txt15:19
charlie-tcaroadmr: thanks for chairing that meeting.15:33
roadmrcharlie-tca: no problem, I did last week too, hope I didn't scare everyone away for today :)15:33
charlie-tcaheh, if they scare that easy, ...15:35
=== ^aL-ITAngel^ is now known as ^zenhoobb-it
=== yofel_ is now known as yofel
jdstrandlet's wait for others to arrive17:02
jdstrandlet's get started17:04
meetingologyMeeting started Mon Sep 12 17:04:39 2011 UTC.  The chair is jdstrand. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot.17:04
meetingologyAvailable 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 #votesrequired17:04
jdstrand[LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting17:04
keeshah "#lurk"17:05
jdstrand[TOPIC] Weekly stand-up report17:05
=== meetingology changed the topic of #ubuntu-meeting to: Weekly stand-up report
jdstrandI'll go first17:05
jdstrandI'm in the happy place this week (thankfully :P)17:06
mdeslaurjdstrand: thanks for covering for me17:06
jdstrandheh, np :)17:06
jdstrandI am reviewing an embargoed issue17:06
jdstrandhave miscellaneous P&C tasks17:06
jdstrandhave patch piloting this week17:06
jdstrandand will continue to work with jjohansen on dbus/apparmor17:07
jdstrandoh, and metrics work items as have time17:07
jdstrandthat's it from me17:07
jdstrandjjohansen: :)17:07
jdstrandkees: you're up17:07
keesI'm going to be focusing on training and documentation this week17:08
keesworking through my list, basically.17:08
keesI have some MIRs and patch pilot work today17:09
keesthat's about it for now. I'll have a blog post with some news later today17:11
jdstrandthanks kees17:11
jdstrandmdeslaur: you're next17:11
mdeslaurAh! yes!17:11
mdeslaurI'm working on cups updates17:11
mdeslaurand will probably tackle ffmpeg next17:11
jdstrandah, good :)17:11
mdeslaurI'm on community this week, although there's nothing in the queue (hint: C'mon community!)17:12
mdeslaurand I'll probably be spending some time with kees, there's a few things he wants to show me17:12
mdeslaurand...that's it!17:12
jdstrand(yeah, the last couple of weeks haven't had a lot of community for me to sponsor)17:12
mdeslaursbeattie: next!17:13
jdstrands/community/community work/17:13
sbeattieI'm on triage this week.17:13
zookoHope I'm not interrupting, but I have a community security issue for you.17:13
sbeattieI'm also working on openssl.17:13
jdstrandzooko: can you bring it up at the end? I'll ping you17:14
sbeattiezooko: end should be more than another 5-10 min away17:14
sbeattieshouldn't be, that is17:14
sbeattieThat's pretty much it for me.17:15
jdstrandmicahg: you're up17:16
micahgok, so I'm still cleaning up after DigiNotar, we're in week 3 of this mess17:17
micahgqt4-x11, thunderbird, and chromium (maybe seamonkey at the end of the week)17:17
micahgalso, the next round of Mozilla builds should be coming soonish, will get them staged as they come17:18
micahgI also have patch piloting once chromium is done17:19
micahgthat's it17:19
jdstrandjeez, 3 patch pilots from our team this week...17:19
jdstrandtyhicks: you're up17:20
tyhicksI am still coming up to speed in the new role, but I feel like I can put the finishing touches on patching and testing of a mutt fix I've been working on17:20
tyhicksI've found a bug in mutt (possibly a regression from the fix mentioned above) while doing initial testing and I'll get that fixed17:20
tyhicksThen I plan on taking ownership of another item in the CVE queue and/or learning the triaging process17:21
keesnice :)17:21
tyhicksIn the rest of the time, I've still got a small eCryptfs kernel maintainer backlog to get through17:21
tyhicksThat's it17:21
sbeattietyhicks: \o/17:21
jdstrandtyhicks: sounds great :)17:22
tyhicksthanks, all :)17:22
jdstrand[TOPIC] Highlighted packages17:22
=== meetingology changed the topic of #ubuntu-meeting to: Highlighted packages
jdstrandThe Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so. See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security.17:22
jdstrand[TOPIC] Miscellaneous and Questions17:23
=== meetingology changed the topic of #ubuntu-meeting to: Miscellaneous and Questions
jdstrandzooko: what's up?17:23
zookoThe Tahoe-LAFS team has found a security flaw in Tahoe-LAFS which is present in all versions included in Ubuntu Lucid and newer.17:24
zookoWe have a fix patch, announcement text, docs, etc. but haven't divulged details to anyone yet.17:24
jdstrandzooko: have you filed a bug with Ubuntu yet?17:25
zookoThe impact is moderate -- it could allow a sufficiently motivated malicious person to delete files but not to read or alter them.17:25
zookoNo -- I'll do that within an hour or so.17:25
jdstrandzooko: thanks for the heads up. please file it at https://bugs.launchpad.net/ubuntu/+source/tahoe-lafs/+filebug and check the 'This bug is a security vulnerability' box17:26
jdstrandzooko: the bug will be sent to us and will be private17:26
jdstrandzooko: we can coordinate via the bug then17:26
jdstrandDoes anyone have any other questions or items to discuss?17:27
jdstrandkees, mdeslaur, sbeattie, micahg, tyhicks, jjohansen, zooko: thanks!17:29
mdeslaurthanks jdstrand!17:29
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology
meetingologyMeeting ended Mon Sep 12 17:29:12 2011 UTC.17:29
meetingologyMinutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-09-12-17.04.moin.txt17:29
micahgthanks jdstrand17:29
sbeattiejdstrand: thanks!17:29
tyhicksjdstrand: thank you!17:29
=== ejat- is now known as ejat
* stgraber waves19:02
* cody-somerville waves.19:02
* micahg is here19:02
* geser waves19:02
cody-somervillebdrung, persia, Laney, geser: ping19:02
* bdrung waves back.19:02
micahgLaney sent apologies19:02
stgraberand cyphermox asked us to postpone his application till our next meeting19:03
cody-somervilleGreat. Any volunteers for chair?19:04
stgraber#startmeeting Ubuntu Developer Membership Board meeting19:04
meetingologyMeeting started Mon Sep 12 19:04:35 2011 UTC.  The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot.19:04
meetingologyAvailable 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 #votesrequired19:04
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Developer Membership Board meeting Meeting | Current topic:
stgraber#topic Review of previous action items19:04
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Developer Membership Board meeting Meeting | Current topic: Review of previous action items
cody-somervilleThat is slightly obnoxious new behavior, lol.19:05
stgraberonly action was for Laney to start a thread on ubuntu-devel19:05
stgraberI guess we'll skip that one as he isn't around19:05
stgraber#topic Administrative Matters19:05
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Developer Membership Board meeting Meeting | Current topic: Administrative Matters
stgraberas Laney sent to the list, the results of the poll are available at: http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_cdfc460c74495b7519:06
stgraberwith micahg being the winner, congrats!19:06
micahgthanks stgraber19:06
gesermicahg: welcome19:06
micahgthanks geser19:06
cody-somervilleI move we accept the results of the poll and forward a request to the TB to have micahg added to the DMB.19:07
geserwho can add micahg to the private DMB list? I forgot who has the password now19:07
stgrabermaybe I have it, let me quickly check19:08
stgraberanyone who's willing to take the action of e-mailing the TB to get micahg added to the team?19:09
ScottKCongratulations micahg.19:09
micahgthanks ScottK19:09
geserI'll mail the TB19:09
cody-somervillestgraber, I recommend we vote to confirm micahg as our recommendation to the TB19:09
stgrabercody-somerville: ok19:09
gesercody-somerville: why vote?19:09
ejatcongrate micahg19:09
gesercody-somerville: the dev community voted micahg and we have to accept it19:10
cody-somervilleBecause the poll wasn't conducted by the TB. We don't have the authority to add someone to the DMB ourselves. It has to be done by the TB and for us to make a recommendation as a body we need to put it to vote.19:10
* ScottK doesn't recall such voting before.19:10
micahggeser: generally the DMB confirms the vote FWIR19:11
stgraberbtw, I just found the DMB mailing list password ;)19:11
micahgfor reference: http://irclogs.ubuntu.com/2011/02/14/%23ubuntu-meeting.html#t12:1619:12
micahgso, no vote was done last time, just a "verbal" confirmation19:12
cody-somervilleSee, this is why we're so glad to have you join us micahg :)19:12
micahgheh, I come to serve :)19:13
bdrungmicahg: then you will suffer ;)19:13
geserI hope the TB would speak up when we ask them to add micahg if they have any doubts about the voting process19:13
cody-somervilleI'll leave it to the chair to decide if we have an official vote or not. I think we all know the outcome anyhow as no one has spoken any objections thus far.19:13
stgraber#agreed micahg is the winner of the CIVS poll19:14
stgrabernot sure if the bot understood that one :)19:14
stgraber#action geser to e-mail the TB with the result of the poll19:15
meetingologyACTION: geser to e-mail the TB with the result of the poll19:15
stgraber#action stgraber to add micahg to the mailing-list once TB has added him to the team19:15
meetingologyACTION: stgraber to add micahg to the mailing-list once TB has added him to the team19:15
stgraberanything else we need to do to get micahg on board?19:15
cody-somervilleWe should probably ask the TB to remove Morgan, eh?19:15
bdrungstgraber: it's #agree not #agreed19:15
bdrungups, both should be possible19:16
gesercody-somerville: will add it to my mail to the TB19:16
* bdrung welcomes micahg, too.19:16
micahgthanks bdrung19:16
stgrabercody-somerville: indeed. I'll remove her from the mailing-list when I add micahg19:17
stgraberjono: around?19:17
jonohi stgraber19:18
stgraberhi jono19:18
micahgISTR jono suggesting waiting for all the boards to come together in a single meeting19:18
stgraberapparently we're already done with our agenda for this meeting as cyphermox asked us to wait till our next meeting to look at his application :)19:18
jonoI figured we may want to evaluate the report when we have the DMB and TB together19:18
jonowe would likely need a joint meeting anyway19:18
jonoso I thought it would be more efficient to organize that single meeting19:19
cody-somervilleIs the TB really required for an initial discussion?19:20
jonocody-somerville, well, the topic is developer process governance, so I think they should be involved19:21
stgrabertrying to get all the TB and the DMB attending the same meeting seems quite tricky, especially when we're getting closer and closer to release, also, I don't know if all the e-mails are still stuck in the TB's moderation queue but I haven't seen any activity from the TB following your e-mail19:21
jonofeel free to discuss the report now though if you wish19:21
jonostgraber, indeed19:21
bdrungjono: bug in page 3? 81% are MOTUs? 81% + 2 * 32% > 100%19:22
jonobdrung, people could choose multiple options19:22
jonoso be a motu and a core-dev for example19:22
bdrungah, ok.19:22
stgraberoh, btw :)19:23
cody-somervillejono, Yes but shouldn't there be a set of recommendations developed before going to the TB? Otherwise we'll just be discussing the data and not necessarily actions that can be taken based off of said data.19:23
stgraber#link http://ubuntuone.com/0L7YnAHC0MRC2cHgLlq4n519:23
jonocody-somerville, then feel free to discuss it now19:23
jonoI am flexible19:24
cody-somervillejono, Do you think there are any areas of concern that your survey has uncovered or confirmed?19:24
jonocody-somerville, sure, see the last page19:25
jonoso, do we want to have this conversation now?19:26
bdrungIMHO yes19:26
geserjono: I guess you have no data about the time the applicants expected to process their application and the time it really needed, right? It would be interesting to know if it really took so long or the expectations where so short.19:27
jonook happy to discuss now then19:28
jonogeser, unfortunately not19:28
jonoso in the report, take a look at the conclusions on the last pager19:28
jonoI think those can be good points of discussion19:29
jonoa common theme was documentation of the process and expectations19:29
micahgjono: should we go point by point?19:29
jonomicahg, sure lets do that19:30
geserI completely agree that PPU and package sets are complete underdocumented19:30
jonoBetter Document the Per-Package Uploader Process – there was significant issues reported over the clarity and expectations of the Per-Package Uploader process. A19:30
jonoreview of the documentation and some clarity could help resolve this issue.19:30
micahgI don't think this is such a problem, see https://wiki.ubuntu.com/UbuntuDevelopers#Per-package_Uploaders19:30
micahgit looks like it's been updated19:30
jonomicahg, maybe folks have either not seen that page or don't understand the content?19:31
micahgjono: that could be, people might not know where to go to see that19:31
jonothe PPU process was the primary area of confusion in the survey19:31
cody-somervilleFWIW, I think the survey appears highly positive.19:31
jonocody-somerville, totally19:31
jonothese are just fixing little bumps in the road19:31
jonoit seems like the MOTU side of things is pretty solid19:31
micahgjono: hmm, it's linked from the main DMB page19:31
jonowhen someone wants to be a dev, where do we point them?19:32
micahgI'd be interested in knowing where people are currently looking19:32
jonoa place for them to learn about what core-dev, motu, and ppu is19:32
micahgI generally send people here: https://wiki.ubuntu.com/UbuntuDevelopers19:32
stgrabermy personal opinion on the matter is that PPU and package sets are mostly confusing because they are invisible. People can't easily know who can upload what and in some cases even what they have the right to upload19:33
jonothat page is way too busy19:33
bdrungthat was my primary wiki page when i applied for upload rights19:33
jonoI think maybe some work on that page could help simplify things19:33
jonoit is a bit of information overload19:33
micahgjono: do you think sub pages for each of the types would be better with just a short paragraph for each on the main page?19:34
jonomicahg, that is my hunch19:34
bdrungand it lacks an picture that shows the difference between the different positions19:34
stgrabermicahg: +119:34
ScottKI've also seen people apply for PPU that clearly knew VERY little about Ubuntu.  I think one reason the feedback was more negative for PPU was there are a larger fraction of applicants that apply way too early.19:34
jonomicahg, more along the lines of https://wiki.ubuntu.com/Membership19:34
jonoScottK, how do you feel we can encourage folks to apply at the right time?19:35
* micahg hasn't noticed a lack of people being told when to apply19:35
ScottKBack when I applied to be MOTU the general (unwritten) rule was apply when someone told you to.19:35
stgraberScottK: indeed, at last one case comes to mind (packages weren't even in the archive)19:35
jonoScottK, but is that scalable?19:36
jonothat replies on people noticing other folks' work and advising them to apply19:36
micahgI had the same experience as ScottK for MOTU and for core-dev as well (application pending soon :))19:36
stgraberjono: as we encourage people going through sponsors before applying for upload irghts, I think it does19:36
jonothere is another possible option here19:37
stgraberjono: people usually tend to poke the same sponsor for most of their uploads (at least that's what's happening to me), so it's pretty easy for the sponsor to know when they are ready19:37
highvoltageI'm only catching the latter part of the conversation so I might be missing something, but there's an Ubuntu Open Week coming up, wouldn't it be nice to have a session on the differences between PPU, MOTU, Core-dev, etc and when it's appropriate to apply to each?19:37
geserScottK: doesn't this look too exclusive from the outside? (you can only join if a current dev member tell you)19:37
jonoI asked dholbach to produce some graphs outlining developer contributions across a timeframe, maybe we could ask the DMB to review these graphs and evaluate folks based upon significant and dustained contributions19:37
ScottKI think that's overkill.19:37
jonoScottK, why?19:38
ScottKjono: Sorry - I was replying to highvoltage.19:38
jonooh I see19:38
highvoltageScottK: ok19:38
micahggeser: I don't think ScottK is saying that's the only way, but rather for most applicants, that's just what happens19:39
jonodholbach and I are using the graphs he created to identify those doing good work and ensure they get mentorship19:39
jonothe same could be applied to identifying potential candidates for DMB review19:39
ScottKjono: How do you graph "good work"?19:39
micahgjono: singling out people for mentorship sounds good, I think for upload rights though, people need to take some initiative to get them19:39
jonoScottK, well, it graphs approved uploads over a period of time - so it should significant and sustained19:40
gesermicahg: I know but do you believe that newcomers will understand it the same way as ScottK intended it?19:40
jonoit would require a little more evaluation19:40
cody-somervillejono, I think improving the DMB's access to data like that would be highly positive.19:40
jonoso let me ask a question19:40
micahgjono: also, if you're doing mentorship, when the mentors feel candidates ready, they'll push them appropriate towards an application19:40
micahggeser: well, if it's worded properly :)19:40
jonotoday people can either (1) apply themselves for a dev role or (2) we can encourage people to only apply if they a dev recommends they do19:40
ScottKjono: OK.  I think that sort of thing is a lot more useful for member applications than developer applications.19:41
jonodo you folks believe we should optimize the process around (2) ?19:41
jonomicahg, agreed19:41
ScottKI would say that they should ask people who've been sponsoring them.19:41
cody-somervilleand get endorsements, lol19:41
ScottKThey don't necessarily need to wait or get permission, but they should ask first.19:41
micahgno, I think if the mentoring pieces are in place, the application encouragement will come automatically19:41
jonowell it seems the issues highlighted in the report are not to do with when or how people apply19:42
cody-somervilleI think the bigger problem is that we don't really have a lot of people applying who aren't working on Ubuntu as a part of their job.19:42
jonoit is a knowledge of how the process and expectations work19:42
micahgcody-somerville: +119:42
ScottKjono: I think that's a side effect of people applying too early.19:42
jonocody-somerville, why is that a problem?19:42
jonoScottK, not sure I agree - the docs could better communicate when people should apply19:42
micahgScottK: +119:42
ScottKjono: Certainly.  That's always the case, but I don't think that's the primary issue.19:43
cody-somervillejono, because our developer community needs to grow and we shouldn't expect Canonical to be the driving force behind that by hiring more folks.19:43
jonocody-somerville, I don't think it matters where people work, it matters that they are good developers19:43
cody-somervillejono, And its highly unlikely that Canonical is able to hire ALL the best and brightest.19:44
cody-somervilleWe should look to attract others from other parts of the wider community to contribute19:44
jonocody-somerville, <jono> cody-somerville, I don't think it matters where people work, it matters that they are good developers19:44
micahgjono: of course it shouldn't matter, I think cody-somerville was just commenting on who's applying recently (i.e. we don't have very many non-canonifolk)19:44
ScottKjono: If Ubuntu development is seen to be a predominately Canonical club, then it will hurt Ubuntu.19:44
cody-somervilleRight. The problem I'm trying to highlight is we're not seeing growth in our ranks except that done by Canonical hiring more folks.19:45
jonoScottK, of course, but working at Canonical is not a reason for someone to have a more challenging application process than someone else19:45
cody-somervillejono, No one is suggesting that.19:45
jonoanyway, I think we digress19:45
ScottKjono: No.  I didn't say that.19:45
ScottKPlease don't put words in my mouth.19:45
jonoScottK, I am not putting words in your mouth19:46
ScottKWhere did I saw Canonical should have a more challenging application process?19:46
jonoScottK, I never said you did say that19:46
jonoI was making a general point19:46
jonoparticularly as this has been a point of contention in the community in the past19:46
ScottKThe why were you making it at me?19:46
jonoScottK, I wasn't19:46
jonoScottK, relax, it wasn't focused at you19:47
jonoit was a general point19:47
cody-somervillejono, Canonical applicants do not have any harder of a time than anyone else... except there is hardly anyone else19:47
ScottKAn odd way to make it, but whatever.19:47
jonocody-somerville, good stuff :-)19:47
jonoso getting back to how devs engage in the process19:47
jonoit sounds like there is a feeling that devs should be recommended to apply19:48
jonoas a general rule19:48
cody-somervilleYes, we require all applicants to have endorsements from other developers.19:49
stgraberit's the recommended way, yes. As that means someone will already have given them tips for their wiki page, very likely a testimonial too, so they're pretty much ready for a meeting with the DMB19:49
jonodo we feel we could improve the docs in recommending this approach19:49
micahgwell, I think this is more about how it happens, than a general rule, but all applicants do need endorsements19:49
jonoso we discourage folks to apply without a recommendation from another dev19:49
cody-somervilleI don't think I've seen any applications that lack endorsements.19:49
cody-somervilleI think we need to improve the documentation for the endorsers19:50
jonoso the survey indicates that there is confusion over elements of the process and expectations, how do you folks feel we could improve that?19:50
ScottKBut do they tend to be strong endorsement or more like "they asked me and I don't want to upset them, so I'll say something"?19:50
stgraberScottK: we get both, but ideally I wouldn't like to see the later at all...19:51
jonoI think what might be useful is for us to restructure the wiki docs and break them out across pages, make it a little easier to parse19:51
jonoI would be happy to ask Daniel to do this19:51
micahgjono: well, I think if we could get more specifics on what people are doing that's causing confusion, then we can evaluate what needs to be done to resolve the issue19:51
micahgor what's specifically perceived as confusing, like flowchart style, that could help the understanding19:52
cody-somervillestgraber, ScottK: Right. We need to better document what it means for someone to endorse someone. We need to clarify that they should only endorse strongly and that they're putting their reputation on the line.19:52
jonomicahg, I don't think we are going to be able to get that level of granularity, but I think the survey provides some themes19:52
jonoe.g. expectations for cor-dev gets some lower ratings - so maybe we can better explain what is expecting of being a core dev and the assessment process19:52
ScottKcody-somerville: I agree with that in theory, but there's a lot of resistance to writing anything negative on an application.19:52
stgraberjono: I'm sure that'd be a good start. Also writting something for the sponsors/endorsers would be good, basically stating that if you leave an endorsement it's because you think they're ready to get the upload rights and that you can basically blindly sponsor their uploads, not a "they've poked me a lot the last few weeks and so they're pretty active in the community"19:53
stgrabercody-somerville: agreed19:53
jonostgraber, agreed19:53
jonook, so it sounds like we have two possible actions:19:53
stgraberScottK: just not writting anything would be a good start :)19:53
jono * restructure the wiki docs to be easier to reads19:53
ScottKstgraber: Agreed.19:53
jono * restructure the wiki docs to be easier to read19:53
jono * provided documentation for how to endorse someone19:53
cody-somervilleScottK, Negative feedback shouldn't go on the application IMHO. We need to find another way to handle that while still being transparent.19:54
jonoI will ask Daniel to do the former, would someone volunteer to write the endorsement doc?19:54
cody-somervilleI'm happy to write that up19:54
jonothanks cody-somerville19:54
cody-somervillealong with some other stuff about being prepared19:54
micahgcody-somerville: yes, this issue of negative feedback has been brought up before, it was suggested to maybe use devel-permissions for that19:55
ScottKcody-somerville: Why not?19:55
jonoquick q19:55
ScottKI think if someone feels strongly that someone is not ready to be a developer that they should be willing to say so.19:55
jonoso in terms of the recommended process of folks getting a recommending from a dev of how to apply, do we agree that we should make this clearer in the docs?19:55
stgraber#action jono to ask Daniel to update https://wiki.ubuntu.com/UbuntuDevelopers to be easier to read19:55
meetingologyACTION: jono to ask Daniel to update https://wiki.ubuntu.com/UbuntuDevelopers to be easier to read19:55
jono(and ensure they have plenty of testimonials)19:55
stgraber#action cody-somerville to write some documentation on how to endorse someone19:56
meetingologyACTION: cody-somerville to write some documentation on how to endorse someone19:56
jonothanks stgraber19:56
cody-somervillejono, I think its already pretty clear. As I said, hardly see anyone without any endorsements at all.19:56
jonocody-somerville, ok sounds good19:56
jonowell I have a meeting in a few mins, so I am going to need to run19:56
jonolets focus on those two actions and maybe get together at the next DMB meeting19:57
cody-somervilleScottK, That can be more difficult when it's someone you work with or even worse work for19:57
jonosound ok?19:57
ScottKcody-somerville: I think it's reasonable to have a private channel for exceptional cases, but those should be exceptional.19:57
stgraberjono: sounds good, I'll add that to our agenda for the next meeting (both actions and the fact we need to continue our discussion)19:57
bdrungjono: maybe one sentence about it. ask your sponsor if you are not sure weather  you are ready for applying19:57
jonothanks stgraber19:57
cody-somervilleScottK, People don't like to be negative though. And I'd rather get the feedback then not.19:58
jonobdrung, sound good19:58
jonothanks cody-somerville for working on the action19:58
jonobye folks19:58
micahgjono: thanks for coming19:58
cody-somervilleScottK, I think public objection should be carried heavier than private objections though (besides in exceptional circumstances).19:58
jonothanks micahg19:58
ScottKcody-somerville: I agree with that.  I think the fact that good and feedback is important needs better communication.19:58
stgraberanything else on that topic for now or should we get the wiki updated and continue discussing it at our next meeting when jono is around?19:59
micahgwell, I wanted to discuss PPU along the lines of one of Laney's e-mails20:00
stgrabermicahg: sure, let me quickly check if there's another meeting in -meeting as we're already past our reserved allocation20:01
micahgerr, I meant package set, not PPU20:01
stgraberseems like we're good, no planned meetings after ours20:01
bdrungwhile discussing about the process: we could use bug report for managing the applications instead of letting the applicant add themselves on our wiki page.20:01
micahgI think having a wiki page is good as you end up with a clear presentation in the end as opposed to a bug20:02
geserhmm, does not being a developer count as a bug that needs fixing? :)20:03
stgraberI also like having everything in the right order on one page, it's easier when chairing the meeting. Also, although it doesn't mean we have to do it like that, all other boards do it using a wiki page :)20:03
bdrunga bug has the advantage of different statuses and you could set a milestone. you could reopen a bug for a deferred application.20:03
micahgbdrung: a wikipage is versatile, you can do whatever you want with it :)20:04
geserand teach the bug triagers to leave those bugs alone20:04
* micahg certainly doesn't need another set of bugs20:04
bdrunggeser: it would be a separate project owned by the dmb20:04
bdrungdevelopers are familiar with bug reports.20:05
stgraberI'm not against changing the layout of the agenda a bit to better work with cases where we vote by e-mail and for people who ask us to wait till our next meeting (rather than have to remember it when chairing the meeting), but I don't think using bugs is a good idea20:05
stgraber#agreed continue discussion on Ubuntu Developer Survey Report with jono at our next meeting20:07
bdrungit seems that i am the only one who likes the idea of lp bugs. so i am dropping this idea.20:07
stgrabermicahg: do we want to discuss package sets now or should we wait till our next meeting where we may might have Laney around?20:08
stgraberas in, do you think there are actions we can take now on that subject?20:08
bdrunganother idea for reducing the waiting time: do a weekly meeting. we had meeting that took more than one hour. having weekly meeting would reduce risk to need longer. if there is no item on the list for one meeting, we could cancel it the day before.20:08
micahgwell, it's about developing the process and agreeing on it, so I don't think there's really any actions that could happen before a vote unless you'd like me to write up a proposal before the next meeting20:09
stgraberbdrung: well, we're already having issues getting together every two weeks ;) I think we'd be fine with the load if we can make sure to have quorum at every meeting, if that becomes a problem, we may switch to weekly meeting then, sounds reasonable?20:09
stgraber#topic Reduce bureaucracy around packagesets20:10
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Developer Membership Board meeting Meeting | Current topic: Reduce bureaucracy around packagesets
bdrungstgraber: yes. having a weekly meeting leads to a quorum every two weeks too. ;)20:11
stgraberbdrung: hehe, I meant, if we indeed get quorum every two weeks and we still have too many applicants to fit in our one hour slot, then we should consider switching to weekly meeting.20:12
stgraberbdrung: for now I think we only accumulated backlog because quite a few of us couldn't make it to the "early" meeting20:12
geserstgraber: have we any written documentation about the process of adding and removing packages to package sets or even the creation of a package set?20:13
stgraberbdrung: not sure what's that status on the doodle, would have to poke Laney and see if we can change that meeting time20:13
stgrabergeser: I'm not sure. The way it usually worked so far is that people ask for PPU to a bunch of packages and the DMB then ask them to ask for a package set20:13
micahggeser: that's the issue I wanted to bring up :)20:14
stgraberIdeally I'd like the list of all package sets to be easy to find on the wiki with a page for each of them containing the current package list (unless the package set is dynamically generated from a seed)20:14
stgraberas well as the reason for its creation and the rule to update it (anything that's bazaar related for example)20:14
micahgstgraber: I think that would be better served as an Ubuntuwire page running a script than a static wiki page20:15
micahgat least for the list,  the other pieces could go on the wiki20:15
bdrungor having the list in a bzr branch?20:15
stgrabermicahg: for the current list of packages, agreed but I still want to have on the same page, what team is linked to the package set (when we have a matching team), the reason for the package set and the rule for updating it20:15
micahgbdrung: again, that requires more work for the updater20:16
micahgstgraber: agreed20:16
stgraberbdrung: the list can be queried from the LP API20:16
stgraberbdrung: python edit_acl.py query -P bzr -S oneiric20:16
stgrabermicahg: can you setup a script that'll list all the existing package sets for all supported ubuntu releases? just the output of edit_acl.py for each of them would be nice.20:18
bdrungstgraber: i know. i was thinking about the rules that is used as basis, e.g. containing "bzr-*" for the bzr package set20:18
stgrabermicahg: ideally refreshed daily and available somewhere public so we can link to it from the wiki20:18
micahgI think geser has had more luck that I with the API20:18
stgrabergeser: can you do that then? :)20:18
* micahg could do it, just not before the next meeting20:19
stgraberbdrung: I think a bzr branch would make sense for cases where we can pretty much automate the generation of the package sets, so we can write a script to check if a package set is up to date and give us the list of what's missing if it's not (I don't wnat the script to just do the change ;))20:21
stgraberbdrung: I'd still like the general rule to be written on the wiki so people can easily find it and understand it20:21
bdrungstgraber: agreed on that20:21
gesermicahg: I can help you with that if you want as I'm not sure when I'm able to find time to do it myself20:22
stgraberhmm, seems like we lost geser :)20:22
stgraberoh, no, he's back :)20:22
micahggeser: ok, maybe we can get it done by UDS then20:23
stgraberI just had a quick look at the API and I think I can get something running pretty quickly20:24
stgraberso I'm happy to take the action ;)20:24
micahgstgraber: there are already some ubuntuwire pages for packagesets as well: qa.ubuntuwire.org/mdt/mozilla.html20:26
stgraber#action stgraber to get the list of all package sets and their content somewhere online20:26
meetingologyACTION: stgraber to get the list of all package sets and their content somewhere online20:26
stgrabermicahg: ah cool, I'll probably link to that then. I'm just planning on getting the list of all package sets, their owner and content, for version numbers and bugs, I'm more than happy to add links :)20:27
stgraberanything else on package sets for this meeting?20:27
micahgstgraber: wgrant set those up20:27
micahgwell, we need a process for adding and/or removing packages from a packageset20:28
stgraberremoving is a bit tricky, for adding, so far I've just done it if it matches the initial reason for the package set (and sent an e-mail to the DMB mailing list)20:29
stgraberin most cases I think we want package sets to match some criteria that can be checked from a script and so a simple poke on IRC should be enough to have one of us update the list20:30
micahgright, we should have a documented process, for instance, I was filing bugs to have packages added to the mozilla packageset before, I don't believe this to be the proper way to do this unless we're involving the archive admins since the DMB/TB don't generally have a bug workflow20:30
stgrabermicahg: right. Keeping your example, we should have the mozilla packageset properly defined (as containing all of firefox, thunderbird, xul, extensions, ... whatever is appropriate) and then any other request we get for it that match that get automatically approved20:32
stgraberif it's not (new mozilla product for example), then it should be discussed and approved at a DMB meeting20:32
geserstgraber: IIRC the mozilla PS is defined through a (build-)dependency20:33
stgraberthat's I think mostly how package sets have been maintained so far (both the DMB and TB maintained ones) and I think it makes sense to continue that way, but have it documented20:33
stgrabergeser: even better then, that's easy to check for ;)20:33
micahgright, makes sense, something outside the defined guidelines needs approval at the meeting20:34
micahgand those defined guidelines should be listed in the initial e-mail to devel-permissions with the approval (in addition to being on the wiki) so there's a record of what they were when approved20:35
gesera central place to look up the definition of a package set would really help, currently one has to look up the meeting log to check what exactly got approved20:35
stgraberI hope that once we have the list up somewhere and some documentation on the wiki for the existing package sets, that'll make things clearer for both uploaders and for us20:35
stgrabermicahg: indeed20:35
micahgas for workflow for adding, I was thinking an e-mail to devel-permissions requesting the change?20:36
micahgI think Laney mentioned something similar20:36
geserworks for me20:36
stgrabermicahg: yep, that sounds good. Also making sure whoever updates the package sets e-mail the DMB and/or -permissions so that we know why a packageset has been changed and what got added20:37
micahgLaney's thoughts are mentioned here: https://lists.ubuntu.com/archives/technical-board/2011-September/001077.html20:37
stgrabercody-somerville: hey again, want me to copy/paste you what you missed?20:37
cody-somervillestgraber, Please.20:38
micahgstgraber: yep, makes sense as long it's not being handled by the archive admins20:38
micahgactually, scratch that20:38
micahgmakes sense period, AA promotions have a bug filed for tracking20:39
stgrabercody-somerville: http://paste.ubuntu.com/687883/20:39
stgrabercody-somerville: added a bit more as you left with a ping timeout20:39
stgrabermicahg: in theory we should be able to update the package sets ourselves, it's unfortunately not always the case and sometimes we need to ask the TB to do it20:40
stgrabermicahg: but I don't think we ever need to work with the archive admins as package sets are unrelated to components20:41
micahgstgraber: well, once the rules are defined, why shouldn't it be an archive admin task?20:41
geserwhich non-seed based PS are TB owned?20:41
stgrabergeser: I think kernel was one I couldn't modify20:41
stgrabermicahg: no because they can't do it, they aren't the owner of the package set, the DMB or the TB is20:42
micahgstgraber: that's a technical issue20:42
geserthe process for changing a package set owner is no fun20:43
stgrabermicahg: indeed, though I guess it currently makes sense it goes through the DMB as we're the ones getting the request for PS update anyway. If we notice we don't do it quickly enough, then we probably should consider moving it to the archive admins and adding that to their todolist (if they agree to do it ;))20:43
micahgagain, a technical issue20:43
micahgstgraber: that's a workflow issue, those requests could be directed to the AAs through bugs if that's appropriate (just like requesting removals from the archive)20:44
micahgthe question is who should really be doing the work20:44
micahgwe should definitely have a workflow for ourselves in the meantime, but maybe keep in mind what the longterm goal for this should be20:45
stgraberI see package sets as the same thing as PPU except it affects a larger amount of people, so as it still has to do with upload rights, I think it's appropriate for the DMB to handle it20:46
micahgstgraber: well, PPU has no rules defining the set, packageset does20:47
micahgwhy is it different than components20:47
stgraber(or the TB for the seed based ones)20:47
micahgonce the rules are set, it's just making sure the package in question follows the rules of the set (same as whether a package from Debian should go in universe instead of multiverse)20:48
stgrabermicahg: my personal point of view is that either we need the package set changes reviewed and in such case I'd like the DMB to do it or we have clear enough rules that they can be scripted and ran in a cron job20:48
stgraberanyway, for the time being, I think we can start by documenting our package sets and continue this discussion at our next meeting, sounds reasonable?20:50
micahgstgraber: yes, sounds good20:50
stgraber(we're getting dangerously close to the 2 hours mark and I still have things to do this afternoon ;))20:50
* micahg has plenty to do as well20:50
stgraber#agreed start documenting package sets and continue discussion about our package set management workflows at our next meeting20:51
stgraber#topic Select a chair for the next meeting20:51
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Developer Membership Board meeting Meeting | Current topic: Select a chair for the next meeting
stgraberany volunteer?20:51
stgraberthanks micahg20:52
stgraber#action micahg to chair our next meeting20:52
meetingologyACTION: micahg to chair our next meeting20:52
stgraber#topic AOB20:52
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Developer Membership Board meeting Meeting | Current topic: AOB
stgraberanything else?20:52
stgraberperfect :)20:52
=== meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology
meetingologyMeeting ended Mon Sep 12 20:52:53 2011 UTC.20:52
meetingologyMinutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-09-12-19.04.moin.txt20:52
stgraberthanks everyone for attending!20:53
micahgsorry for talking everyone's ear off :)20:53
micahgthanks stgraber20:53
micahgstgraber: just to confirm, next meeting is 14:00 UTC on sept 26?20:53
stgrabermicahg: glad to have you on board, hope to get TB confirmation soon so we can have you talk on our mailing-list too :)20:53
bdrungmicahg: yes20:54
micahgstgraber: thanks20:54
micahgbdrung: thanks20:54
bdrungi have updated https://wiki.ubuntu.com/DeveloperMembershipBoard/NextMeeting which will be shown on the main page20:54
stgraberbdrung: thanks20:55
bdrungshowing more than the next meeting time gives the applicants more choices for when they want to attend20:55
micahgLaney: ?21:25
stgraberLaney: any problem? :)21:26
LaneyI think sets should be DMB owned and managed. And I'm not sure that you could script most of them. As for where they should be documented, a project seems overkill. I was thinking of a wiki page as a lightweight solution. Or, as each set is linked to a Launchpad team, the description there.21:29
stgraberLaney: yep, I'm going to have a script online on people.canonical.com (as I can run something with cron there) that will just dump the list of package sets and their content. Then have a wiki page for each of them pointing there with who owns them, if there's a team linked to them and what was the reason for its creation.21:31
stgraberI think that's what we need for now, we can always try to automate more later when we feel it's needed.21:31
Laneythey'll always have a team, by policy21:32
Laneyso I think that might be a good place to document the definition of that particular set21:32
Laneyif the script is just to enumerate the sets, that's fine21:34
stgraberyep, that's what I'm working on21:34
stgraberLaney: I guess we'll need to fix some package sets, I can't find a team for the package set "utouch"21:40
Laneyluckily we can fix that since it is dmb owned21:41
Laneyyou can make ~ubuntu-utouch-uploaders and add chase to it, then swap the packageset membership21:42

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!