| === 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 | ||
| roadmr | Hey everyone! | 15:00 |
|---|---|---|
| roadmr | Ready for the Ubuntu Friendly meeting? | 15:00 |
| roadmr | #startmeeting Ubuntu Friendly meeting | 15:00 |
| meetingology | Meeting 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 |
| 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 | 15: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: | ||
| roadmr | Welcome 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 |
| roadmr | Don'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 |
| roadmr | We'll go over agenda topics first, so here goes: | 15:02 |
| roadmr | #topic Questions about the program posed during Ubuntu Global Jam | 15: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 | ||
| roadmr | akgraner 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=1020 | 15:03 |
| roadmr | victorp 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 |
| roadmr | guess I'll follow the convention too : | 15:04 |
| roadmr | .. | 15:04 |
| roadmr | anyone? :) | 15:05 |
| roadmr | last chance! | 15:06 |
| victorp | going once | 15:06 |
| roadmr | looks like the answers are so far OK then :) | 15:08 |
| roadmr | I'll o/ | 15:09 |
| roadmr | I'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 LUGs | 15:09 |
| roadmr | but 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 find | 15:10 |
| roadmr | .. | 15:10 |
| roadmr | Anyway, 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 |
| roadmr | So let's move on! | 15:11 |
| roadmr | #topic Any Other Business | 15: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 | ||
| roadmr | Would you like to discuss anything else today? | 15:11 |
| roadmr | nothing? :) nobody? | 15:13 |
| * charlie-tca thinks it must be close to a perfect project, now ;) | 15:14 | |
| roadmr | speak now or forever (or at least until next Monday) hold your peace? | 15:14 |
| roadmr | charlie-tca: heheh we welcome praise as well :) | 15:15 |
| roadmr | last chance, any takers? | 15:15 |
| roadmr | OK, 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 |
| roadmr | It 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 |
| roadmr | See you next time, Monday September 19th at 15:00 UTC! | 15:18 |
| roadmr | #endmeeting | 15:19 |
| === 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 | ||
| meetingology | Meeting ended Mon Sep 12 15:19:14 2011 UTC. | 15:19 |
| meetingology | Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-09-12-15.00.moin.txt | 15:19 |
| charlie-tca | roadmr: thanks for chairing that meeting. | 15:33 |
| roadmr | charlie-tca: no problem, I did last week too, hope I didn't scare everyone away for today :) | 15:33 |
| charlie-tca | heh, if they scare that easy, ... | 15:35 |
| === ^aL-ITAngel^ is now known as ^zenhoobb-it | ||
| === yofel_ is now known as yofel | ||
| jdstrand | hi! | 17:01 |
| jjohansen | hey | 17:01 |
| jdstrand | let's wait for others to arrive | 17:02 |
| sbeattie | hey | 17:03 |
| micahg | o/ | 17:03 |
| mdeslaur | hiya | 17:03 |
| tyhicks | Hello | 17:04 |
| kees | \o | 17:04 |
| jdstrand | let's get started | 17:04 |
| jdstrand | #startmeeting | 17:04 |
| meetingology | Meeting 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 |
| 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 | 17:04 |
| jdstrand | [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting | 17:04 |
| kees | hah "#lurk" | 17:05 |
| jdstrand | heh | 17:05 |
| jdstrand | [TOPIC] Weekly stand-up report | 17:05 |
| === meetingology changed the topic of #ubuntu-meeting to: Weekly stand-up report | ||
| jdstrand | I'll go first | 17:05 |
| jdstrand | I'm in the happy place this week (thankfully :P) | 17:06 |
| mdeslaur | jdstrand: thanks for covering for me | 17:06 |
| jdstrand | heh, np :) | 17:06 |
| jdstrand | I am reviewing an embargoed issue | 17:06 |
| jdstrand | have miscellaneous P&C tasks | 17:06 |
| jdstrand | have patch piloting this week | 17:06 |
| jdstrand | and will continue to work with jjohansen on dbus/apparmor | 17:07 |
| jjohansen | \o/ | 17:07 |
| jdstrand | oh, and metrics work items as have time | 17:07 |
| jdstrand | that's it from me | 17:07 |
| jdstrand | jjohansen: :) | 17:07 |
| jdstrand | kees: you're up | 17:07 |
| kees | I'm going to be focusing on training and documentation this week | 17:08 |
| kees | working through my list, basically. | 17:08 |
| kees | I have some MIRs and patch pilot work today | 17:09 |
| kees | that's about it for now. I'll have a blog post with some news later today | 17:11 |
| jdstrand | thanks kees | 17:11 |
| jdstrand | mdeslaur: you're next | 17:11 |
| mdeslaur | Ah! yes! | 17:11 |
| mdeslaur | :) | 17:11 |
| mdeslaur | I'm working on cups updates | 17:11 |
| mdeslaur | and will probably tackle ffmpeg next | 17:11 |
| jdstrand | ah, good :) | 17:11 |
| mdeslaur | I'm on community this week, although there's nothing in the queue (hint: C'mon community!) | 17:12 |
| mdeslaur | and I'll probably be spending some time with kees, there's a few things he wants to show me | 17:12 |
| mdeslaur | and...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 |
| mdeslaur | sbeattie: next! | 17:13 |
| jdstrand | s/community/community work/ | 17:13 |
| sbeattie | I'm on triage this week. | 17:13 |
| zooko | Hope I'm not interrupting, but I have a community security issue for you. | 17:13 |
| sbeattie | I'm also working on openssl. | 17:13 |
| jdstrand | zooko: can you bring it up at the end? I'll ping you | 17:14 |
| zooko | Ok | 17:14 |
| sbeattie | zooko: end should be more than another 5-10 min away | 17:14 |
| sbeattie | shouldn't be, that is | 17:14 |
| sbeattie | That's pretty much it for me. | 17:15 |
| jdstrand | micahg: you're up | 17:16 |
| micahg | ok, so I'm still cleaning up after DigiNotar, we're in week 3 of this mess | 17:17 |
| micahg | qt4-x11, thunderbird, and chromium (maybe seamonkey at the end of the week) | 17:17 |
| micahg | also, the next round of Mozilla builds should be coming soonish, will get them staged as they come | 17:18 |
| micahg | I also have patch piloting once chromium is done | 17:19 |
| micahg | that's it | 17:19 |
| jdstrand | jeez, 3 patch pilots from our team this week... | 17:19 |
| jdstrand | tyhicks: you're up | 17:20 |
| tyhicks | I 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 on | 17:20 |
| mdeslaur | \o/ | 17:20 |
| tyhicks | I've found a bug in mutt (possibly a regression from the fix mentioned above) while doing initial testing and I'll get that fixed | 17:20 |
| tyhicks | Then I plan on taking ownership of another item in the CVE queue and/or learning the triaging process | 17:21 |
| kees | nice :) | 17:21 |
| tyhicks | In the rest of the time, I've still got a small eCryptfs kernel maintainer backlog to get through | 17:21 |
| tyhicks | That's it | 17:21 |
| sbeattie | tyhicks: \o/ | 17:21 |
| jdstrand | tyhicks: sounds great :) | 17:22 |
| tyhicks | thanks, all :) | 17:22 |
| jdstrand | [TOPIC] Highlighted packages | 17:22 |
| === meetingology changed the topic of #ubuntu-meeting to: Highlighted packages | ||
| jdstrand | The 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 | http://people.canonical.com/~ubuntu-security/cve/pkg/monotone.html | 17:23 |
| jdstrand | http://people.canonical.com/~ubuntu-security/cve/pkg/ember.html | 17:23 |
| jdstrand | http://people.canonical.com/~ubuntu-security/cve/pkg/policycoreutils.html | 17:23 |
| jdstrand | http://people.canonical.com/~ubuntu-security/cve/pkg/citadel.html | 17:23 |
| jdstrand | http://people.canonical.com/~ubuntu-security/cve/pkg/xcftools.html | 17:23 |
| jdstrand | [TOPIC] Miscellaneous and Questions | 17:23 |
| === meetingology changed the topic of #ubuntu-meeting to: Miscellaneous and Questions | ||
| jdstrand | zooko: what's up? | 17:23 |
| zooko | The 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 |
| zooko | We have a fix patch, announcement text, docs, etc. but haven't divulged details to anyone yet. | 17:24 |
| jdstrand | zooko: have you filed a bug with Ubuntu yet? | 17:25 |
| zooko | The impact is moderate -- it could allow a sufficiently motivated malicious person to delete files but not to read or alter them. | 17:25 |
| zooko | No -- I'll do that within an hour or so. | 17:25 |
| jdstrand | zooko: 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' box | 17:26 |
| jdstrand | zooko: the bug will be sent to us and will be private | 17:26 |
| jdstrand | zooko: we can coordinate via the bug then | 17:26 |
| zooko | Okay. | 17:26 |
| jdstrand | Does anyone have any other questions or items to discuss? | 17:27 |
| jdstrand | alright | 17:28 |
| jdstrand | kees, mdeslaur, sbeattie, micahg, tyhicks, jjohansen, zooko: thanks! | 17:29 |
| mdeslaur | thanks jdstrand! | 17:29 |
| jdstrand | #endmeeting | 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 | ||
| meetingology | Meeting ended Mon Sep 12 17:29:12 2011 UTC. | 17:29 |
| meetingology | Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-09-12-17.04.moin.txt | 17:29 |
| zooko | :-) | 17:29 |
| micahg | thanks jdstrand | 17:29 |
| sbeattie | jdstrand: thanks! | 17:29 |
| tyhicks | jdstrand: thank you! | 17:29 |
| === ejat- is now known as ejat | ||
| * stgraber waves | 19:02 | |
| * cody-somerville waves. | 19:02 | |
| * micahg is here | 19:02 | |
| * geser waves | 19:02 | |
| cody-somerville | bdrung, persia, Laney, geser: ping | 19:02 |
| bdrung | pong | 19:02 |
| * bdrung waves back. | 19:02 | |
| micahg | Laney sent apologies | 19:02 |
| stgraber | and cyphermox asked us to postpone his application till our next meeting | 19:03 |
| cody-somerville | Great. Any volunteers for chair? | 19:04 |
| stgraber | #startmeeting Ubuntu Developer Membership Board meeting | 19:04 |
| meetingology | Meeting 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 |
| 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 |
| === 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 items | 19: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-somerville | That is slightly obnoxious new behavior, lol. | 19:05 |
| stgraber | only action was for Laney to start a thread on ubuntu-devel | 19:05 |
| stgraber | I guess we'll skip that one as he isn't around | 19:05 |
| stgraber | #topic Administrative Matters | 19: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 | ||
| stgraber | as 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_cdfc460c74495b75 | 19:06 |
| stgraber | with micahg being the winner, congrats! | 19:06 |
| micahg | thanks stgraber | 19:06 |
| geser | micahg: welcome | 19:06 |
| micahg | thanks geser | 19:06 |
| cody-somerville | I move we accept the results of the poll and forward a request to the TB to have micahg added to the DMB. | 19:07 |
| geser | who can add micahg to the private DMB list? I forgot who has the password now | 19:07 |
| stgraber | +1 | 19:07 |
| stgraber | maybe I have it, let me quickly check | 19:08 |
| stgraber | anyone who's willing to take the action of e-mailing the TB to get micahg added to the team? | 19:09 |
| ScottK | Congratulations micahg. | 19:09 |
| micahg | thanks ScottK | 19:09 |
| geser | I'll mail the TB | 19:09 |
| cody-somerville | stgraber, I recommend we vote to confirm micahg as our recommendation to the TB | 19:09 |
| stgraber | cody-somerville: ok | 19:09 |
| geser | cody-somerville: why vote? | 19:09 |
| ejat | congrate micahg | 19:09 |
| geser | cody-somerville: the dev community voted micahg and we have to accept it | 19:10 |
| cody-somerville | Because 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 | |
| micahg | geser: generally the DMB confirms the vote FWIR | 19:11 |
| stgraber | btw, I just found the DMB mailing list password ;) | 19:11 |
| micahg | for reference: http://irclogs.ubuntu.com/2011/02/14/%23ubuntu-meeting.html#t12:16 | 19:12 |
| micahg | so, no vote was done last time, just a "verbal" confirmation | 19:12 |
| cody-somerville | See, this is why we're so glad to have you join us micahg :) | 19:12 |
| micahg | heh, I come to serve :) | 19:13 |
| bdrung | micahg: then you will suffer ;) | 19:13 |
| geser | I hope the TB would speak up when we ask them to add micahg if they have any doubts about the voting process | 19:13 |
| cody-somerville | I'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 poll | 19:14 |
| stgraber | not sure if the bot understood that one :) | 19:14 |
| cody-somerville | :-) | 19:15 |
| stgraber | #action geser to e-mail the TB with the result of the poll | 19:15 |
| meetingology | ACTION: geser to e-mail the TB with the result of the poll | 19:15 |
| bdrung | :) | 19:15 |
| stgraber | #action stgraber to add micahg to the mailing-list once TB has added him to the team | 19:15 |
| meetingology | ACTION: stgraber to add micahg to the mailing-list once TB has added him to the team | 19:15 |
| stgraber | anything else we need to do to get micahg on board? | 19:15 |
| cody-somerville | We should probably ask the TB to remove Morgan, eh? | 19:15 |
| bdrung | stgraber: it's #agree not #agreed | 19:15 |
| bdrung | ups, both should be possible | 19:16 |
| geser | cody-somerville: will add it to my mail to the TB | 19:16 |
| * bdrung welcomes micahg, too. | 19:16 | |
| micahg | thanks bdrung | 19:16 |
| stgraber | cody-somerville: indeed. I'll remove her from the mailing-list when I add micahg | 19:17 |
| stgraber | jono: around? | 19:17 |
| jono | hi stgraber | 19:18 |
| stgraber | hi jono | 19:18 |
| jono | howdy | 19:18 |
| micahg | ISTR jono suggesting waiting for all the boards to come together in a single meeting | 19:18 |
| stgraber | apparently 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 |
| jono | I figured we may want to evaluate the report when we have the DMB and TB together | 19:18 |
| jono | we would likely need a joint meeting anyway | 19:18 |
| jono | so I thought it would be more efficient to organize that single meeting | 19:19 |
| cody-somerville | Is the TB really required for an initial discussion? | 19:20 |
| jono | cody-somerville, well, the topic is developer process governance, so I think they should be involved | 19:21 |
| stgraber | trying 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-mail | 19:21 |
| jono | feel free to discuss the report now though if you wish | 19:21 |
| jono | stgraber, indeed | 19:21 |
| bdrung | jono: bug in page 3? 81% are MOTUs? 81% + 2 * 32% > 100% | 19:22 |
| jono | bdrung, people could choose multiple options | 19:22 |
| jono | so be a motu and a core-dev for example | 19:22 |
| bdrung | ah, ok. | 19:22 |
| stgraber | oh, btw :) | 19:23 |
| cody-somerville | jono, 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/0L7YnAHC0MRC2cHgLlq4n5 | 19:23 |
| jono | cody-somerville, then feel free to discuss it now | 19:23 |
| jono | I am flexible | 19:24 |
| jono | :-) | 19:24 |
| cody-somerville | jono, Do you think there are any areas of concern that your survey has uncovered or confirmed? | 19:24 |
| jono | cody-somerville, sure, see the last page | 19:25 |
| jono | so, do we want to have this conversation now? | 19:26 |
| bdrung | IMHO yes | 19:26 |
| cody-somerville | Yes. | 19:26 |
| stgraber | yes | 19:27 |
| geser | jono: 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 |
| jono | ok happy to discuss now then | 19:28 |
| jono | geser, unfortunately not | 19:28 |
| jono | so in the report, take a look at the conclusions on the last pager | 19:28 |
| jono | I think those can be good points of discussion | 19:29 |
| jono | a common theme was documentation of the process and expectations | 19:29 |
| micahg | jono: should we go point by point? | 19:29 |
| jono | micahg, sure lets do that | 19:30 |
| geser | I completely agree that PPU and package sets are complete underdocumented | 19:30 |
| jono | Better Document the Per-Package Uploader Process – there was significant issues reported over the clarity and expectations of the Per-Package Uploader process. A | 19:30 |
| jono | review of the documentation and some clarity could help resolve this issue. | 19:30 |
| micahg | I don't think this is such a problem, see https://wiki.ubuntu.com/UbuntuDevelopers#Per-package_Uploaders | 19:30 |
| micahg | it looks like it's been updated | 19:30 |
| jono | micahg, maybe folks have either not seen that page or don't understand the content? | 19:31 |
| micahg | jono: that could be, people might not know where to go to see that | 19:31 |
| jono | the PPU process was the primary area of confusion in the survey | 19:31 |
| cody-somerville | FWIW, I think the survey appears highly positive. | 19:31 |
| jono | cody-somerville, totally | 19:31 |
| jono | these are just fixing little bumps in the road | 19:31 |
| jono | it seems like the MOTU side of things is pretty solid | 19:31 |
| micahg | jono: hmm, it's linked from the main DMB page | 19:31 |
| jono | when someone wants to be a dev, where do we point them? | 19:32 |
| micahg | I'd be interested in knowing where people are currently looking | 19:32 |
| jono | a place for them to learn about what core-dev, motu, and ppu is | 19:32 |
| micahg | I generally send people here: https://wiki.ubuntu.com/UbuntuDevelopers | 19:32 |
| stgraber | my 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 upload | 19:33 |
| jono | that page is way too busy | 19:33 |
| bdrung | that was my primary wiki page when i applied for upload rights | 19:33 |
| jono | I think maybe some work on that page could help simplify things | 19:33 |
| jono | it is a bit of information overload | 19:33 |
| micahg | jono: 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 |
| jono | micahg, that is my hunch | 19:34 |
| bdrung | and it lacks an picture that shows the difference between the different positions | 19:34 |
| stgraber | micahg: +1 | 19:34 |
| ScottK | I'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 |
| jono | micahg, more along the lines of https://wiki.ubuntu.com/Membership | 19:34 |
| jono | ScottK, 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 apply | 19:35 | |
| ScottK | Back when I applied to be MOTU the general (unwritten) rule was apply when someone told you to. | 19:35 |
| stgraber | ScottK: indeed, at last one case comes to mind (packages weren't even in the archive) | 19:35 |
| jono | ScottK, but is that scalable? | 19:36 |
| jono | that replies on people noticing other folks' work and advising them to apply | 19:36 |
| micahg | I had the same experience as ScottK for MOTU and for core-dev as well (application pending soon :)) | 19:36 |
| stgraber | jono: as we encourage people going through sponsors before applying for upload irghts, I think it does | 19:36 |
| jono | there is another possible option here | 19:37 |
| stgraber | jono: 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 ready | 19:37 |
| highvoltage | I'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 |
| geser | ScottK: doesn't this look too exclusive from the outside? (you can only join if a current dev member tell you) | 19:37 |
| jono | I 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 contributions | 19:37 |
| ScottK | I think that's overkill. | 19:37 |
| jono | ScottK, why? | 19:38 |
| ScottK | jono: Sorry - I was replying to highvoltage. | 19:38 |
| jono | oh I see | 19:38 |
| jono | np | 19:38 |
| highvoltage | ScottK: ok | 19:38 |
| micahg | geser: I don't think ScottK is saying that's the only way, but rather for most applicants, that's just what happens | 19:39 |
| jono | dholbach and I are using the graphs he created to identify those doing good work and ensure they get mentorship | 19:39 |
| jono | the same could be applied to identifying potential candidates for DMB review | 19:39 |
| ScottK | jono: How do you graph "good work"? | 19:39 |
| micahg | jono: singling out people for mentorship sounds good, I think for upload rights though, people need to take some initiative to get them | 19:39 |
| jono | ScottK, well, it graphs approved uploads over a period of time - so it should significant and sustained | 19:40 |
| geser | micahg: I know but do you believe that newcomers will understand it the same way as ScottK intended it? | 19:40 |
| jono | it would require a little more evaluation | 19:40 |
| cody-somerville | jono, I think improving the DMB's access to data like that would be highly positive. | 19:40 |
| jono | so let me ask a question | 19:40 |
| micahg | jono: also, if you're doing mentorship, when the mentors feel candidates ready, they'll push them appropriate towards an application | 19:40 |
| micahg | geser: well, if it's worded properly :) | 19:40 |
| jono | today 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 do | 19:40 |
| ScottK | jono: OK. I think that sort of thing is a lot more useful for member applications than developer applications. | 19:41 |
| jono | do you folks believe we should optimize the process around (2) ? | 19:41 |
| cody-somerville | No. | 19:41 |
| jono | micahg, agreed | 19:41 |
| ScottK | I would say that they should ask people who've been sponsoring them. | 19:41 |
| cody-somerville | and get endorsements, lol | 19:41 |
| ScottK | They don't necessarily need to wait or get permission, but they should ask first. | 19:41 |
| micahg | no, I think if the mentoring pieces are in place, the application encouragement will come automatically | 19:41 |
| jono | well it seems the issues highlighted in the report are not to do with when or how people apply | 19:42 |
| cody-somerville | I 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 |
| jono | it is a knowledge of how the process and expectations work | 19:42 |
| micahg | cody-somerville: +1 | 19:42 |
| ScottK | jono: I think that's a side effect of people applying too early. | 19:42 |
| jono | cody-somerville, why is that a problem? | 19:42 |
| jono | ScottK, not sure I agree - the docs could better communicate when people should apply | 19:42 |
| micahg | ScottK: +1 | 19:42 |
| ScottK | jono: Certainly. That's always the case, but I don't think that's the primary issue. | 19:43 |
| cody-somerville | jono, 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 |
| jono | cody-somerville, I don't think it matters where people work, it matters that they are good developers | 19:43 |
| cody-somerville | jono, And its highly unlikely that Canonical is able to hire ALL the best and brightest. | 19:44 |
| cody-somerville | We should look to attract others from other parts of the wider community to contribute | 19:44 |
| jono | cody-somerville, <jono> cody-somerville, I don't think it matters where people work, it matters that they are good developers | 19:44 |
| jono | :-) | 19:44 |
| micahg | jono: 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 |
| jono | right | 19:44 |
| ScottK | jono: If Ubuntu development is seen to be a predominately Canonical club, then it will hurt Ubuntu. | 19:44 |
| cody-somerville | Right. 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 |
| jono | ScottK, of course, but working at Canonical is not a reason for someone to have a more challenging application process than someone else | 19:45 |
| cody-somerville | jono, No one is suggesting that. | 19:45 |
| jono | anyway, I think we digress | 19:45 |
| ScottK | jono: No. I didn't say that. | 19:45 |
| ScottK | Please don't put words in my mouth. | 19:45 |
| jono | ScottK, I am not putting words in your mouth | 19:46 |
| ScottK | Where did I saw Canonical should have a more challenging application process? | 19:46 |
| ScottK | saw/say | 19:46 |
| jono | ScottK, I never said you did say that | 19:46 |
| jono | I was making a general point | 19:46 |
| jono | particularly as this has been a point of contention in the community in the past | 19:46 |
| ScottK | The why were you making it at me? | 19:46 |
| jono | ScottK, I wasn't | 19:46 |
| jono | ScottK, relax, it wasn't focused at you | 19:47 |
| jono | it was a general point | 19:47 |
| cody-somerville | jono, Canonical applicants do not have any harder of a time than anyone else... except there is hardly anyone else | 19:47 |
| ScottK | An odd way to make it, but whatever. | 19:47 |
| jono | cody-somerville, good stuff :-) | 19:47 |
| jono | so getting back to how devs engage in the process | 19:47 |
| jono | it sounds like there is a feeling that devs should be recommended to apply | 19:48 |
| jono | as a general rule | 19:48 |
| cody-somerville | Yes, we require all applicants to have endorsements from other developers. | 19:49 |
| stgraber | it'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 DMB | 19:49 |
| jono | do we feel we could improve the docs in recommending this approach | 19:49 |
| micahg | well, I think this is more about how it happens, than a general rule, but all applicants do need endorsements | 19:49 |
| jono | so we discourage folks to apply without a recommendation from another dev | 19:49 |
| jono | right | 19:49 |
| cody-somerville | I don't think I've seen any applications that lack endorsements. | 19:49 |
| cody-somerville | I think we need to improve the documentation for the endorsers | 19:50 |
| jono | so 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 |
| ScottK | But 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 |
| stgraber | ScottK: we get both, but ideally I wouldn't like to see the later at all... | 19:51 |
| jono | I 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 parse | 19:51 |
| jono | I would be happy to ask Daniel to do this | 19:51 |
| micahg | jono: 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 issue | 19:51 |
| micahg | or what's specifically perceived as confusing, like flowchart style, that could help the understanding | 19:52 |
| cody-somerville | stgraber, 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 |
| jono | micahg, I don't think we are going to be able to get that level of granularity, but I think the survey provides some themes | 19:52 |
| jono | e.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 process | 19:52 |
| ScottK | cody-somerville: I agree with that in theory, but there's a lot of resistance to writing anything negative on an application. | 19:52 |
| stgraber | jono: 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 |
| stgraber | cody-somerville: agreed | 19:53 |
| jono | stgraber, agreed | 19:53 |
| jono | ok, so it sounds like we have two possible actions: | 19:53 |
| stgraber | ScottK: just not writting anything would be a good start :) | 19:53 |
| jono | * restructure the wiki docs to be easier to reads | 19:53 |
| ScottK | stgraber: Agreed. | 19:53 |
| jono | * restructure the wiki docs to be easier to read | 19:53 |
| jono | * provided documentation for how to endorse someone | 19:53 |
| cody-somerville | ScottK, Negative feedback shouldn't go on the application IMHO. We need to find another way to handle that while still being transparent. | 19:54 |
| jono | I will ask Daniel to do the former, would someone volunteer to write the endorsement doc? | 19:54 |
| cody-somerville | I'm happy to write that up | 19:54 |
| jono | thanks cody-somerville | 19:54 |
| cody-somerville | along with some other stuff about being prepared | 19:54 |
| micahg | cody-somerville: yes, this issue of negative feedback has been brought up before, it was suggested to maybe use devel-permissions for that | 19:55 |
| ScottK | cody-somerville: Why not? | 19:55 |
| jono | quick q | 19:55 |
| ScottK | I think if someone feels strongly that someone is not ready to be a developer that they should be willing to say so. | 19:55 |
| jono | so 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 read | 19:55 |
| meetingology | ACTION: jono to ask Daniel to update https://wiki.ubuntu.com/UbuntuDevelopers to be easier to read | 19:55 |
| jono | (and ensure they have plenty of testimonials) | 19:55 |
| stgraber | #action cody-somerville to write some documentation on how to endorse someone | 19:56 |
| meetingology | ACTION: cody-somerville to write some documentation on how to endorse someone | 19:56 |
| jono | thanks stgraber | 19:56 |
| cody-somerville | jono, I think its already pretty clear. As I said, hardly see anyone without any endorsements at all. | 19:56 |
| jono | cody-somerville, ok sounds good | 19:56 |
| jono | well I have a meeting in a few mins, so I am going to need to run | 19:56 |
| jono | lets focus on those two actions and maybe get together at the next DMB meeting | 19:57 |
| cody-somerville | ScottK, That can be more difficult when it's someone you work with or even worse work for | 19:57 |
| jono | sound ok? | 19:57 |
| cody-somerville | Yup | 19:57 |
| ScottK | cody-somerville: I think it's reasonable to have a private channel for exceptional cases, but those should be exceptional. | 19:57 |
| stgraber | jono: 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 |
| bdrung | jono: maybe one sentence about it. ask your sponsor if you are not sure weather you are ready for applying | 19:57 |
| jono | thanks stgraber | 19:57 |
| cody-somerville | ScottK, People don't like to be negative though. And I'd rather get the feedback then not. | 19:58 |
| jono | bdrung, sound good | 19:58 |
| jono | thanks cody-somerville for working on the action | 19:58 |
| jono | bye folks | 19:58 |
| micahg | jono: thanks for coming | 19:58 |
| cody-somerville | ScottK, I think public objection should be carried heavier than private objections though (besides in exceptional circumstances). | 19:58 |
| jono | thanks micahg | 19:58 |
| ScottK | cody-somerville: I agree with that. I think the fact that good and feedback is important needs better communication. | 19:58 |
| stgraber | anything 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 |
| micahg | well, I wanted to discuss PPU along the lines of one of Laney's e-mails | 20:00 |
| stgraber | micahg: sure, let me quickly check if there's another meeting in -meeting as we're already past our reserved allocation | 20:01 |
| micahg | err, I meant package set, not PPU | 20:01 |
| stgraber | seems like we're good, no planned meetings after ours | 20:01 |
| bdrung | while 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 |
| micahg | I think having a wiki page is good as you end up with a clear presentation in the end as opposed to a bug | 20:02 |
| geser | hmm, does not being a developer count as a bug that needs fixing? :) | 20:03 |
| stgraber | I 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 |
| bdrung | a bug has the advantage of different statuses and you could set a milestone. you could reopen a bug for a deferred application. | 20:03 |
| micahg | bdrung: a wikipage is versatile, you can do whatever you want with it :) | 20:04 |
| geser | and teach the bug triagers to leave those bugs alone | 20:04 |
| * micahg certainly doesn't need another set of bugs | 20:04 | |
| bdrung | geser: it would be a separate project owned by the dmb | 20:04 |
| bdrung | developers are familiar with bug reports. | 20:05 |
| stgraber | I'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 idea | 20:05 |
| stgraber | #agreed continue discussion on Ubuntu Developer Survey Report with jono at our next meeting | 20:07 |
| bdrung | it seems that i am the only one who likes the idea of lp bugs. so i am dropping this idea. | 20:07 |
| stgraber | micahg: 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 |
| stgraber | as in, do you think there are actions we can take now on that subject? | 20:08 |
| bdrung | another 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 |
| micahg | well, 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 meeting | 20:09 |
| stgraber | bdrung: 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 packagesets | 20: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 | ||
| bdrung | stgraber: yes. having a weekly meeting leads to a quorum every two weeks too. ;) | 20:11 |
| stgraber | bdrung: 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 |
| bdrung | agreed | 20:12 |
| stgraber | bdrung: for now I think we only accumulated backlog because quite a few of us couldn't make it to the "early" meeting | 20:12 |
| geser | stgraber: 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 |
| stgraber | bdrung: not sure what's that status on the doodle, would have to poke Laney and see if we can change that meeting time | 20:13 |
| stgraber | geser: 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 set | 20:13 |
| micahg | geser: that's the issue I wanted to bring up :) | 20:14 |
| stgraber | Ideally 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 |
| stgraber | as well as the reason for its creation and the rule to update it (anything that's bazaar related for example) | 20:14 |
| micahg | stgraber: I think that would be better served as an Ubuntuwire page running a script than a static wiki page | 20:15 |
| micahg | at least for the list, the other pieces could go on the wiki | 20:15 |
| bdrung | or having the list in a bzr branch? | 20:15 |
| stgraber | micahg: 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 it | 20:15 |
| micahg | bdrung: again, that requires more work for the updater | 20:16 |
| micahg | stgraber: agreed | 20:16 |
| stgraber | bdrung: the list can be queried from the LP API | 20:16 |
| stgraber | bdrung: python edit_acl.py query -P bzr -S oneiric | 20:16 |
| stgraber | micahg: 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 |
| bdrung | stgraber: i know. i was thinking about the rules that is used as basis, e.g. containing "bzr-*" for the bzr package set | 20:18 |
| stgraber | micahg: ideally refreshed daily and available somewhere public so we can link to it from the wiki | 20:18 |
| micahg | I think geser has had more luck that I with the API | 20:18 |
| stgraber | geser: can you do that then? :) | 20:18 |
| * micahg could do it, just not before the next meeting | 20:19 | |
| stgraber | bdrung: 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 |
| stgraber | bdrung: I'd still like the general rule to be written on the wiki so people can easily find it and understand it | 20:21 |
| bdrung | stgraber: agreed on that | 20:21 |
| geser | micahg: I can help you with that if you want as I'm not sure when I'm able to find time to do it myself | 20:22 |
| stgraber | hmm, seems like we lost geser :) | 20:22 |
| stgraber | oh, no, he's back :) | 20:22 |
| micahg | geser: ok, maybe we can get it done by UDS then | 20:23 |
| stgraber | I just had a quick look at the API and I think I can get something running pretty quickly | 20:24 |
| stgraber | so I'm happy to take the action ;) | 20:24 |
| micahg | stgraber: there are already some ubuntuwire pages for packagesets as well: qa.ubuntuwire.org/mdt/mozilla.html | 20:26 |
| stgraber | #action stgraber to get the list of all package sets and their content somewhere online | 20:26 |
| meetingology | ACTION: stgraber to get the list of all package sets and their content somewhere online | 20:26 |
| stgraber | micahg: 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 |
| stgraber | anything else on package sets for this meeting? | 20:27 |
| micahg | stgraber: wgrant set those up | 20:27 |
| micahg | well, we need a process for adding and/or removing packages from a packageset | 20:28 |
| stgraber | removing 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 |
| stgraber | in 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 list | 20:30 |
| micahg | right, 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 workflow | 20:30 |
| stgraber | micahg: 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 approved | 20:32 |
| stgraber | if it's not (new mozilla product for example), then it should be discussed and approved at a DMB meeting | 20:32 |
| geser | stgraber: IIRC the mozilla PS is defined through a (build-)dependency | 20:33 |
| stgraber | that'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 documented | 20:33 |
| stgraber | geser: even better then, that's easy to check for ;) | 20:33 |
| micahg | right, makes sense, something outside the defined guidelines needs approval at the meeting | 20:34 |
| micahg | and 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 approved | 20:35 |
| geser | a 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 approved | 20:35 |
| stgraber | I 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 us | 20:35 |
| stgraber | micahg: indeed | 20:35 |
| micahg | as for workflow for adding, I was thinking an e-mail to devel-permissions requesting the change? | 20:36 |
| micahg | I think Laney mentioned something similar | 20:36 |
| geser | works for me | 20:36 |
| stgraber | micahg: 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 added | 20:37 |
| micahg | Laney's thoughts are mentioned here: https://lists.ubuntu.com/archives/technical-board/2011-September/001077.html | 20:37 |
| stgraber | cody-somerville: hey again, want me to copy/paste you what you missed? | 20:37 |
| cody-somerville | stgraber, Please. | 20:38 |
| micahg | stgraber: yep, makes sense as long it's not being handled by the archive admins | 20:38 |
| micahg | actually, scratch that | 20:38 |
| micahg | makes sense period, AA promotions have a bug filed for tracking | 20:39 |
| stgraber | cody-somerville: http://paste.ubuntu.com/687883/ | 20:39 |
| stgraber | cody-somerville: added a bit more as you left with a ping timeout | 20:39 |
| stgraber | micahg: 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 it | 20:40 |
| stgraber | micahg: but I don't think we ever need to work with the archive admins as package sets are unrelated to components | 20:41 |
| micahg | stgraber: well, once the rules are defined, why shouldn't it be an archive admin task? | 20:41 |
| geser | which non-seed based PS are TB owned? | 20:41 |
| stgraber | geser: I think kernel was one I couldn't modify | 20:41 |
| stgraber | micahg: no because they can't do it, they aren't the owner of the package set, the DMB or the TB is | 20:42 |
| micahg | stgraber: that's a technical issue | 20:42 |
| geser | the process for changing a package set owner is no fun | 20:43 |
| stgraber | micahg: 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 |
| micahg | again, a technical issue | 20:43 |
| micahg | stgraber: 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 |
| micahg | the question is who should really be doing the work | 20:44 |
| micahg | we should definitely have a workflow for ourselves in the meantime, but maybe keep in mind what the longterm goal for this should be | 20:45 |
| stgraber | I 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 it | 20:46 |
| micahg | stgraber: well, PPU has no rules defining the set, packageset does | 20:47 |
| micahg | why is it different than components | 20:47 |
| stgraber | (or the TB for the seed based ones) | 20:47 |
| micahg | once 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 |
| stgraber | micahg: 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 job | 20:48 |
| stgraber | anyway, 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 |
| micahg | stgraber: yes, sounds good | 20: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 well | 20:50 | |
| stgraber | #agreed start documenting package sets and continue discussion about our package set management workflows at our next meeting | 20:51 |
| stgraber | #topic Select a chair for the next meeting | 20: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 | ||
| stgraber | any volunteer? | 20:51 |
| micahg | o/ | 20:51 |
| stgraber | thanks micahg | 20:52 |
| stgraber | #action micahg to chair our next meeting | 20:52 |
| meetingology | ACTION: micahg to chair our next meeting | 20:52 |
| stgraber | #topic AOB | 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 | Ubuntu Developer Membership Board meeting Meeting | Current topic: AOB | ||
| stgraber | anything else? | 20:52 |
| bdrung | no | 20:52 |
| stgraber | perfect :) | 20:52 |
| stgraber | #endmeeting | 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 | ||
| meetingology | Meeting ended Mon Sep 12 20:52:53 2011 UTC. | 20:52 |
| meetingology | Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-09-12-19.04.moin.txt | 20:52 |
| stgraber | thanks everyone for attending! | 20:53 |
| micahg | sorry for talking everyone's ear off :) | 20:53 |
| micahg | thanks stgraber | 20:53 |
| micahg | stgraber: just to confirm, next meeting is 14:00 UTC on sept 26? | 20:53 |
| stgraber | micahg: 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 |
| bdrung | micahg: yes | 20:54 |
| micahg | stgraber: thanks | 20:54 |
| micahg | bdrung: thanks | 20:54 |
| bdrung | i have updated https://wiki.ubuntu.com/DeveloperMembershipBoard/NextMeeting which will be shown on the main page | 20:54 |
| stgraber | bdrung: thanks | 20:55 |
| bdrung | showing more than the next meeting time gives the applicants more choices for when they want to attend | 20:55 |
| Laney | erk | 21:24 |
| micahg | Laney: ? | 21:25 |
| stgraber | Laney: any problem? :) | 21:26 |
| Laney | I 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 |
| stgraber | Laney: 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 |
| stgraber | I think that's what we need for now, we can always try to automate more later when we feel it's needed. | 21:31 |
| Laney | they'll always have a team, by policy | 21:32 |
| Laney | so I think that might be a good place to document the definition of that particular set | 21:32 |
| Laney | if the script is just to enumerate the sets, that's fine | 21:34 |
| stgraber | yep, that's what I'm working on | 21:34 |
| stgraber | Laney: I guess we'll need to fix some package sets, I can't find a team for the package set "utouch" | 21:40 |
| Laney | yes | 21:41 |
| Laney | luckily we can fix that since it is dmb owned | 21:41 |
| stgraber | indeed | 21:41 |
| Laney | you can make ~ubuntu-utouch-uploaders and add chase to it, then swap the packageset membership | 21:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!