#title #ubuntu-meeting: Ubuntu Developer Membership Board meeting Meeting started by stgraber at 19:04:35 UTC. The full logs are available at http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-09-12-19.04.log.html . == Meeting summary == *Review of previous action items *Administrative Matters ''ACTION:'' geser to e-mail the TB with the result of the poll (stgraber, 19:15:11) ''ACTION:'' stgraber to add micahg to the mailing-list once TB has added him to the team (stgraber, 19:15:31) ''LINK:'' http://ubuntuone.com/0L7YnAHC0MRC2cHgLlq4n5 (stgraber, 19:23:43) ''ACTION:'' jono to ask Daniel to update https://wiki.ubuntu.com/UbuntuDevelopers to be easier to read (stgraber, 19:55:47) ''ACTION:'' cody-somerville to write some documentation on how to endorse someone (stgraber, 19:56:03) *Reduce bureaucracy around packagesets ''ACTION:'' stgraber to get the list of all package sets and their content somewhere online (stgraber, 20:26:43) *Select a chair for the next meeting ''ACTION:'' micahg to chair our next meeting (stgraber, 20:52:15) *AOB Meeting ended at 20:52:53 UTC. == Votes == == Action items == * geser to e-mail the TB with the result of the poll * stgraber to add micahg to the mailing-list once TB has added him to the team * jono to ask Daniel to update https://wiki.ubuntu.com/UbuntuDevelopers to be easier to read * cody-somerville to write some documentation on how to endorse someone * stgraber to get the list of all package sets and their content somewhere online * micahg to chair our next meeting == Action items, by person == * cody-somerville ** cody-somerville to write some documentation on how to endorse someone * geser ** geser to e-mail the TB with the result of the poll * jono ** jono to ask Daniel to update https://wiki.ubuntu.com/UbuntuDevelopers to be easier to read * micahg ** stgraber to add micahg to the mailing-list once TB has added him to the team ** micahg to chair our next meeting * stgraber ** stgraber to add micahg to the mailing-list once TB has added him to the team ** stgraber to get the list of all package sets and their content somewhere online == People present (lines said) == * stgraber (100) * jono (100) * micahg (70) * cody-somerville (36) * ScottK (26) * bdrung (23) * geser (20) * meetingology (9) * highvoltage (2) * ejat (1) == Full Log == 19:04:35 #startmeeting Ubuntu Developer Membership Board meeting 19:04:35 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:35 19:04:35 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:52 #topic Review of previous action items 19:05:10 That is slightly obnoxious new behavior, lol. 19:05:19 only action was for Laney to start a thread on ubuntu-devel 19:05:27 I guess we'll skip that one as he isn't around 19:05:46 #topic Administrative Matters 19:06:18 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:33 with micahg being the winner, congrats! 19:06:42 thanks stgraber 19:06:46 micahg: welcome 19:06:54 thanks geser 19:07:03 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:35 who can add micahg to the private DMB list? I forgot who has the password now 19:07:36 +1 19:08:47 maybe I have it, let me quickly check 19:09:07 anyone who's willing to take the action of e-mailing the TB to get micahg added to the team? 19:09:10 Congratulations micahg. 19:09:26 thanks ScottK 19:09:26 I'll mail the TB 19:09:28 stgraber, I recommend we vote to confirm micahg as our recommendation to the TB 19:09:37 cody-somerville: ok 19:09:39 cody-somerville: why vote? 19:09:43 congrate micahg 19:10:13 cody-somerville: the dev community voted micahg and we have to accept it 19:10:47 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:49 * ScottK doesn't recall such voting before. 19:11:02 geser: generally the DMB confirms the vote FWIR 19:11:42 btw, I just found the DMB mailing list password ;) 19:12:12 for reference: http://irclogs.ubuntu.com/2011/02/14/%23ubuntu-meeting.html#t12:16 19:12:36 so, no vote was done last time, just a "verbal" confirmation 19:12:53 See, this is why we're so glad to have you join us micahg :) 19:13:09 heh, I come to serve :) 19:13:24 micahg: then you will suffer ;) 19:13:44 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:49 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:14:26 #agreed micahg is the winner of the CIVS poll 19:14:50 not sure if the bot understood that one :) 19:15:05 :-) 19:15:11 #action geser to e-mail the TB with the result of the poll 19:15:11 * meetingology geser to e-mail the TB with the result of the poll 19:15:15 :) 19:15:31 #action stgraber to add micahg to the mailing-list once TB has added him to the team 19:15:31 * meetingology stgraber to add micahg to the mailing-list once TB has added him to the team 19:15:45 anything else we need to do to get micahg on board? 19:15:56 We should probably ask the TB to remove Morgan, eh? 19:15:59 stgraber: it's #agree not #agreed 19:16:12 ups, both should be possible 19:16:21 cody-somerville: will add it to my mail to the TB 19:16:43 * bdrung welcomes micahg, too. 19:16:59 thanks bdrung 19:17:04 cody-somerville: indeed. I'll remove her from the mailing-list when I add micahg 19:17:47 jono: around? 19:18:10 hi stgraber 19:18:19 hi jono 19:18:22 howdy 19:18:34 ISTR jono suggesting waiting for all the boards to come together in a single meeting 19:18:38 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:38 I figured we may want to evaluate the report when we have the DMB and TB together 19:18:58 we would likely need a joint meeting anyway 19:19:09 so I thought it would be more efficient to organize that single meeting 19:20:00 Is the TB really required for an initial discussion? 19:21:35 cody-somerville, well, the topic is developer process governance, so I think they should be involved 19:21:43 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:44 feel free to discuss the report now though if you wish 19:21:55 stgraber, indeed 19:22:08 jono: bug in page 3? 81% are MOTUs? 81% + 2 * 32% > 100% 19:22:37 bdrung, people could choose multiple options 19:22:45 so be a motu and a core-dev for example 19:22:47 ah, ok. 19:23:41 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:41 oh, btw :) 19:23:43 #link http://ubuntuone.com/0L7YnAHC0MRC2cHgLlq4n5 19:23:57 cody-somerville, then feel free to discuss it now 19:24:00 I am flexible 19:24:01 :-) 19:24:51 jono, Do you think there are any areas of concern that your survey has uncovered or confirmed? 19:25:34 cody-somerville, sure, see the last page 19:26:07 so, do we want to have this conversation now? 19:26:49 IMHO yes 19:26:53 Yes. 19:26:59 yes 19:27:05 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:28:01 ok happy to discuss now then 19:28:15 geser, unfortunately not 19:28:28 so in the report, take a look at the conclusions on the last pager 19:29:01 I think those can be good points of discussion 19:29:53 a common theme was documentation of the process and expectations 19:29:55 jono: should we go point by point? 19:30:04 micahg, sure lets do that 19:30:18 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:18 review of the documentation and some clarity could help resolve this issue. 19:30:18 I completely agree that PPU and package sets are complete underdocumented 19:30:29 I don't think this is such a problem, see https://wiki.ubuntu.com/UbuntuDevelopers#Per-package_Uploaders 19:30:35 it looks like it's been updated 19:30:59 micahg, maybe folks have either not seen that page or don't understand the content? 19:31:19 jono: that could be, people might not know where to go to see that 19:31:19 the PPU process was the primary area of confusion in the survey 19:31:20 FWIW, I think the survey appears highly positive. 19:31:29 cody-somerville, totally 19:31:39 these are just fixing little bumps in the road 19:31:50 it seems like the MOTU side of things is pretty solid 19:31:54 jono: hmm, it's linked from the main DMB page 19:32:35 when someone wants to be a dev, where do we point them? 19:32:45 I'd be interested in knowing where people are currently looking 19:32:45 a place for them to learn about what core-dev, motu, and ppu is 19:32:59 I generally send people here: https://wiki.ubuntu.com/UbuntuDevelopers 19:33:21 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:25 that page is way too busy 19:33:26 that was my primary wiki page when i applied for upload rights 19:33:33 I think maybe some work on that page could help simplify things 19:33:49 it is a bit of information overload 19:34:10 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:18 micahg, that is my hunch 19:34:19 and it lacks an picture that shows the difference between the different positions 19:34:22 micahg: +1 19:34:35 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:44 micahg, more along the lines of https://wiki.ubuntu.com/Membership 19:35:14 ScottK, how do you feel we can encourage folks to apply at the right time? 19:35:36 * micahg hasn't noticed a lack of people being told when to apply 19:35:43 Back when I applied to be MOTU the general (unwritten) rule was apply when someone told you to. 19:35:44 ScottK: indeed, at last one case comes to mind (packages weren't even in the archive) 19:36:07 ScottK, but is that scalable? 19:36:18 that replies on people noticing other folks' work and advising them to apply 19:36:27 I had the same experience as ScottK for MOTU and for core-dev as well (application pending soon :)) 19:36:32 jono: as we encourage people going through sponsors before applying for upload irghts, I think it does 19:37:08 there is another possible option here 19:37:15 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:22 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:49 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:49 ScottK: doesn't this look too exclusive from the outside? (you can only join if a current dev member tell you) 19:37:51 I think that's overkill. 19:38:07 ScottK, why? 19:38:34 jono: Sorry - I was replying to highvoltage. 19:38:39 oh I see 19:38:44 np 19:38:50 ScottK: ok 19:39:06 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:15 dholbach and I are using the graphs he created to identify those doing good work and ensure they get mentorship 19:39:32 the same could be applied to identifying potential candidates for DMB review 19:39:42 jono: How do you graph "good work"? 19:39:50 jono: singling out people for mentorship sounds good, I think for upload rights though, people need to take some initiative to get them 19:40:03 ScottK, well, it graphs approved uploads over a period of time - so it should significant and sustained 19:40:06 micahg: I know but do you believe that newcomers will understand it the same way as ScottK intended it? 19:40:14 it would require a little more evaluation 19:40:20 jono, I think improving the DMB's access to data like that would be highly positive. 19:40:29 so let me ask a question 19:40:43 jono: also, if you're doing mentorship, when the mentors feel candidates ready, they'll push them appropriate towards an application 19:40:51 geser: well, if it's worded properly :) 19:40:54 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:41:01 jono: OK. I think that sort of thing is a lot more useful for member applications than developer applications. 19:41:04 do you folks believe we should optimize the process around (2) ? 19:41:11 No. 19:41:17 micahg, agreed 19:41:35 I would say that they should ask people who've been sponsoring them. 19:41:42 and get endorsements, lol 19:41:49 They don't necessarily need to wait or get permission, but they should ask first. 19:41:58 no, I think if the mentoring pieces are in place, the application encouragement will come automatically 19:42:15 well it seems the issues highlighted in the report are not to do with when or how people apply 19:42:16 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:22 it is a knowledge of how the process and expectations work 19:42:30 cody-somerville: +1 19:42:36 jono: I think that's a side effect of people applying too early. 19:42:38 cody-somerville, why is that a problem? 19:42:57 ScottK, not sure I agree - the docs could better communicate when people should apply 19:42:59 ScottK: +1 19:43:21 jono: Certainly. That's always the case, but I don't think that's the primary issue. 19:43:22 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:45 cody-somerville, I don't think it matters where people work, it matters that they are good developers 19:44:05 jono, And its highly unlikely that Canonical is able to hire ALL the best and brightest. 19:44:16 We should look to attract others from other parts of the wider community to contribute 19:44:17 cody-somerville, cody-somerville, I don't think it matters where people work, it matters that they are good developers 19:44:17 :-) 19:44:26 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:54 right 19:44:59 jono: If Ubuntu development is seen to be a predominately Canonical club, then it will hurt Ubuntu. 19:45:00 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:28 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:37 jono, No one is suggesting that. 19:45:40 anyway, I think we digress 19:45:47 jono: No. I didn't say that. 19:45:54 Please don't put words in my mouth. 19:46:01 ScottK, I am not putting words in your mouth 19:46:21 Where did I saw Canonical should have a more challenging application process? 19:46:24 saw/say 19:46:31 ScottK, I never said you did say that 19:46:37 I was making a general point 19:46:49 particularly as this has been a point of contention in the community in the past 19:46:49 The why were you making it at me? 19:46:55 ScottK, I wasn't 19:47:02 ScottK, relax, it wasn't focused at you 19:47:10 it was a general point 19:47:17 jono, Canonical applicants do not have any harder of a time than anyone else... except there is hardly anyone else 19:47:18 An odd way to make it, but whatever. 19:47:34 cody-somerville, good stuff :-) 19:47:44 so getting back to how devs engage in the process 19:48:23 it sounds like there is a feeling that devs should be recommended to apply 19:48:29 as a general rule 19:49:03 Yes, we require all applicants to have endorsements from other developers. 19:49:07 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:26 do we feel we could improve the docs in recommending this approach 19:49:37 well, I think this is more about how it happens, than a general rule, but all applicants do need endorsements 19:49:40 so we discourage folks to apply without a recommendation from another dev 19:49:47 right 19:49:57 I don't think I've seen any applications that lack endorsements. 19:50:17 I think we need to improve the documentation for the endorsers 19:50:26 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:32 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:51:12 ScottK: we get both, but ideally I wouldn't like to see the later at all... 19:51:18 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:27 I would be happy to ask Daniel to do this 19:51:31 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:52:06 or what's specifically perceived as confusing, like flowchart style, that could help the understanding 19:52:20 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:28 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:59 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:59 cody-somerville: I agree with that in theory, but there's a lot of resistance to writing anything negative on an application. 19:53:01 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:17 cody-somerville: agreed 19:53:20 stgraber, agreed 19:53:33 ok, so it sounds like we have two possible actions: 19:53:34 ScottK: just not writting anything would be a good start :) 19:53:41 * restructure the wiki docs to be easier to reads 19:53:44 stgraber: Agreed. 19:53:45 * restructure the wiki docs to be easier to read 19:53:55 * provided documentation for how to endorse someone 19:54:00 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:10 I will ask Daniel to do the former, would someone volunteer to write the endorsement doc? 19:54:32 I'm happy to write that up 19:54:40 thanks cody-somerville 19:54:41 along with some other stuff about being prepared 19:54:59 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:03 cody-somerville: Why not? 19:55:08 quick q 19:55:29 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:40 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:47 #action jono to ask Daniel to update https://wiki.ubuntu.com/UbuntuDevelopers to be easier to read 19:55:47 * meetingology jono to ask Daniel to update https://wiki.ubuntu.com/UbuntuDevelopers to be easier to read 19:55:48 (and ensure they have plenty of testimonials) 19:56:03 #action cody-somerville to write some documentation on how to endorse someone 19:56:03 * meetingology cody-somerville to write some documentation on how to endorse someone 19:56:09 thanks stgraber 19:56:20 jono, I think its already pretty clear. As I said, hardly see anyone without any endorsements at all. 19:56:26 cody-somerville, ok sounds good 19:56:54 well I have a meeting in a few mins, so I am going to need to run 19:57:10 lets focus on those two actions and maybe get together at the next DMB meeting 19:57:11 ScottK, That can be more difficult when it's someone you work with or even worse work for 19:57:13 sound ok? 19:57:37 Yup 19:57:40 cody-somerville: I think it's reasonable to have a private channel for exceptional cases, but those should be exceptional. 19:57:45 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:48 jono: maybe one sentence about it. ask your sponsor if you are not sure weather you are ready for applying 19:57:57 thanks stgraber 19:58:03 ScottK, People don't like to be negative though. And I'd rather get the feedback then not. 19:58:06 bdrung, sound good 19:58:11 thanks cody-somerville for working on the action 19:58:16 bye folks 19:58:25 jono: thanks for coming 19:58:29 ScottK, I think public objection should be carried heavier than private objections though (besides in exceptional circumstances). 19:58:30 thanks micahg 19:58:39 cody-somerville: I agree with that. I think the fact that good and feedback is important needs better communication. 19:59:55 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? 20:00:32 well, I wanted to discuss PPU along the lines of one of Laney's e-mails 20:01:13 micahg: sure, let me quickly check if there's another meeting in -meeting as we're already past our reserved allocation 20:01:38 err, I meant package set, not PPU 20:01:45 seems like we're good, no planned meetings after ours 20:01:55 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:02:32 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:03:21 hmm, does not being a developer count as a bug that needs fixing? :) 20:03:21 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:35 a bug has the advantage of different statuses and you could set a milestone. you could reopen a bug for a deferred application. 20:04:05 bdrung: a wikipage is versatile, you can do whatever you want with it :) 20:04:10 and teach the bug triagers to leave those bugs alone 20:04:35 * micahg certainly doesn't need another set of bugs 20:04:37 geser: it would be a separate project owned by the dmb 20:05:13 developers are familiar with bug reports. 20:05:23 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:07:01 #agreed continue discussion on Ubuntu Developer Survey Report with jono at our next meeting 20:07:19 it seems that i am the only one who likes the idea of lp bugs. so i am dropping this idea. 20:08:17 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:32 as in, do you think there are actions we can take now on that subject? 20:08:40 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:09:17 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:57 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:10:51 #topic Reduce bureaucracy around packagesets 20:11:06 stgraber: yes. having a weekly meeting leads to a quorum every two weeks too. ;) 20:12:14 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:29 agreed 20:12:39 bdrung: for now I think we only accumulated backlog because quite a few of us couldn't make it to the "early" meeting 20:13:14 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:18 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:58 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:14:35 geser: that's the issue I wanted to bring up :) 20:14:36 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:58 as well as the reason for its creation and the rule to update it (anything that's bazaar related for example) 20:15:10 stgraber: I think that would be better served as an Ubuntuwire page running a script than a static wiki page 20:15:31 at least for the list, the other pieces could go on the wiki 20:15:48 or having the list in a bzr branch? 20:15:54 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:16:04 bdrung: again, that requires more work for the updater 20:16:17 stgraber: agreed 20:16:19 bdrung: the list can be queried from the LP API 20:16:57 bdrung: python edit_acl.py query -P bzr -S oneiric 20:18:17 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:20 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:34 micahg: ideally refreshed daily and available somewhere public so we can link to it from the wiki 20:18:47 I think geser has had more luck that I with the API 20:18:59 geser: can you do that then? :) 20:19:41 * micahg could do it, just not before the next meeting 20:21:00 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:18 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:58 stgraber: agreed on that 20:22:31 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:31 hmm, seems like we lost geser :) 20:22:37 oh, no, he's back :) 20:23:47 geser: ok, maybe we can get it done by UDS then 20:24:11 I just had a quick look at the API and I think I can get something running pretty quickly 20:24:21 so I'm happy to take the action ;) 20:26:04 stgraber: there are already some ubuntuwire pages for packagesets as well: qa.ubuntuwire.org/mdt/mozilla.html 20:26:43 #action stgraber to get the list of all package sets and their content somewhere online 20:26:43 * meetingology stgraber to get the list of all package sets and their content somewhere online 20:27:15 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:35 anything else on package sets for this meeting? 20:27:36 stgraber: wgrant set those up 20:28:18 well, we need a process for adding and/or removing packages from a packageset 20:29:10 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:30:10 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:36 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:32:25 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:41 if it's not (new mozilla product for example), then it should be discussed and approved at a DMB meeting 20:33:27 stgraber: IIRC the mozilla PS is defined through a (build-)dependency 20:33:41 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:53 geser: even better then, that's easy to check for ;) 20:34:10 right, makes sense, something outside the defined guidelines needs approval at the meeting 20:34:59 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:01 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:07 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:35 micahg: indeed 20:36:12 as for workflow for adding, I was thinking an e-mail to devel-permissions requesting the change? 20:36:29 I think Laney mentioned something similar 20:36:35 works for me 20:37:37 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:46 Laney's thoughts are mentioned here: https://lists.ubuntu.com/archives/technical-board/2011-September/001077.html 20:37:59 cody-somerville: hey again, want me to copy/paste you what you missed? 20:38:16 stgraber, Please. 20:38:36 stgraber: yep, makes sense as long it's not being handled by the archive admins 20:38:54 actually, scratch that 20:39:13 makes sense period, AA promotions have a bug filed for tracking 20:39:34 cody-somerville: http://paste.ubuntu.com/687883/ 20:39:46 cody-somerville: added a bit more as you left with a ping timeout 20:40:31 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:41:14 micahg: but I don't think we ever need to work with the archive admins as package sets are unrelated to components 20:41:32 stgraber: well, once the rules are defined, why shouldn't it be an archive admin task? 20:41:34 which non-seed based PS are TB owned? 20:41:54 geser: I think kernel was one I couldn't modify 20:42:15 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:27 stgraber: that's a technical issue 20:43:37 the process for changing a package set owner is no fun 20:43:50 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:51 again, a technical issue 20:44:31 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:44 the question is who should really be doing the work 20:45:45 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:46:38 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:47:08 stgraber: well, PPU has no rules defining the set, packageset does 20:47:19 why is it different than components 20:47:29 (or the TB for the seed based ones) 20:48:33 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:41 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:50:08 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:25 stgraber: yes, sounds good 20:50:41 (we're getting dangerously close to the 2 hours mark and I still have things to do this afternoon ;)) 20:50:50 * micahg has plenty to do as well 20:51:09 #agreed start documenting package sets and continue discussion about our package set management workflows at our next meeting 20:51:25 #topic Select a chair for the next meeting 20:51:33 any volunteer? 20:51:57 o/ 20:52:07 thanks micahg 20:52:15 #action micahg to chair our next meeting 20:52:15 * meetingology micahg to chair our next meeting 20:52:18 #topic AOB 20:52:29 anything else? 20:52:39 no 20:52:51 perfect :) 20:52:53 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/AlanBell/mootbot)