== Meeting information == * #ubuntu-meeting: Ubuntu Developer Membership Board, 11 Mar at 15:05 — 17:54 UTC * Full logs at [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-03-11-15.05.log.html]] == Meeting summary == ''LINK:'' https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda === Review of previous action items === The discussion about "Review of previous action items" started at 15:06. === Package Set / Per Package Uploader applications === The discussion about "Package Set / Per Package Uploader applications" started at 15:07. * ''LINK:'' https://wiki.ubuntu.com/RossGammon/PPUApplication * ''Vote:'' Rosco2 PPU for the packages he maintains in Debian (Carried) * ''Vote:'' rosco2 to gain PPU rights to carla (when NEW processed), grub2-theme-ubuntustudio, and ubuntustudio-* packages listed in his wiki page (Carried) * ''ACTION:'' cyphermox to give PPU rights to rosco2 * ''LINK:'' https://wiki.ubuntu.com/Eickmeyer/PPUApplication * ''Vote:'' to grant Rosco2 upload rights to the ubuntustudio packageset (Carried) * ''Vote:'' to grant Rosco2 upload rights to the ubuntustudio packageset (take 2) (Carried) * ''LINK:'' https://paste.ubuntu.com/p/mWwQFjzPQ3/ * ''ACTION:'' cyphermox to fix the packageset-report script * ''Vote:'' to grant Rosco2 upload rights to the packageset of { ubuntustudio } - { other flavors } (Carried) * '''Eickmeyer for PPU permissions''' (17:08) * ''LINK:'' https://wiki.ubuntu.com/Eickmeyer/PPUApplication * ''Vote:'' for granting Eickmeyer PPU rights to packages as per his application (Carried) * ''Vote:'' for granting Eickmeyer PPU rights to packages: carla, grub2-themes-ubuntustudio and ubuntustudio-* (Carried) * ''ACTION:'' cyphermox to deal with PPU rights for Rosco2 and Eickmeyer * ''LINK:'' https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Actions_after_a_successful_applications * ''ACTION:'' sil2100 to send out announcements for Rosco2 and Eickmeyer === AOB === The discussion about "AOB" started at 17:47. * ''ACTION:'' slashd to follow up on the APAC Ubuntu community coverage == Vote results == * [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-03-11-15.05.log.html#185 to grant Rosco2 upload rights to the ubuntustudio packageset]] * Deadlock (For/Against/Abstained 1/0/1) * Voters cyphermox, tsimonq2 * [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-03-11-15.05.log.html#626 for granting Eickmeyer PPU rights to packages as per his application]] * Deadlock (For/Against/Abstained 2/1/2) * Voters rbasak, slashd, sil2100, cyphermox, tsimonq2 * [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-03-11-15.05.log.html#97 Rosco2 PPU for the packages he maintains in Debian]] * Motion carried (For/Against/Abstained 4/0/1) * Voters rbasak, slashd, sil2100, cyphermox, tsimonq2 * [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-03-11-15.05.log.html#666 for granting Eickmeyer PPU rights to packages: carla, grub2-themes-ubuntustudio and ubuntustudio-*]] * Motion carried (For/Against/Abstained 3/0/2) * Voters rbasak, slashd, sil2100, cyphermox, tsimonq2 * [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-03-11-15.05.log.html#144 rosco2 to gain PPU rights to carla (when NEW processed), grub2-theme-ubuntustudio, and ubuntustudio-* packages listed in his wiki page]] * Motion carried (For/Against/Abstained 4/0/1) * Voters rbasak, slashd, sil2100, cyphermox, tsimonq2 * [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-03-11-15.05.log.html#459 to grant Rosco2 upload rights to the packageset of { ubuntustudio } - { other flavors }]] * Motion carried (For/Against/Abstained 3/1/1) * Voters rbasak, slashd, sil2100, cyphermox, tsimonq2 * [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-03-11-15.05.log.html#295 to grant Rosco2 upload rights to the ubuntustudio packageset (take 2)]] * Deadlock (For/Against/Abstained 1/0/3) * Voters rbasak, slashd, cyphermox, tsimonq2 == Action items, by person == * cyphermox * cyphermox to give PPU rights to rosco2 * cyphermox to fix the packageset-report script * cyphermox to deal with PPU rights for Rosco2 and Eickmeyer * Eickmeyer * cyphermox to deal with PPU rights for Rosco2 and Eickmeyer * sil2100 to send out announcements for Rosco2 and Eickmeyer * Rosco2 * cyphermox to deal with PPU rights for Rosco2 and Eickmeyer * sil2100 to send out announcements for Rosco2 and Eickmeyer * sil2100 * sil2100 to send out announcements for Rosco2 and Eickmeyer * slashd * slashd to follow up on the APAC Ubuntu community coverage == Done items == * (none) == People present (lines said) == * cyphermox (234) * sil2100 (161) * rbasak (160) * meetingology (77) * Rosco2 (45) * tsimonq2 (44) * Eickmeyer (35) * vorlon (31) * slashd (22) * teward (15) * Laney (11) * acheronuk (1) == Full Log == 15:05 #startmeeting Ubuntu Developer Membership Board 15:05 Meeting started Mon Mar 11 15:05:11 2019 UTC. The chair is cyphermox. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 15:05 15:05 Available commands: action commands idea info link nick 15:05 Hey all; just give me a second to look up the agenda please :) 15:05 #link https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda 15:06 #topic Review of previous action items 15:06 Oh, cyphermox took it over, thanks o/ 15:06 so; mine is done (recent packageset requests) 15:06 tsimonq2: you had "better document what we expect applicants to know" 15:07 Mine is not quite done yet, I'll have it done for next meeting. 15:07 ack 15:07 let's get to the meat of this meeting then 15:07 #topic Package Set / Per Package Uploader applications 15:07 Today we look at Rosco2 's and Eickmeyer's applications 15:08 who wants to go first? 15:08 actually 15:08 * Rosco2 nervously puts up hand 15:08 Rosco2: if you're around, you name is up first in the wiki page 15:08 cool :) 15:09 so; link to the application is here: 15:09 #link https://wiki.ubuntu.com/RossGammon/PPUApplication 15:09 Rosco2: would you like to tell us a little more about what you're applying for and all? 15:09 Yes 15:09 I have been working on Ubuntu Studio packages for a while 15:10 I would like to have permission to upload these and a few of my Debian packages 15:10 the list as written on your wiki page? 15:10 Mainly ones from the Debian Multimedia Team 15:10 Yes 15:11 Eventually I would like the US package set, but that is a good astart 15:12 ah, I was going to ask about that 15:12 do you have a timeline? 15:12 Not really, 15:12 my understanding is that the Technical Board's requirement for official flavours be that at least one developer has packageset access 15:12 Just want to be able to help out as much as possible 15:13 Then if granted I would be happy with that :-) 15:13 vorlon: ^ perhaps you're interested in this meeting as you've been in these discussions before 15:13 Could you speak to your recent activity level in Ubuntu? 15:13 Well 15:14 cyphermox: we already have the same situation for Ubuntu Budgie 15:14 cyphermox: yes, hi 15:14 sil2100: yes, I'm aware :/ 15:14 But I guess it's up to the TB to decide, maybe we should push the budgie guys as well 15:15 I want to avoid derailing the meeting and distracting from an already stressful situation for applicants, maybe we can cover that in AOB? 15:15 tsimonq2, The workload on pure US packages is normally 4/5 uploads per cycle 15:15 Sure 15:15 But the team has been much more active this cycle 15:16 Rosco2: How many uploads have you personally driven for Cosmic and Disco? 15:16 So there has been a lot more to review and test 15:16 Just counting 15:17 6? 15:17 The total packages should be 8 including 2 new. 15:17 Quite a few more have been tidyups after reviewing Erich's ^& Lens work in the team 15:18 Erich, 2 cycles includes more :-) 15:18 Ah, yes. 15:18 I understand those were also driven by others, my point is to gauge your personal involvement with those uploads. 15:19 Well - mainly reviewing the package to get it ready for upload. 15:19 Committing changes (lintian etc) and triaging bugs that might be fixable at the same time 15:20 When you're done, I have questions please 15:21 tsimonq2, more? 15:22 I'm satisfied, thabks. 15:23 Rosco2: how familiar would you say you are with respect to Ubuntu-specific development processes that don't apply to Debian? 15:23 T think I have tackled most of the possible types of uploads in Ubuntu 15:24 Mainly merges & syncs in the development release 15:24 Do you know where to look to find the freeze timetable, documentation on when you may upload what, and how to get an exception? 15:24 I have done an SRU or 3, but there hasn't been a US package needing one recently 15:25 Yes - for a while I was the Test Manager / Release Manager in US, and was sending regular reminders to the team 15:26 We followed the FFE procedure last week with the 2 new packages 15:26 Do you know about proposed migration? 15:26 (in Ubuntu) 15:26 Yes 15:26 * sil2100 has a question as well 15:26 (related) 15:26 Lmms had some problems migrating 15:27 OK, I'm done with quesetions - thanks! 15:27 Failed to build on one architecture, then was stuck due to libc transition 15:27 (but don't let me stop you expanding - that's useful to hear) 15:28 I normally check my Debian packages have moved out of proposed and try and help using execuse.tx and the new tool in archive-tools 15:28 Rosco2: so a follow up question to the one by rbasak: from the upload miner I see you had 3 SRUs in the past, but none of them seem to be 'well prepared' from the SRU POV - if you would have to prepare an SRU to a stable series for one of the US packages, what steps would you need to perform? 15:29 Well step 1 - reread the wiki :-) 15:29 Which page would that be? ;) 15:30 From memory it needs to be tested, the bug description contain the test case 15:30 Are those upload miner entries correctly categorized? They don't look like SRUs to me. 15:30 and justification (targeted changes) and discussion of regression risk 15:31 Then there is normally a requirmeent for verification of the fix before it is released 15:32 rbasak, As I said. It has been a while - I can't actually remebr which was a real SRU 15:33 rbasak: udd.debian.org? it wrongly categorises some of my uploads :/ 15:33 But I do remember doing it at least once or following along in the process. 15:33 rbasak: indeed, the dates do not match 15:33 Rosco2: thanks! 15:34 * sil2100 has no more questions 15:35 If everyone's done, ready for voting? 15:35 cyphermox? 15:36 sorry, yeah, no questions from me 15:36 let's deal with these separately; first the PPU for debian packages maintained 15:37 (and look at my bad grammar) 15:37 #vote Rosco2 PPU for the packages he maintains in Debian 15:37 Please vote on: Rosco2 PPU for the packages he maintains in Debian 15:37 Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) 15:37 +1 15:37 +1 received from sil2100 15:37 +1 15:37 +1 received from rbasak 15:37 +1 15:37 +1 received from cyphermox 15:37 jbicha sent a +1 as well. 15:38 slashd: ? 15:38 +1 15:38 +1 received from slashd 15:38 tsimonq2? 15:38 I think this is clearly a successful application anyway. 15:38 +0 15:38 +0 received from tsimonq2 15:38 :) 15:38 #endvote 15:38 Voting ended on: Rosco2 PPU for the packages he maintains in Debian 15:38 Votes for:4 Votes against:0 Abstentions:1 15:38 Motion carried 15:38 that's a motion carried indeed. 15:39 Now for the US ones? 15:39 ok; second thing to vote for: PPU for the ubuntustudio-* packages and carla, grub2-theme-ubuntustudio 15:39 point of order, please 15:39 Technically we can't grant carla yet 15:39 vorlon: yes? 15:40 I understand the application was for the list of individually named packages 15:40 yes 15:40 and I understand there are more packages than that in the ubuntustudio packageset 15:40 yep 15:40 Yes 15:40 is the DMB intending to only vote on PPU for the individually named packages, because that is what Rosco2 asked for? 15:41 I am aware of that, mentioned it earlier -- my plan, if people agree, would be to first vote for the stuff as it is in his wiki application, and then separately vote for the packageset request despite it not being on the request 15:41 ok 15:41 hm, ok 15:41 that sounds fine, I just wasn't sure the latter was also on the agenda, carry on thanks :) 15:42 that way if PPU are an easy motion carried, we don't avoid going over it discussing other things. 15:42 sil2100: rbasak: slashd: objections? 15:42 tsimonq2: ^ 15:42 Not from me. 15:42 no objections 15:43 I think that's a good plan. 15:43 I'm free for a little while meetingwise; so we could either immediately vote for packageset after or defer until after we've also looked at Erich's application (as per the agenda) 15:44 No objections 15:44 I am Ok with waiting - I am sure Erich is gewtting impatient :-) 15:44 #vote rosco2 to gain PPU rights to carla (when NEW processed), grub2-theme-ubuntustudio, and ubuntustudio-* packages listed in his wiki page 15:44 Please vote on: rosco2 to gain PPU rights to carla (when NEW processed), grub2-theme-ubuntustudio, and ubuntustudio-* packages listed in his wiki page 15:44 Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) 15:44 However we won't get a proxy vote from jbicha since he's absent and we can't consider him to be able to send a vote in advance for motions not planned in advance. 15:44 rbasak: I understand 15:44 +1 15:44 +1 received from rbasak 15:44 +1 15:44 +1 received from sil2100 15:44 +1 15:44 +1 received from slashd 15:44 +1 15:44 +1 received from cyphermox 15:44 (again, jbicha sent a +1) 15:45 +0 15:45 +0 received from tsimonq2 15:45 #endvote 15:45 Voting ended on: rosco2 to gain PPU rights to carla (when NEW processed), grub2-theme-ubuntustudio, and ubuntustudio-* packages listed in his wiki page 15:45 Votes for:4 Votes against:0 Abstentions:1 15:45 Motion carried 15:45 congrats Rosco2 15:45 Thanks very much everyone 15:45 I know Eickmeyer's waiting. 15:45 ANd thanks for all the sponsorship upto now 15:45 please stay around; let's review Eickmeyer's application right away :) 15:46 But I think Rosco2's packageset vote might eliminate the current need for urgency 15:46 I'm here. 15:46 let me take an action to set up the accesses 15:46 I agree with rbasak. 15:46 #action cyphermox to give PPU rights to rosco2 15:46 * meetingology cyphermox to give PPU rights to rosco2 15:46 To be clear, my +0s are due to not enough recent activity level in my opinion. 15:47 Eickmeyer: so; your application is here: 15:47 Otherwise I'm satisfied with Rosco2's packaging skills. 15:47 #link https://wiki.ubuntu.com/Eickmeyer/PPUApplication 15:47 cyphermox: I think Eickmeyer wants to defer to Rosco2's third vote first? 15:47 oh, is that so? 15:47 sorry I misread 15:48 okay then; 15:48 Yes. That's the more urgent matter. AFAIK, the TB needs one person on the team to have the package set, correct? 15:48 I'm not sure how well defined the requirement is against the packageset specifically, but being able to upload the packageset will surely resolve the TB's concern. 15:48 #vote to grant Rosco2 upload rights to the ubuntustudio packageset 15:48 Please vote on: to grant Rosco2 upload rights to the ubuntustudio packageset 15:48 Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) 15:49 +0 15:49 +0 received from tsimonq2 15:49 rbasak: only being able to upload themed packages is not super useful tbh 15:49 Same reasons as stated. 15:49 For reference, here is the current packageset: http://people.canonical.com/~ubuntu-archive/packagesets/disco/ubuntustudio 15:49 However the vote is for the packageset including all future changes to it. 15:49 Yes - the package set is way out of date ATM 15:49 I'm not sure debian-archive-keyring should be in there for example. 15:49 That seems really wrong. 15:50 But I think fixing that is independent of Rosco2 being able to upload to the list. 15:50 So, I know we didn't want to touch this topic here right now but it might affect my vote 15:50 +1; I see evidence of good work on packageing; the applicant is already a Debian Developer, etc. No issues. 15:50 +1; I see evidence of good work on packageing; the applicant is already a Debian Developer, etc. No issues. received from cyphermox 15:50 rbasak: debian-archive-keyring is certainly depended on by something to make it in the packageset 15:50 vorlon: from the TB POV, for ubuntu-studio to still stay as a recognized supported flavor, do they need to have people with upload rights to the whole packageset? 15:51 cyphermox: sure, that's probably how it's brought in, but it's wrong and the automatic generation should blacklist it IMHO. 15:51 sil2100: from my perspective, it needs to be "the whole packageset" as an abstraction, but I agree that the current packageset contents look odd 15:52 rbasak: (it's via apt-offline, which is a direct recommend) 15:52 Ubuntu Studio's flavor status should not affect our vote on an independent applicant's application. 15:52 sil2100: i.e.: I'd be looking for the TB to sign off that there is an uploader trusted to upload all the packages that need to be maintained for the ubuntustudio flavor to be successful 15:52 rbasak: I disagree. Seed might want to handle the package slightly differently, but I definitely don't see this as a blocker 15:52 and the details of what's actually in that packageset can be refined 15:52 cyphermox: not a blocker for this vote, but we (the DMB) should fix it. 15:53 *no* 15:53 ubuntustudio should fix their seed. 15:53 An upload of us-meta is pending. Will look into it 15:54 Rosco2: it's a bit more involved than uploading us-meta, but I can help you with this 15:54 Thnks 15:54 vorlon: what would your (TB hat) view be on packages like gimp? Do you think the flavor developer should be able to upload that? 15:54 (as a requirement) 15:54 err, why did you pick gimp in particular as your example? 15:55 Because it's very not-flavor-specific. 15:55 ubuntustudio is a flavour that is meant to let people to artsy stuff 15:55 (but clearly important to the flavor) 15:55 rbasak: it doesn't match my understanding of how it's meant to work for a common package like gimp to be something we grant upload rights on for a community flavor given that it should already be well-maintained as part of flavors in main 15:56 I concur 15:56 rbasak: however, I also think that's something that can be mediated between the flavors in case of conflict and I don't care much if that mediation takes place through the packagesets or in person-to-person discussions 15:56 There are also kubuntu packages that we tend to leave to kubuntu unless they need help 15:56 in main? 15:56 But I'm not sure that cyphermox does, for what this packageset should include. 15:56 /except/ that if there are particular packages in the packageset whose presence gives the DMB pause in +1ing, in which case we should deal with that with priority ;) 15:57 I am experiencing pause for this reason. 15:57 I am confident to +1 Rosco2 for packages in universe not maintained as part of any other flavor 15:57 I'm not sure if that currently means I'm a +1 for the packageset or not. 15:58 right, in my mind the ideal is that "Rosco2 should be trusted as an US uploader" should be severable from "US uploaders should be able to upload package $foo that is shared with other flavors" 15:58 It's a pretty huge packageset, which is why I asked the question of US maintenance requirement 15:58 I'm not sure everyone is on the same page as how flavour packagesets work. 15:58 cyphermox: agreed 15:58 ^ 15:59 In my view, flavour packageset automatic generation is secondary to what we intend them to be, and where there's a mismatch, we whitelist/blacklist packages to make it so. 15:59 AFAICT (please correct me if I'm wrong), cyphermox sees it the other way round? 15:59 these are not random lists of packages; they are an output of the seed going through germinate. Some of the packages are directly listed in the seeds, others are recommends and whatnot; and there already is some amounts of set generation that ensures common packages land expliclity in core 16:00 What's the advantage to blacklisting packages if other flavor packagesets can upload to it? 16:00 my point is we should not blacklist or whitelist things 16:00 So why isn't gimp in core? 16:00 +1 cyphermox 16:00 +1 cyphermox received from tsimonq2 16:00 wait 16:00 no 16:00 XD 16:00 because it's not in any other flavour 16:00 ok, I stand correctly 16:00 *corrected 16:00 +0 16:00 +0 received from tsimonq2 16:00 it's also in xubuntu 16:00 there 16:00 tsimonq2: yup 16:01 let me kill that off, we'll start over 16:01 #envote 16:01 #endvote 16:01 Voting ended on: to grant Rosco2 upload rights to the ubuntustudio packageset 16:01 Votes for:1 Votes against:0 Abstentions:1 16:01 Motion carried 16:01 Oh, sorry. I had assumed it was in main. 16:01 ^disregard 16:01 rbasak: that's precisely the problem with reviewing packagesets like these 16:02 we get to recognize some packages and think they ought to be in main or elsewhere. 16:03 anything that would be in main and shared would end up in core; anything else is currently free game; and I for one agree with teh current state of things 16:04 we're all adults and presumably able to handle conflicts and exercise judgement as to whether what we upload is sane and okay for other users of the packages 16:04 I have too many memories of packageset conflicts doing unexpected things. In particular with the server seed. 16:04 cyphermox: by that logic the only upload status should be core dev. 16:04 rbasak: Do you have an example? 16:04 rbasak: what? 16:05 tsimonq2: of packageset conflicts doing unexpected things? Let's not digress. 16:05 rbasak: precisely not: what I'm saying is if xubuntu and ubuntustudio have gimp in their packagesets, they're all old enough to know how to not upload things that will break stuff for one another. 16:05 ie. what we expect of an developer by way of the CoC 16:06 cyphermox: sure, but that's not a reason to eliminate the question of whether a packageset has too wide covefrage. 16:06 rbasak: It'll add to the general argument for whitelisting/blacklisting packagesm 16:06 coverage 16:06 tsimonq2: we can discuss further elsewhere, I think I know exactly what rbasak is talking about,and it's vastly different than Packageset upload rights 16:06 s/packagesm/packages./ 16:06 Alright, sounds good. 16:06 rbasak: we ask that question (too wide coverage) when we review the packageset update report. 16:06 I mean, I understand the question, but I have no issue with the packageset as it currently is 16:07 I'm comfortable with a +1 to Rosco2 for narrow coverage. 16:07 I'm not currently comfortable with giving Rosco2 wide coverage, because of his relatively little involvement recently. 16:07 are we all ready to vote? 16:07 So in deciding whether to +1 the packageset, I need to know what the packageset is intended to cover. 16:07 or do we need to further discuss this? 16:08 Really, the only thing that Ubuntu Studio really touches are the ubuntustudio-* packages and Carla at present time. Everything else is pretty much upstream. 16:08 I understand the concern, but I'm hoping we get the benefit of the doubt. 16:09 Where does everyone else stand currently? 16:09 I'm still at +0. 16:09 rbasak, I'm with you w/ narrow coverage 16:09 Or sure, run the vote and we can find out if you prefer. 16:10 Eickmeyer: ("pretty much upstream" - yes, but if you need to fix something for a release or in SRU, you can't rely on the Debian maintainers to fix it) 16:11 #vote to grant Rosco2 upload rights to the ubuntustudio packageset (take 2) 16:11 Please vote on: to grant Rosco2 upload rights to the ubuntustudio packageset (take 2) 16:11 Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) 16:11 vorlon: I understand. 16:11 +0 16:11 +0 received from rbasak 16:11 +1 16:11 +1 received from cyphermox 16:11 +0 16:11 +0 received from slashd 16:11 +0 16:11 +0 received from tsimonq2 16:11 fwiw I see packages listed in http://people.canonical.com/~ubuntu-archive/packagesets/disco/ubuntustudio that definitely *are* in main (gnome-software, langpacks) so I'm not sure how that squares with cyphermox's comments about "everything common is in core" 16:12 I'm still not entirely sure about my vote here 16:12 vorlon: I simplified it quite a bit; the exact code is at https://code.launchpad.net/~developer-membership-board/+junk/packageset 16:13 I feel that we're stuck on a technicality, but in general our sentiment does actually resolve the TB's concern. 16:13 sure, there can be improvements; but I don't see it as wrong per se. 16:13 I have some conflicting feelings: on one hand I suppose flavor maintainers *should* have upload rights to all of the components in their packageset, but the current packageset is quite big and I suppose it'll be like that because of what ubuntustudio actually is 16:13 sil2100: so +0? 16:14 What if we passed a motion agreeing that Rosco2 can upload, more narrowly, ubuntustudio-specific fixes that aren't covered by an existing flavor? 16:14 That would resolve the TB's concern I think. 16:14 Like, US will always have a lot of apps and packages in the packageset as the images come pre-installed with many many tools 16:14 And we could grant PPU as needed, which sounds unlikely anyway. 16:14 rbasak: that would require a specific list of packages 16:14 We could agree to leave that at one DMB member's discretion. 16:15 in that sense, why not bring up by ourselves a list of the packages we feel *shouldn't* be in the pacakgeset and address that? 16:15 Feels like a lot of unnecessary work for something that seems unlikely to be needed. 16:15 I don't follow 16:15 you will eventually have uploaders for the ubutnustudio pacakgeset 16:15 We'd need to find consensus on that list and that'll take considerable time. 16:16 and if you feel ubuntustudio is wrong; then you should also look at xubuntu, lubuntu, etc. 16:16 Instead, if we all trust each other to be agreed on what "narrow" means, then we could just leave it at that, and approve PPU for those things using only one DMB member, like we do for existing DD uploaders. 16:16 otoh, having to round-trip to (a member of) the DMB for each package a US developer needs to upload is onerous, and scarcely better than going through the sponsorship queue 16:16 I'm just proposing a way forward to resolve this quickly. 16:16 his current PPU request will already cover 90% 16:17 #endvote 16:17 Voting ended on: to grant Rosco2 upload rights to the ubuntustudio packageset (take 2) 16:17 Votes for:1 Votes against:0 Abstentions:3 16:17 Motion carried 16:17 meetingology: that's not a motion carried. 16:17 :) 16:17 Much quicker than going through the sponsorship queue IMHO, as a review would be unnecessary. Sponsorship in this case would be merely agreeing the PPU in principle, rather than having to round trip the TB, instead of actually having to review. 16:17 sil2100: I considered you a +0 fwiw; being unsure. 16:17 can we move on to Erich's application? 16:18 i.e. if it's not maintainable as a packageset, then there's a round trip for each package that has to be added to PPU, at exactly the time when this would cause friction for development 16:18 cyphermox: I think we should find a way forward for Rosco2 first as the urgent matter. 16:18 I believe that's what Eickmeyer wants too? 16:18 cyphermox: too bad this was introduced into the agenda so late, since I was actually starting on leaning towards +1'ing 16:18 But well 16:19 did we not already arrive at a resolution, given that he already has access to ubuntustudio-* as per earlier votes? 16:19 Yes. We need something that will satisfy the TB's requirement, otherwise 19.04 will likely get denied. 16:19 I am assuming that, given the reasons the last motion didn't carry, an equivalent motion for Eickmeyer also won't carry. 16:19 So we should spend our time trying to resolve the current flavor situation as requested by the TB as a priority 16:19 I can be back at the next meeting with a defined package set? 16:19 can I ask what the point of a packageset is that the DMB doesn't think anyone should be granted upload rights to? My understanding of packagesets is that they exist purely as objects to attach permissions to 16:19 vorlon: +1 16:20 I don't think "anyone should be" is fair here. 16:20 This is a special case. In the usual case there would be an established set of developers already able to upload the packageset. 16:20 And we would only be considering whether somebody should be added to that set. 16:21 so unless the DMB's intent is to say that US is not releasable because there are no developers qualified to have upload rights on the packageset, IMHO far better to change the contents of the packageset to match what you think the US devs should be uploading 16:21 Sure 16:21 How should we resolve that list? 16:22 The TB has some idea since that set must be sufficient to meet their requiremnts. 16:22 Is this the DMB challenging the concept of flavour packagesets as has existed up until now, or the particular (apparently) buggy entries in ubuntustudio? 16:22 I'm not sure we have any idea right now, tbh. 16:23 We seem to differ on what a packageset even means. 16:23 rbasak: speaking as a single member of the TB, I think a packageset that is the disjunction of the contents of the US image, and all other flavor images, is sufficient for the requirement 16:23 cyphermox: anyway, for the last vote count me as a +1 actually 16:23 sil2100: thanks. 16:24 (but also, as noted above, the current packageset definitely looks buggy wrt including packages from main) 16:24 Anyway, seeing the results of the vote, the motion can still pass by votes of absent members 16:25 OK, so there are two paths forward right now that I can see. 16:25 I'm +1 to give Rosco2 upload to the set that vorlon defines above. If others agree, then that is a path to resolving the current issue. 16:25 Or, we can wait to see if the absent members will pass the previous motion. 16:27 I think first and foremost people who are in disagreement with the contents of the packageset as it currently is should have a look at the packageset update script and propose fixes; or agree to give upload rights as it is with the modulo that the contents will change a bit after a review. 16:28 I don't agree. You're the one trying to pass a motion with a broken packageset. 16:28 (and ill-defined proposed correctoins to that packageset) 16:28 The bugs pointed out are likely because the script isn't handling the desktop-minimal seed, FWIW 16:28 seed*s* 16:28 possibly 16:29 rbasak: it's fine not to agree, I'm trying to point out that I'm not sure that's a way forward. your "set vorlon defines above" doesn't currently exist and isn't all that better defined. 16:29 What if we just created a secondary manual packageset so we don't need to fix the script to resolve the current situation? 16:30 rbasak: what would be the contents of it? 16:30 https://paste.ubuntu.com/p/mWwQFjzPQ3/ 16:30 With that, gnome-software ends up in ubuntu-desktop 16:30 If that fixes it, then great, thanks :) 16:30 Laney: solid. 16:31 that does sound like it would fix it. 16:31 Of course you might want to make the real patch use globs or something 16:31 yup yup 16:31 I'll take care of that 16:31 #action cyphermox to fix the packageset-report script 16:31 * meetingology cyphermox to fix the packageset-report script 16:32 By "fix", do you mean that the packageset will be intended to meet vorlon's definition above? 16:32 rbasak: let me answer you a different way 16:32 (because if so, then +1 to grant Rosco2 to that set - no need to block on that) 16:32 My issue is with how we define the packageset, rather than what it's implementation (and/or bugs) happen to be right now. 16:32 can we have a vote on granting Rosco2 packageset rights conditional on my fixing the script to everyone's satisfaction? 16:33 * Eickmeyer is going mobile 16:33 cyphermox: depends on how you/we define "fixed" 16:33 ie; we all mostly agree on the view behind the packageset, I'll fix the script, then we can review the packageset contents to make sure everyone's fine with it's new contents, and then grant access? 16:33 oh ffs 16:33 I'm not trying to be difficult! 16:34 When we grant upload to a packageset, we also grant upload to all future versions of that packageset too. 16:34 yes, I am well aware of that 16:34 What matters is what we _mean_ by allowing a packageset, not its current contents. 16:34 What I want to resolve is what we _mean_ right now. 16:34 cyphermox: there are two definitions of "fix" here. One is fixing it to not be pulling in things that are supposed to be in core; the other is that plus not pulling in things that are in other flavor packagesets 16:34 I don't care about when its implemented, and if there's a delay in implementation, I don't care, because I assume good faith. 16:34 vorlon: disagree here. 16:35 It's not exactly what vorlon said. It's { ubuntustudio } - { ubuntu U ubuntu-server U kubuntu } 16:35 and it sounds to me like there's not consensus about which of these two fixes suffices for the DMB to grant rights 16:35 I think for example, display manager bits are absolutely fine to be in the flavours that make use of them 16:35 sorry, couldn't be bothered to find the right union symbol 16:35 Laney: yes 16:35 that I fully agree with 16:35 cyphermox: yes, that you subscribe to *one* of these definitions of "fix" doesn't mean there aren't two definitions the DMB has to decide between 16:35 and tbh, you fix will likely do exactly that. 16:35 vorlon: fair enough 16:36 vote on this then? 16:36 In the general case I don't object to cyphermox's definition either. 16:36 let's try the following proposition 16:36 Just that in this particular case, I'm not confident in +1'ing right now. I expect that will change in the future after Rosco2 is more active. 16:37 "on flavour packagesets to be explicilty defined as { ubuntustudio } - { ubuntu U ubuntu-server U kubuntu } 16:37 is that acceptable enough for people to vote on? 16:37 well 16:37 argh 16:37 "on flavour packagesets to be explicilty defined as { $flavour_seed } - { ubuntu U ubuntu-server U kubuntu } 16:37 (and fwiw with my earlier comment I'm only saying that { ubuntustudio } - { all other flavors } is the MINIMUM that meets my standard; I have no opinion on whether I think that's how the DMB should define the set) 16:38 vorlon: it's okay 16:38 cyphermox: well I was going for { ubuntustudio } - { all other flavors } 16:38 cyphermox: for Rosco2 right now, rather than necessarily redefining the ubuntustudio packageset. 16:38 what about what I mentioned earlier? 16:38 what happens for seeds that share a dm? 16:38 I'm not trying to solve the general case here. 16:38 Just Rosco2 for right now. 16:39 typically they are free to maintain it; everyone has their upload rights 16:39 As a stop gap to help the flavour outl 16:39 out 16:39 The plan being that the need for this will go away as soon as Rosco2 is given further rights in the future 16:39 We can vote for that indeed 16:39 if you want to create that manual set, feel free. 16:39 can somebody else chair from now on please? 16:40 Look, I'm just one person trying to find a way forward. 16:40 I understand that 16:40 but I can't follow the meeting, so I'm asking for help 16:40 AFAICT, nobody objects to what I'm proposing. 16:40 Ok, I can pick it up 16:40 It would be possible to restructure the script to implement that concept. Make ~flavour-dev teams have upload rights to and , and then you can grant upload rights to indpendently of ~flavour-dev membership. 16:40 Except that you don't like it in the general case. 16:41 #chair sil2100 16:41 Current chairs: cyphermox sil2100 16:41 cyphermox: o/ 16:41 Ok everyone, this meeting is long overdue already 16:41 Thanks sil2100, and cyphermox for bearing with it thus far. 16:42 I'm still there too, keeping an eye on the discussion. 16:42 I'm personally fine myself with granting Rosco2 upload rights to the packageset as per previous definition (although it seemed to have a bit more packages than needed), but I suppose we could vote for the 'smaller set' now 16:43 Laney: sure, but I don't see why suddently packagesets can't remain what they have always been; and we can't just fix the obvious current bug vs. ubuntu/desktop-minimal 16:43 Vote on both things and see what passes? 16:43 I think perhaps we should disentangle what we want Rosco2 to be able to upload with technical implementation. 16:43 Should we start a vote? 16:43 sil2100: "previous definition" is too vague 16:44 ("Fix the script" needs to happen regardless) 16:44 rbasak: I don't think we should. if we can just immediately fix the packageset, why should we not just do that and give rosco2 upload rights to it (if we think he should) and be done with it 16:44 #vote to grant Rosco2 upload rights to the packageset of { ubuntustudio } - { other flavors } 16:44 Please vote on: to grant Rosco2 upload rights to the packageset of { ubuntustudio } - { other flavors } 16:44 Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) 16:44 +1 16:44 +1 received from rbasak 16:44 +0 16:44 +0 received from tsimonq2 16:44 -1 16:44 -1 received from cyphermox 16:44 cyphermox: we tried that and the motion didn't pass! 16:45 rbasak: that wasn't my understanding 16:45 we tried { give access to the packageset } 16:45 cyphermox: OK so now you're voting not give Rosco2 upload to a subset, but are +1 on the superset? How is that productive? 16:45 this needs an explanation 16:46 I'm -1 because I disagree with teh definition of that packageset. 16:46 it's vastly different than others, it's not fair for Rosco2 or other applicants. 16:46 if we redefine what a flavour packageset is, we should make it on the general case. 16:46 So personally, completely personally (and this can be *wrong*), I currently don't really care what's in the packageset currently 16:46 We grant PPU to people, which is vastly different from flavor packagesets, but we consider that acceptable. 16:47 I want to *assume* that the packageset has all the right packages for the existance of a flavor, as per vorlon's and the TB's POV 16:47 sil2100: I wholeheartedly agree. It's not *perfect* but packagesets have had small bugs from time to time and we can fix this out of band 16:47 cyphermox: I think you misunderstand my view at the moment. 16:47 Let me to make it clear. 16:47 rbasak: however PPUs are based on discreet lists of packages, not abstract sets 16:48 WHich is why I voted previously +1 on he 'previous definition' because I think Rosco2 should have access to all packages needed by Ubuntu Studio - right now it might be a too big of a set, sure, but I want him to have upload rights to the right set 16:48 we've already had to turn people away because they didn't have a list. 16:48 And to me those are two different things that I *personally* want to keep separate 16:48 The reason I am unwilling to grant the packageset, like other flavors, is that I don't think I've seen evidence of involvement at the same level as our usual norms in this particular case. 16:48 sil2100: +1 16:48 rbasak: that is a valid concern, yes 16:49 However, I am willing to grant a subset, distinct from the packageset, for now, as a stop gap to help the flavor. 16:49 rbasak: then perhaps we should process the request as any other PPU request and review a discreet list rather than voting on the abstract 16:49 * Eickmeyer is no longer mobile 16:49 rbasak: I also had the same concern but in the end I leaned towards thinking that Rosco2 has demonstrated enough to maintain studio 16:49 rbasak: but what I'm trying to say is: I understand your concern, yes 16:50 cyphermox: I'm quite happy to vote on the abstract, just as you do on abstract packagesets which is the norm. 16:50 cyphermox: if you're unwilling to vote on the abstract, then sure, generate the list and we can vote on that. 16:51 cyphermox: it just feels like extra hassle though. We can vote on abstract packagesets. Why not on a well defined subset of such a thing? 16:51 rbasak: abstract packageset which is the norm? sorry I don't understand what you mean? 16:52 when you are reviewing request for a packageset, you know what the packageset contains 16:52 you don't, because there are bugs 16:52 and the packageset changes 16:52 yes, bugs are fixable 16:52 and there will be other bugs 16:52 You know what it _currently_ contains, but that isn't the same as what you're agreeing to 16:53 any changes are reviewed by the DMB 16:53 and if we see things we don't agree with, we can always defer updating the packagesets until we've resolved the situation 16:53 ergo; I always know what is in a pacakgeset, or what is about to be. 16:54 I also don't think voting on a list of packages is an adequate compromise, because it's static and not guaranteed to give Rosco2 what he needs to maintain the image over time 16:54 and sure, there may be bugs in; but I also know what applicants won't immediately upload everything in the packageset 100 times a second 16:55 The motion above is still open. 16:55 my overarching point is: bugs are fixable, and we shouldn't block an application because there is a bug 16:55 We're in a bit of a pickle here hen 16:55 Is it just cyphermox who disagrees? 16:55 sil2100, slashd? 16:55 which is why I asked w/ TB hat for a vote on the packageset, and gave a minimum definition of a packageset that I think would satisfy the requirement 16:55 we can say: oh look, we're generally okay, but this here is going to change 16:55 vorlon: I'm happy you did 16:56 I disagreed on the exact definition, but you did say it was a minimum? 16:56 cyphermox: I'm not blocking the application on any current bug. 16:56 If you think I am, please re-read my position above. 16:56 It feels to me that you're blocking the current motion on an implementation detail. 16:56 sil2100: you want to close the vote? I'm not going to change mine. 16:56 rbasak, if we vote for Rosco2, I'm +1 to unblock him, but I totally understand rbasak's concern 16:57 or make sure everyone who should had voted. 16:57 Ok, so I can vote +1 on the current one 16:57 But of course personally I'd prefer the previous one to pass instead 16:58 +1 16:58 +1 received from slashd 16:58 I treat the current vote as a 'fallback' to get things moving 16:58 But actually 16:58 This will not get us moving 16:58 Since this one won't pass today as well 16:58 that's why I was saying that we should tentatively say it's ok or not, based on the seed-generated pacakgeset, provided it is fixed to everyone's satisfaction; at least to solve the obvious bugs in 16:59 perhaps it would be best to table this particular part and go on to vote for Eickmeyer's PPU? 16:59 cyphermox: no, I still don't think you understand my position if you believe that your proposal will work. 16:59 +1 (but I prefer the previous vote to pass) 16:59 +1 (but I prefer the previous vote to pass) received from sil2100 16:59 #endvote 16:59 Voting ended on: to grant Rosco2 upload rights to the packageset of { ubuntustudio } - { other flavors } 16:59 Votes for:3 Votes against:1 Abstentions:1 16:59 Motion carried 17:00 Motion is not carried yet ^ 17:00 Anyway, I think we won't solve this today 17:00 vorlon: ^ as you can see this is a very heated discussion, can we get an 'extension' for dealing with teh ubuntustudio situation? 17:00 Possibly till the nearest DMB meeting 17:00 we still have two meetings 17:00 (before release) 17:00 wait, was it two? 17:01 Yes 17:01 I don't think my position is worth blocking Ubuntu Studio over. 17:01 personally I think that's plenty to resolve the situation 17:02 I think the next action is to actually inform the absent DMB members of the current situation and the current votes open 17:02 sil2100: I would like to see this resolved before beta; I don't know how those dates line up 17:02 e.g. the vote for granting Rosco2 upload rights for the ubuntustudio packageset 17:02 beta is March 28, when is next DMB meeting? 17:03 So I'll switch my vote to +1 to give Rosco2 to the full packageset. 17:03 vorlon: 25th 17:03 If that changes anything. 17:03 So we should be good 17:03 25th is also beta freeze. 17:03 rbasak: I wouldn't want you to change your vote because I disagree with the other option 17:03 rbasak: I think we still miss 1 +1 in that case, so we'd have to reach out to absent members 17:04 Let's sort this out till next meeting 17:04 Not much we can do now since we're still missing one +1 17:04 I think we'll be just fine to sort it out completely before next meeting 17:04 +1 17:04 sil2100, I'm okay to give +1 based on my belief for rosco2 to do a good job 17:04 It was a very long and heated meeting 17:05 hmmm 17:05 ;) 17:05 Ok, so I could propose re-opening the previous vote, but what I would not want is for people to change their votes just for the sake of getting things moving 17:05 can we move forward instead and continue over email? 17:05 Like, I would like every DMB member to vote for what they think is correct, always 17:06 sil2100: +1 17:06 Let's move on as cyphermox proposes, we can deal with this later or through e-mail 17:06 Ok 17:06 sound good to me 17:06 you know how much I dislike the email threads for voting; but I would like for Erich's to have his PPU even if he can't have packageset yet because we can't agree 17:07 No problems - thanks all 17:08 #subtopic Eickmeyer for PPU permissions 17:08 #link https://wiki.ubuntu.com/Eickmeyer/PPUApplication 17:08 (the packages are defined in the application) 17:08 Eickmeyer: apologies for the long wait! 17:08 sil2100: No worries. I ran my son to school and back watching on Quasseldroid. :) 17:08 ;) 17:09 Eickmeyer: could you introduce yourself? 17:09 I'm Erich Eickmeyer, current council chair and de-facto project lead for Ubuntu Studio. I've been driving the project for the past year, but have been oblivious to the fact that nobody had upload permissions for the two years prior. 17:10 I had previous experience with RPM packaging and have been working on Debian packaging for said past year. 17:10 Jumped from Fedora to Ubuntu Studio when I saw the need for leadership. 17:10 Eickmeyer: \o/ 17:10 ;) 17:11 Eickmeyer: welcome, and thank you for sitting through all of this 17:11 Had previously used Ubuntu for the majority of my distro-hoppig time. :) 17:11 rbasak: Thank you. 17:11 Eickmeyer: how familiar would you say you are with respect to Ubuntu-specific development processes that don't apply to Debian? 17:12 (question time o/) 17:14 * sil2100 pokes Eickmeyer 17:14 My concern is for the Ubuntu Studio project to keep moving forward. 17:14 [end intro] 17:14 Eickmeyer: there was a question from rbasak above ^ 17:14 ;) 17:15 rbasak: Very famililar, as I'm much more keen on Ubuntu's process than Debian's process. While managing the project, I was always keeping my eye out for the feature/UI/Beta/RC freezes to make sure that we weren't going to have unfinished business before then. 17:15 Oh sorry, I had thought you were done. 17:15 Eickmeyer: OK, thanks. Do you know about proposed migration in Ubuntu? 17:16 rbasak: Vaguely. As I understand it, when a package gets uploaded it goes into proposed and then through a series of tests before landing in the archive. For new packages, that also requires a manual review. 17:17 Any other questions? 17:17 Eickmeyer: it's documented at https://wiki.ubuntu.com/ProposedMigration. The general rule is to make sure that packages you upload do migrate. 17:17 Eickmeyer, talking about proposed, what can influence/impact the release of a package in -proposed ? 17:18 (I'm done with questions - thanks) 17:18 no questions; but I do have a comment. I was asked by Erich to provide an endorsement, unfortunately I was unable to do so on time; but I do fully endorse Eickmeyer for upload rights. I haven't reviewed much, but it's consistent with the requested PPU upload rights and I am happy with the packaging quality 17:19 cyphermox, but you never sponsored him ? at least I don't see it in sponsorship miner 17:19 I have sponsored him, package is still in NEW 17:19 cyphermox, ack 17:20 I have reviewed the other packages uploaded. 17:20 slashd: From what I understand, if that package affects other packages, or has other errors, that can affect it from being migrated. 17:20 By affects I mean negatively. 17:20 Eickmeyer, how this package affect other package is reported ? and where would you look at to see it ? 17:21 slashd: The textual output of the proposed-migration scripts, correct? 17:22 ok, no more question for me 17:23 No questions for me. 17:24 Running Britney locally is a good idea too. 17:24 ^ unrelated, I recently wrote some code making thst easy. 17:24 :P 17:25 vote ? 17:25 Whoops, tsimonq2 did it again. 17:25 Ok, I think it's time to vote 17:25 #vote for granting Eickmeyer PPU rights to packages as per his application 17:25 Please vote on: for granting Eickmeyer PPU rights to packages as per his application 17:25 Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) 17:25 +0 not much uploads yet and very recent uploads (2-3 weeks old). I was about to say that he has only 1 endorsement, but he has 2 including cyphermox. I would say too early for me. 17:25 +0 not much uploads yet and very recent uploads (2-3 weeks old). I was about to say that he has only 1 endorsement, but he has 2 including cyphermox. I would say too early for me. received from slashd 17:26 -1 I'd like to see more experience with a wider variety of packages 17:26 -1 I'd like to see more experience with a wider variety of packages received from tsimonq2 17:27 +1 17:27 +1 received from rbasak 17:27 +1 17:27 +1 received from cyphermox 17:27 I'm heavily weight Rosco2's endorsement as someone who is on his team and already uploads these packages. 17:27 I heavily weight 17:28 Sorry typing ahead of thinking today 17:29 +0 I appreciate your involvement and I really think that in the nearest future you should really just have upload rights, but 5 packages are a bit not enough for me to have a good understanding of your skills 17:29 +0 I appreciate your involvement and I really think that in the nearest future you should really just have upload rights, but 5 packages are a bit not enough for me to have a good understanding of your skills received from sil2100 17:29 Oh, endorsement from cyphermox I missed 17:30 uh 17:30 Well 17:30 #endvote 17:30 Voting ended on: for granting Eickmeyer PPU rights to packages as per his application 17:30 Votes for:2 Votes against:1 Abstentions:2 17:30 Motion carried 17:31 Another vote undecided it seems ^ 17:31 Actually 17:32 hm, Eickmeyer's PPU packagelist seems odd 17:32 This is what made me confused, I guess I'm tired 17:33 Eickmeyer: so I see on your wiki application page you seem to mention the list of packages and 'Ubuntu Studio Package Set' 17:33 Oh 17:33 sil2100: Yes, the "Ubuntu Studio Package Set" is really a "hail mary" to save Ubuntu Studio. 17:33 I don't think this is supposed to be there 17:33 -1 on that, sorry. 17:33 I can remove it. 17:33 Eickmeyer: yes, please 17:34 Done 17:34 Since if we remove that, then I can be +1 on the PPU list 17:34 (with cyphermox's endorsement) 17:34 Ok, let's just re-do the vote to be sure: 17:35 my vote counted it out 17:35 (since it was obvious from before that was undecided etc etc) 17:35 #vote for granting Eickmeyer PPU rights to packages: carla, grub2-themes-ubuntustudio and ubuntustudio-* 17:35 Please vote on: for granting Eickmeyer PPU rights to packages: carla, grub2-themes-ubuntustudio and ubuntustudio-* 17:35 Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) 17:35 +1 17:35 +1 received from rbasak 17:35 +1 17:35 +1 received from cyphermox 17:36 +0 for the same reason 17:36 +0 for the same reason received from slashd 17:36 +1 you're new but with the endorsements so far, and also a +1 from Rosco, I think it's safe to say you should just be able to 'do it' 17:36 +1 you're new but with the endorsements so far, and also a +1 from Rosco, I think it's safe to say you should just be able to 'do it' received from sil2100 17:36 (since it's just a small subset of packages that you acually work on) 17:36 tsimonq2: ^ 17:37 +0 for the same reason 17:37 +0 for the same reason received from tsimonq2 17:37 #endvote 17:37 Voting ended on: for granting Eickmeyer PPU rights to packages: carla, grub2-themes-ubuntustudio and ubuntustudio-* 17:37 Votes for:3 Votes against:0 Abstentions:2 17:37 Motion carried 17:37 Ok, still undecided, but at least it's clear 17:37 that's still not a carried; yep 17:37 Eickmeyer: I think this will also have to wait till next meeting (or e-mail) 17:37 Okay. 17:37 Hang on 17:37 Ok, I think we need some action items for those 17:37 I think it is carried 17:38 rbasak: it's not 17:38 rbasak: oh? 17:38 rbasak: oh 17:38 The absentees cannot cause the motion to fail 17:38 rbasak: wait 17:38 If they both voted -1, it'd be 3-2 17:38 actually 17:38 rbasak: you are right I think! 17:38 yes 17:38 Yaay 17:38 \o/ 17:38 yay for math \o/ 17:38 ;) 17:38 well 17:38 it's iffy, but sure ;) 17:38 Eickmeyer: congratulations anyway o/ 17:38 Thanks! 17:39 \o/ 17:39 Congrats to both of you Rosco2 Eickmeyer 17:39 Now, we need action items for both Rosco2 and Eickmeyer 17:39 Now I'm just hoping for Rosco2 to get the packageset. Any chance we can be cc'd on the emails? 17:39 Reminder: action items for the announcements too, please 17:39 They have similar sets of packages, but I think we'd need 2 separate packagesets anyway 17:39 Any volunteers? 17:39 Eickmeyer: subscribe to devel-permissions@ please! 17:39 rbasak: Already subscribed. :) 17:39 sil2100: I don't think this needs separate packagesets 17:40 No packagesets - just PPU? 17:40 I mean, PPU's 17:40 if the list is the same; it can be just one especially since it's quite likely to be temporary 17:40 cyphermox: well, Rosco2 has some more 17:40 oh 17:40 in that case two yeah 17:40 cyphermox: since he has the US ones + his Debian packages 17:40 well 17:41 this is where it's a little complicated 17:41 it really should be one PPU list for debian packages 17:41 and one separate PPU list for anything else. 17:41 Could be that 17:41 cyphermox: on the other hand 17:41 (so both Erich and Ross can share that) 17:41 Huh? 17:42 What's a PPU list? 17:42 cyphermox: I see that previously we had all those personal- packagesets, so I just assumed for such custom PPUs we go the personal-* way 17:42 It's an edit-acl command per entry 17:42 rbasak: packageset 17:42 sil2100: well, we can also share such packagesets if we create one 17:42 "Where an individual has a special reason for upload rights to a large number of packages that the DMB expects to need to manage frequently, we can create a "personal packageset" for this person, named "personal-"." 17:42 I'm not sure that applies here. 17:42 cyphermox: yeah, but how would you call it? ;) 17:42 *shrugs* 17:42 cyphermox: I guess it's a bikesheding thing 17:42 ubuntustudio-tehming? 17:43 it doesn't matter much 17:43 Ah, right, we do have input-methods already 17:43 my point was the Debian packages as separate than the ubuntusutdio- 17:43 Makes sense 17:43 rbasak: ah, right 17:43 We did it for GunnarHj because of fonts-* 17:43 rbasak: you are correct, we might not even have to do that 17:43 it's only because DD PPU won't change, whereas ubuntustudio-* won't be necessary as soon as they have full flavour packageset rights 17:43 I'm not sure why fossfreedom needed it. I wasn't present at that meeting. 17:43 Anyone want to take the action for that? 17:44 creating any packageset will require TB action 17:44 cyphermox: as mentioned by rbasak, we might not need that 17:44 cyphermox: but so does adding PPU entries 17:44 rbasak: no 17:44 cyphermox: like, we can just assign PPU rights manually without a packageset 17:44 yup 17:44 cyphermox: OK. Well you should take the action to add the PPU entries without help from the TB then :-P 17:45 I was thinking ahead in terms of maintainability 17:45 So we should be good without the TB 17:45 (or at least that was my understanding?) 17:45 ie. so we don't have to do as much cleanup later, but sure, I'll take the actions 17:45 #action cyphermox to deal with PPU rights for Rosco2 and Eickmeyer 17:45 * meetingology cyphermox to deal with PPU rights for Rosco2 and Eickmeyer 17:45 cyphermox: thanks! ;) 17:45 "PPU changes or the creation of a new packageset must be done by the TB." but I was the one who wrote that documentation. 17:45 phew 17:45 thanks to you sil2100 17:46 sil2100: actions for the announcements please 17:46 rbasak: ah, indeed! 17:46 https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Actions_after_a_successful_applications 17:46 rbasak: IIRC we can add single PPUs just fine; I remember doing so before 17:46 we just can't create the packageset 17:46 cyphermox: do you want to do the announcements as well or should I do those to save you time? 17:46 sil2100: if you can please do the announcements? 17:46 I've been working on updating the packageset 17:46 +s 17:47 cyphermox: ok! 17:47 #action sil2100 to send out announcements for Rosco2 and Eickmeyer 17:47 * meetingology sil2100 to send out announcements for Rosco2 and Eickmeyer 17:47 OK! 17:47 #topic AOB 17:47 ...it's not over YET! 17:48 Time for other business, and I think teward wanted to bring something up? 17:48 I know there's already an AOB on the agenda but... *raises hand* 17:48 yeah just a suggestion/comment if I may 17:48 I understand teward has some AOB 17:48 yeah 17:49 In personal grilling by tsimonq2 to test breadth-of-knowledge ahead of a Core Dev application that I intend to file in a few weeks, it became more and more clear to me that the definition of breadth-of-knowledge requirements varies between DMB members, and is not defined for any of the upload tiers 17:49 teward: maybe you start, we'll move on to the other one afterwards 17:49 it is implied that CoreDev with full upload access would have the largest breadth of knowledge, however I would like to request that the DMB come up with more clear requirements for the varying 'tiers' of upload rights access 17:49 as there is no clear documentation, and as has been stated to me multiple times, each DMB member has their own general 'opinions' on the various requirements for the various upload tiers. 17:49 teward: that's why tsimonq2 has an action to add that to the wiki and clarify it :) 17:50 cyphermox: indeed, but I also suggest perhaps *not* giving that to Simon 17:50 Simon is currently... *looks* ... fifty documentation tasks behind due to classes/work/otherObligations 17:50 I will admit to grilling teward in a personal capacity before I advocate for him :P 17:50 hah 17:50 teward: ok; we're talking about just a single person responsible for the action though; I'm sure tsimonq2 will ask for questions when it gets to points he's not sure about :) 17:51 ack 17:51 Yup. 17:51 cyphermox: i assume then that this is a discussion point internally as well :) 17:51 teward: well, it wouldn't be just Simon doing the documentation, but we wanted him to start it off 17:51 indeed. 17:51 And then work together on the final form 17:51 As long as it's on the radar, and the breadth of knowledge is considered based on what each upload tier requires, all's good :) 17:51 teward: perhaps we hadn't made that explicit; but yeah, as per what sil2100 is saying 17:51 just wanted to get that clarification in there. 17:51 teward: thanks :) 17:51 cyphermox: indeed, the quick AOB discussion helps :) 17:51 *lurks* 17:51 yup 17:52 teward: \o/ 17:52 Ok, now slashd's topic 17:52 "DMB meeting doesn't have a good time coverage for APAC Ubuntu community. Should we add a meeting time or implicitly just process by email ?" 17:52 (it's nice when some AOB discussions're just short and easy xD) 17:52 I think we're all tired and worn off already 17:52 sil2100: I liked the suggestion of asking by email for a time that would work for them 17:52 sil2100, seyeong (my APAC colleague) will send an official request to the ML. 17:52 I'm open to showing up in the evening US time. 17:52 cyphermox, slashd: excellent 17:53 That's the middle of the night for Europe though. 17:53 I guess it's decided: we wait for an e-mail to the ML and resolve that there 17:53 tsimonq2: we'll figure something out :) 17:53 ok 17:53 sil2100, lgtm 17:53 slashd: would that be fine? Let's add an action item to check on this for next meeting 17:54 Nothing elsw from me. Who doesn't love a three hour DMB meeting? :) 17:54 sil2100, yep 17:54 *else 17:54 #action slashd to follow up on the APAC Ubuntu community coverage 17:54 * meetingology slashd to follow up on the APAC Ubuntu community coverage 17:54 Ok, I think it's time 17:54 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)