15:05 <cyphermox> #startmeeting Ubuntu Developer Membership Board
15:05 <meetingology> 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 <meetingology> 
15:05 <meetingology> Available commands: action commands idea info link nick
15:05 <cyphermox> Hey all; just give me a second to look up the agenda please :)
15:05 <cyphermox> #link https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
15:06 <cyphermox> #topic Review of previous action items
15:06 <sil2100> Oh, cyphermox took it over, thanks o/
15:06 <cyphermox> so; mine is done (recent packageset requests)
15:06 <cyphermox> tsimonq2: you had "better document what we expect applicants to know"
15:07 <tsimonq2> Mine is not quite done yet, I'll have it done for next meeting.
15:07 <cyphermox> ack
15:07 <cyphermox> let's get to the meat of this meeting then
15:07 <cyphermox> #topic Package Set / Per Package Uploader applications
15:07 <cyphermox> Today we look at Rosco2 's and Eickmeyer's applications
15:08 <cyphermox> who wants to go first?
15:08 <cyphermox> actually
15:08 * Rosco2 nervously puts up hand
15:08 <cyphermox> Rosco2: if you're around, you name is up first in the wiki page
15:08 <cyphermox> cool :)
15:09 <cyphermox> so; link to the application is here:
15:09 <cyphermox> #link https://wiki.ubuntu.com/RossGammon/PPUApplication
15:09 <cyphermox> Rosco2: would you like to tell us a little more about what you're applying for and all?
15:09 <Rosco2> Yes
15:09 <Rosco2> I have been working on Ubuntu Studio packages for a while
15:10 <Rosco2> I would like to have permission to upload these and a few of my Debian packages
15:10 <cyphermox> the list as written on your wiki page?
15:10 <Rosco2> Mainly ones from the Debian Multimedia Team
15:10 <Rosco2> Yes
15:11 <Rosco2> Eventually I would like the US package set, but that is a good astart
15:12 <cyphermox> ah, I was going to ask about that
15:12 <cyphermox> do you have a timeline?
15:12 <Rosco2> Not really,
15:12 <cyphermox> my understanding is that the Technical Board's requirement for official flavours be that at least one developer has packageset access
15:12 <Rosco2> Just want to be able to help out as much as possible
15:13 <Rosco2> Then if granted I would be happy with that :-)
15:13 <cyphermox> vorlon: ^ perhaps you're interested in this meeting as you've been in these discussions before
15:13 <tsimonq2> Could you speak to your recent activity level in Ubuntu?
15:13 <sil2100> Well
15:14 <sil2100> cyphermox: we already have the same situation for Ubuntu Budgie
15:14 <vorlon> cyphermox: yes, hi
15:14 <cyphermox> sil2100: yes, I'm aware :/
15:14 <sil2100> But I guess it's up to the TB to decide, maybe we should push the budgie guys as well
15:15 <cyphermox> 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 <Rosco2> tsimonq2, The workload on pure US packages is normally 4/5 uploads per cycle
15:15 <sil2100> Sure
15:15 <Rosco2> But the team has been much more active this cycle
15:16 <tsimonq2> Rosco2: How many uploads have you personally driven for Cosmic and Disco?
15:16 <Rosco2> So there has been a lot more to review and test
15:16 <Rosco2> Just counting
15:17 <Rosco2> 6?
15:17 <Eickmeyer> The total packages should be 8 including 2 new.
15:17 <Rosco2> Quite a few more have been tidyups after reviewing Erich's ^& Lens work in the team
15:18 <Rosco2> Erich, 2 cycles includes more :-)
15:18 <Eickmeyer> Ah, yes.
15:18 <tsimonq2> I understand those were also driven by others, my point is to gauge your personal involvement with those uploads.
15:19 <Rosco2> Well - mainly reviewing the package to get it ready for upload.
15:19 <Rosco2> Committing changes (lintian etc) and triaging bugs that might be fixable at the same time
15:20 <rbasak> When you're done, I have questions please
15:21 <Rosco2> tsimonq2, more?
15:22 <tsimonq2> I'm satisfied, thabks.
15:23 <rbasak> Rosco2: how familiar would you say you are with respect to Ubuntu-specific development processes that don't apply to Debian?
15:23 <Rosco2> T think I have tackled most of the possible types of uploads in Ubuntu
15:24 <Rosco2> Mainly merges & syncs in the development release
15:24 <rbasak> 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 <Rosco2> I have done an SRU or 3, but there hasn't been a US package needing one recently
15:25 <Rosco2> Yes - for a while I was the Test Manager / Release Manager in US, and was sending regular reminders to the team
15:26 <Rosco2> We followed the FFE procedure last week with the 2 new packages
15:26 <rbasak> Do you know about proposed migration?
15:26 <rbasak> (in Ubuntu)
15:26 <Rosco2> Yes
15:26 * sil2100 has a question as well
15:26 <sil2100> (related)
15:26 <Rosco2> Lmms had some problems migrating
15:27 <rbasak> OK, I'm done with quesetions - thanks!
15:27 <Rosco2> Failed to build on one architecture, then was stuck due to libc transition
15:27 <rbasak> (but don't let me stop you expanding - that's useful to hear)
15:28 <Rosco2> 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 <sil2100> 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 <Rosco2> Well step 1 - reread the wiki :-)
15:29 <sil2100> Which page would that be? ;)
15:30 <Rosco2> From memory it needs to be tested, the bug description contain the test case
15:30 <rbasak> Are those upload miner entries correctly categorized? They don't look like SRUs to me.
15:30 <Rosco2> and justification (targeted changes) and discussion of regression risk
15:31 <Rosco2> Then there is normally a requirmeent for verification of the fix before it is released
15:32 <Rosco2> rbasak, As I said. It has been a while - I can't actually remebr which was a real SRU
15:33 <acheronuk> rbasak: udd.debian.org? it wrongly categorises some of my uploads :/
15:33 <Rosco2> But I do remember doing it at least once or following along in the process.
15:33 <sil2100> rbasak: indeed, the dates do not match
15:33 <sil2100> Rosco2: thanks!
15:34 * sil2100 has no more questions
15:35 <rbasak> If everyone's done, ready for voting?
15:35 <rbasak> cyphermox?
15:36 <cyphermox> sorry, yeah, no questions from me
15:36 <cyphermox> let's deal with these separately; first the PPU for debian packages maintained
15:37 <cyphermox> (and look at my bad grammar)
15:37 <cyphermox> #vote Rosco2 PPU for the packages he maintains in Debian
15:37 <meetingology> Please vote on: Rosco2 PPU for the packages he maintains in Debian
15:37 <meetingology> 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 <sil2100> +1
15:37 <meetingology> +1 received from sil2100
15:37 <rbasak> +1
15:37 <meetingology> +1 received from rbasak
15:37 <cyphermox> +1
15:37 <meetingology> +1 received from cyphermox
15:37 <cyphermox> jbicha sent a +1 as well.
15:38 <cyphermox> slashd: ?
15:38 <slashd> +1
15:38 <meetingology> +1 received from slashd
15:38 <rbasak> tsimonq2?
15:38 <cyphermox> I think this is clearly a successful application anyway.
15:38 <tsimonq2> +0
15:38 <meetingology> +0 received from tsimonq2
15:38 <tsimonq2> :)
15:38 <cyphermox> #endvote
15:38 <meetingology> Voting ended on: Rosco2 PPU for the packages he maintains in Debian
15:38 <meetingology> Votes for:4 Votes against:0 Abstentions:1
15:38 <meetingology> Motion carried
15:38 <cyphermox> that's a motion carried indeed.
15:39 <sil2100> Now for the US ones?
15:39 <cyphermox> ok; second thing to vote for: PPU for the ubuntustudio-* packages and carla, grub2-theme-ubuntustudio
15:39 <vorlon> point of order, please
15:39 <rbasak> Technically we can't grant carla yet
15:39 <cyphermox> vorlon: yes?
15:40 <vorlon> I understand the application was for the list of individually named packages
15:40 <cyphermox> yes
15:40 <vorlon> and I understand there are more packages than that in the ubuntustudio packageset
15:40 <cyphermox> yep
15:40 <sil2100> Yes
15:40 <vorlon> is the DMB intending to only vote on PPU for the individually named packages, because that is what Rosco2 asked for?
15:41 <cyphermox> 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 <vorlon> ok
15:41 <sil2100> hm, ok
15:41 <vorlon> that sounds fine, I just wasn't sure the latter was also on the agenda, carry on thanks :)
15:42 <cyphermox> that way if PPU are an easy motion carried, we don't avoid going over it discussing other things.
15:42 <cyphermox> sil2100: rbasak: slashd: objections?
15:42 <cyphermox> tsimonq2: ^
15:42 <tsimonq2> Not from me.
15:42 <slashd> no objections
15:43 <rbasak> I think that's a good plan.
15:43 <cyphermox> 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 <sil2100> No objections
15:44 <Rosco2> I am Ok with waiting - I am sure Erich is gewtting impatient :-)
15:44 <cyphermox> #vote rosco2 to gain PPU rights to carla (when NEW processed), grub2-theme-ubuntustudio, and ubuntustudio-* packages listed in his wiki page
15:44 <meetingology> 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 <meetingology> 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 <rbasak> 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 <cyphermox> rbasak: I understand
15:44 <rbasak> +1
15:44 <meetingology> +1 received from rbasak
15:44 <sil2100> +1
15:44 <meetingology> +1 received from sil2100
15:44 <slashd> +1
15:44 <meetingology> +1 received from slashd
15:44 <cyphermox> +1
15:44 <meetingology> +1 received from cyphermox
15:44 <cyphermox> (again, jbicha sent a +1)
15:45 <tsimonq2> +0
15:45 <meetingology> +0 received from tsimonq2
15:45 <cyphermox> #endvote
15:45 <meetingology> 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 <meetingology> Votes for:4 Votes against:0 Abstentions:1
15:45 <meetingology> Motion carried
15:45 <cyphermox> congrats Rosco2
15:45 <Rosco2> Thanks very much everyone
15:45 <rbasak> I know Eickmeyer's waiting.
15:45 <Rosco2> ANd thanks for all the sponsorship upto now
15:45 <cyphermox> please stay around; let's review Eickmeyer's application right away :)
15:46 <rbasak> But I think Rosco2's packageset vote might eliminate the current need for urgency
15:46 <Eickmeyer> I'm here.
15:46 <cyphermox> let me take an action to set up the accesses
15:46 <Eickmeyer> I agree with rbasak.
15:46 <cyphermox> #action cyphermox to give PPU rights to rosco2
15:46 * meetingology cyphermox to give PPU rights to rosco2
15:46 <tsimonq2> To be clear, my +0s are due to not enough recent activity level in my opinion.
15:47 <cyphermox> Eickmeyer: so; your application is here:
15:47 <tsimonq2> Otherwise I'm satisfied with Rosco2's packaging skills.
15:47 <cyphermox> #link https://wiki.ubuntu.com/Eickmeyer/PPUApplication
15:47 <rbasak> cyphermox: I think Eickmeyer wants to defer to Rosco2's third vote first?
15:47 <cyphermox> oh, is that so?
15:47 <cyphermox> sorry I misread
15:48 <cyphermox> okay then;
15:48 <Eickmeyer> Yes. That's the more urgent matter. AFAIK, the TB needs one person on the team to have the package set, correct?
15:48 <rbasak> 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 <cyphermox> #vote to grant Rosco2 upload rights to the ubuntustudio packageset
15:48 <meetingology> Please vote on: to grant Rosco2 upload rights to the ubuntustudio packageset
15:48 <meetingology> 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 <tsimonq2> +0
15:49 <meetingology> +0 received from tsimonq2
15:49 <cyphermox> rbasak: only being able to upload themed packages is not super useful tbh
15:49 <tsimonq2> Same reasons as stated.
15:49 <rbasak> For reference, here is the current packageset: http://people.canonical.com/~ubuntu-archive/packagesets/disco/ubuntustudio
15:49 <rbasak> However the vote is for the packageset including all future changes to it.
15:49 <Rosco2> Yes - the package set is way out of date ATM
15:49 <rbasak> I'm not sure debian-archive-keyring should be in there for example.
15:49 <rbasak> That seems really wrong.
15:50 <rbasak> But I think fixing that is independent of Rosco2 being able to upload to the list.
15:50 <sil2100> So, I know we didn't want to touch this topic here right now but it might affect my vote
15:50 <cyphermox> +1; I see evidence of good work on packageing; the applicant is already a Debian Developer, etc. No issues.
15:50 <meetingology> +1; I see evidence of good work on packageing; the applicant is already a Debian Developer, etc. No issues. received from cyphermox
15:50 <cyphermox> rbasak: debian-archive-keyring is certainly depended on by something to make it in the packageset
15:50 <sil2100> 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 <rbasak> cyphermox: sure, that's probably how it's brought in, but it's wrong and the automatic generation should blacklist it IMHO.
15:51 <vorlon> 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 <cyphermox> rbasak: (it's via apt-offline, which is a direct recommend)
15:52 <tsimonq2> Ubuntu Studio's flavor status should not affect our vote on an independent applicant's application.
15:52 <vorlon> 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 <cyphermox> rbasak: I disagree. Seed might want to handle the package slightly differently, but I definitely don't see this as a blocker
15:52 <vorlon> and the details of what's actually in that packageset can be refined
15:52 <rbasak> cyphermox: not a blocker for this vote, but we (the DMB) should fix it.
15:53 <cyphermox> *no*
15:53 <cyphermox> ubuntustudio should fix their seed.
15:53 <Rosco2> An upload of us-meta is pending. Will look into it
15:54 <cyphermox> Rosco2: it's a bit more involved than uploading us-meta, but I can help you with this
15:54 <Rosco2> Thnks
15:54 <rbasak> 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 <rbasak> (as a requirement)
15:54 <cyphermox> err, why did you pick gimp in particular as your example?
15:55 <rbasak> Because it's very not-flavor-specific.
15:55 <cyphermox> ubuntustudio is a flavour that is meant to let people to artsy stuff
15:55 <rbasak> (but clearly important to the flavor)
15:55 <vorlon> 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 <rbasak> I concur
15:56 <vorlon> 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 <Rosco2> There are also kubuntu packages that we tend to leave to kubuntu unless they need help
15:56 <cyphermox> in main?
15:56 <rbasak> But I'm not sure that cyphermox does, for what this packageset should include.
15:56 <vorlon> /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 <rbasak> I am experiencing pause for this reason.
15:57 <rbasak> I am confident to +1 Rosco2 for packages in universe not maintained as part of any other flavor
15:57 <rbasak> I'm not sure if that currently means I'm a +1 for the packageset or not.
15:58 <vorlon> 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 <sil2100> It's a pretty huge packageset, which is why I asked the question of US maintenance requirement
15:58 <cyphermox> I'm not sure everyone is on the same page as how flavour packagesets work.
15:58 <rbasak> cyphermox: agreed
15:58 <tsimonq2> ^
15:59 <rbasak> 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 <rbasak> AFAICT (please correct me if I'm wrong), cyphermox sees it the other way round?
15:59 <cyphermox> 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 <tsimonq2> What's the advantage to blacklisting packages if other flavor packagesets can upload to it?
16:00 <cyphermox> my point is we should not blacklist or whitelist things
16:00 <rbasak> So why isn't gimp in core?
16:00 <tsimonq2> +1 cyphermox
16:00 <meetingology> +1 cyphermox received from tsimonq2
16:00 <tsimonq2> wait
16:00 <tsimonq2> no
16:00 <tsimonq2> XD
16:00 <cyphermox> because it's not in any other flavour
16:00 <cyphermox> ok, I stand correctly
16:00 <cyphermox> *corrected
16:00 <tsimonq2> +0
16:00 <meetingology> +0 received from tsimonq2
16:00 <cyphermox> it's also in xubuntu
16:00 <tsimonq2> there
16:00 <cyphermox> tsimonq2: yup
16:01 <cyphermox> let me kill that off, we'll start over
16:01 <cyphermox> #envote
16:01 <cyphermox> #endvote
16:01 <meetingology> Voting ended on: to grant Rosco2 upload rights to the ubuntustudio packageset
16:01 <meetingology> Votes for:1 Votes against:0 Abstentions:1
16:01 <meetingology> Motion carried
16:01 <rbasak> Oh, sorry. I had assumed it was in main.
16:01 <cyphermox> ^disregard
16:01 <cyphermox> rbasak: that's precisely the problem with reviewing packagesets like these
16:02 <cyphermox> we get to recognize some packages and think they ought to be in main or elsewhere.
16:03 <cyphermox> 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 <cyphermox> 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 <rbasak> I have too many memories of packageset conflicts doing unexpected things. In particular with the server seed.
16:04 <rbasak> cyphermox: by that logic the only upload status should be core dev.
16:04 <tsimonq2> rbasak: Do you have an example?
16:04 <cyphermox> rbasak: what?
16:05 <rbasak> tsimonq2: of packageset conflicts doing unexpected things? Let's not digress.
16:05 <cyphermox> 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 <cyphermox> ie. what we expect of an developer by way of the CoC
16:06 <rbasak> cyphermox: sure, but that's not a reason to eliminate the question of whether a packageset has too wide covefrage.
16:06 <tsimonq2> rbasak: It'll add to the general argument for whitelisting/blacklisting packagesm
16:06 <rbasak> coverage
16:06 <cyphermox> 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 <tsimonq2> s/packagesm/packages./
16:06 <tsimonq2> Alright, sounds good.
16:06 <cyphermox> rbasak: we ask that question (too wide coverage) when we review the packageset update report.
16:06 <cyphermox> I mean, I understand the question, but I have no issue with the packageset as it currently is
16:07 <rbasak> I'm comfortable with a +1 to Rosco2 for narrow coverage.
16:07 <rbasak> I'm not currently comfortable with giving Rosco2 wide coverage, because of his relatively little involvement recently.
16:07 <cyphermox> are we all ready to vote?
16:07 <rbasak> So in deciding whether to +1 the packageset, I need to know what the packageset is intended to cover.
16:07 <cyphermox> or do we need to further discuss this?
16:08 <Eickmeyer> 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 <Eickmeyer> I understand the concern, but I'm hoping we get the benefit of the doubt.
16:09 <rbasak> Where does everyone else stand currently?
16:09 <tsimonq2> I'm still at +0.
16:09 <slashd> rbasak, I'm with you w/ narrow coverage
16:09 <rbasak> Or sure, run the vote and we can find out if you prefer.
16:10 <vorlon> 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 <cyphermox> #vote to grant Rosco2 upload rights to the ubuntustudio packageset (take 2)
16:11 <meetingology> Please vote on: to grant Rosco2 upload rights to the ubuntustudio packageset (take 2)
16:11 <meetingology> 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 <Eickmeyer> vorlon: I understand.
16:11 <rbasak> +0
16:11 <meetingology> +0 received from rbasak
16:11 <cyphermox> +1
16:11 <meetingology> +1 received from cyphermox
16:11 <slashd> +0
16:11 <meetingology> +0 received from slashd
16:11 <tsimonq2> +0
16:11 <meetingology> +0 received from tsimonq2
16:11 <vorlon> 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 <sil2100> I'm still not entirely sure about my vote here
16:12 <cyphermox> vorlon: I simplified it quite a bit; the exact code is at https://code.launchpad.net/~developer-membership-board/+junk/packageset
16:13 <rbasak> I feel that we're stuck on a technicality, but in general our sentiment does actually resolve the TB's concern.
16:13 <cyphermox> sure, there can be improvements; but I don't see it as wrong per se.
16:13 <sil2100> 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 <cyphermox> sil2100: so +0?
16:14 <rbasak> 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 <rbasak> That would resolve the TB's concern I think.
16:14 <sil2100> 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 <rbasak> And we could grant PPU as needed, which sounds unlikely anyway.
16:14 <cyphermox> rbasak: that would require a specific list of packages
16:14 <rbasak> We could agree to leave that at one DMB member's discretion.
16:15 <cyphermox> 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 <rbasak> Feels like a lot of unnecessary work for something that seems unlikely to be needed.
16:15 <cyphermox> I don't follow
16:15 <cyphermox> you will eventually have uploaders for the ubutnustudio pacakgeset
16:15 <rbasak> We'd need to find consensus on that list and that'll take considerable time.
16:16 <cyphermox> and if you feel ubuntustudio is wrong; then you should also look at xubuntu, lubuntu, etc.
16:16 <rbasak> 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 <vorlon> 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 <rbasak> I'm just proposing a way forward to resolve this quickly.
16:16 <cyphermox> his current PPU request will already cover 90%
16:17 <cyphermox> #endvote
16:17 <meetingology> Voting ended on: to grant Rosco2 upload rights to the ubuntustudio packageset (take 2)
16:17 <meetingology> Votes for:1 Votes against:0 Abstentions:3
16:17 <meetingology> Motion carried
16:17 <cyphermox> meetingology: that's not a motion carried.
16:17 <vorlon> :)
16:17 <rbasak> 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 <cyphermox> sil2100: I considered you a +0 fwiw; being unsure.
16:17 <cyphermox> can we move on to Erich's application?
16:18 <vorlon> 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 <rbasak> cyphermox: I think we should find a way forward for Rosco2 first as the urgent matter.
16:18 <rbasak> I believe that's what Eickmeyer wants too?
16:18 <sil2100> cyphermox: too bad this was introduced into the agenda so late, since I was actually starting on leaning towards +1'ing
16:18 <sil2100> But well
16:19 <cyphermox> did we not already arrive at a resolution, given that he already has access to ubuntustudio-* as per earlier votes?
16:19 <Eickmeyer> Yes. We need something that will satisfy the TB's requirement, otherwise 19.04 will likely get denied.
16:19 <rbasak> I am assuming that, given the reasons the last motion didn't carry, an equivalent motion for Eickmeyer also won't carry.
16:19 <rbasak> So we should spend our time trying to resolve the current flavor situation as requested by the TB as a priority
16:19 <Rosco2> I can be back at the next meeting with a defined package set?
16:19 <vorlon> 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 <cyphermox> vorlon: +1
16:20 <rbasak> I don't think "anyone should be" is fair here.
16:20 <rbasak> 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 <rbasak> And we would only be considering whether somebody should be added to that set.
16:21 <vorlon> 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 <rbasak> Sure
16:21 <rbasak> How should we resolve that list?
16:22 <rbasak> The TB has some idea since that set must be sufficient to meet their requiremnts.
16:22 <Laney> 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 <rbasak> I'm not sure we have any idea right now, tbh.
16:23 <rbasak> We seem to differ on what a packageset even means.
16:23 <vorlon> 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 <sil2100> cyphermox: anyway, for the last vote count me as a +1 actually
16:23 <cyphermox> sil2100: thanks.
16:24 <vorlon> (but also, as noted above, the current packageset definitely looks buggy wrt including packages from main)
16:24 <sil2100> Anyway, seeing the results of the vote, the motion can still pass by votes of absent members
16:25 <rbasak> OK, so there are two paths forward right now that I can see.
16:25 <rbasak> 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 <rbasak> Or, we can wait to see if the absent members will pass the previous motion.
16:27 <cyphermox> 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 <rbasak> I don't agree. You're the one trying to pass a motion with a broken packageset.
16:28 <rbasak> (and ill-defined proposed correctoins to that packageset)
16:28 <Laney> The bugs pointed out are likely because the script isn't handling the desktop-minimal seed, FWIW
16:28 <Laney> seed*s*
16:28 <cyphermox> possibly
16:29 <cyphermox> 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 <rbasak> 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 <cyphermox> rbasak: what would be the contents of it?
16:30 <Laney> https://paste.ubuntu.com/p/mWwQFjzPQ3/
16:30 <Laney> With that, gnome-software ends up in ubuntu-desktop
16:30 <rbasak> If that fixes it, then great, thanks :)
16:30 <cyphermox> Laney: solid.
16:31 <cyphermox> that does sound like it would fix it.
16:31 <Laney> Of course you might want to make the real patch use globs or something
16:31 <cyphermox> yup yup
16:31 <cyphermox> I'll take care of that
16:31 <cyphermox> #action cyphermox to fix the packageset-report script
16:31 * meetingology cyphermox to fix the packageset-report script
16:32 <rbasak> By "fix", do you mean that the packageset will be intended to meet vorlon's definition above?
16:32 <cyphermox> rbasak: let me answer you a different way
16:32 <rbasak> (because if so, then +1 to grant Rosco2 to that set - no need to block on that)
16:32 <rbasak> 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 <cyphermox> 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 <rbasak> cyphermox: depends on how you/we define "fixed"
16:33 <cyphermox> 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 <cyphermox> oh ffs
16:33 <rbasak> I'm not trying to be difficult!
16:34 <rbasak> When we grant upload to a packageset, we also grant upload to all future versions of that packageset too.
16:34 <cyphermox> yes, I am well aware of that
16:34 <rbasak> What matters is what we _mean_ by allowing a packageset, not its current contents.
16:34 <rbasak> What I want to resolve is what we _mean_ right now.
16:34 <vorlon> 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 <rbasak> 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 <cyphermox> vorlon: disagree here.
16:35 <Laney> It's not exactly what vorlon said. It's { ubuntustudio } - { ubuntu U ubuntu-server U kubuntu }
16:35 <vorlon> 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 <cyphermox> I think for example, display manager bits are absolutely fine to be in the flavours that make use of them
16:35 <Laney> sorry, couldn't be bothered to find the right union symbol
16:35 <cyphermox> Laney: yes
16:35 <cyphermox> that I fully agree with
16:35 <vorlon> 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 <cyphermox> and tbh, you fix will likely do exactly that.
16:35 <cyphermox> vorlon: fair enough
16:36 <cyphermox> vote on this then?
16:36 <rbasak> In the general case I don't object to cyphermox's definition either.
16:36 <cyphermox> let's try the following proposition
16:36 <rbasak> 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 <cyphermox> "on flavour packagesets to be explicilty defined as { ubuntustudio } - { ubuntu U  ubuntu-server U kubuntu }
16:37 <cyphermox> is that acceptable enough for people to vote on?
16:37 <cyphermox> well
16:37 <cyphermox> argh
16:37 <cyphermox> "on flavour packagesets to be explicilty defined as { $flavour_seed } - { ubuntu U  ubuntu-server U kubuntu }
16:37 <vorlon> (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 <cyphermox> vorlon: it's okay
16:38 <rbasak> cyphermox: well I was going for { ubuntustudio } - { all other flavors }
16:38 <rbasak> cyphermox: for Rosco2 right now, rather than necessarily redefining the ubuntustudio packageset.
16:38 <cyphermox> what about what I mentioned earlier?
16:38 <cyphermox> what happens for seeds that share a dm?
16:38 <rbasak> I'm not trying to solve the general case here.
16:38 <rbasak> Just Rosco2 for right now.
16:39 <cyphermox> typically they are free to maintain it; everyone has their upload rights
16:39 <rbasak> As a stop gap to help the flavour outl
16:39 <rbasak> out
16:39 <rbasak> The plan being that the need for this will go away as soon as Rosco2 is given further rights in the future
16:39 <sil2100> We can vote for that indeed
16:39 <cyphermox> if you want to create that manual set, feel free.
16:39 <cyphermox> can somebody else chair from now on please?
16:40 <rbasak> Look, I'm just one person trying to find a way forward.
16:40 <cyphermox> I understand that
16:40 <cyphermox> but I can't follow the meeting, so I'm asking for help
16:40 <rbasak> AFAICT, nobody objects to what I'm proposing.
16:40 <sil2100> Ok, I can pick it up
16:40 <Laney> It would be possible to restructure the script to implement that concept. Make ~flavour-dev teams have upload rights to <flavours-common> and <flavour>, and then you can grant upload rights to <flavour> indpendently of ~flavour-dev membership.
16:40 <rbasak> Except that you don't like it in the general case.
16:41 <cyphermox> #chair sil2100
16:41 <meetingology> Current chairs: cyphermox sil2100
16:41 <sil2100> cyphermox: o/
16:41 <sil2100> Ok everyone, this meeting is long overdue already
16:41 <rbasak> Thanks sil2100, and cyphermox for bearing with it thus far.
16:42 <slashd> I'm still there too, keeping an eye on the discussion.
16:42 <sil2100> 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 <cyphermox> 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 <Laney> Vote on both things and see what passes?
16:43 <rbasak> I think perhaps we should disentangle what we want Rosco2 to be able to upload with technical implementation.
16:43 <sil2100> Should we start a vote?
16:43 <cyphermox> sil2100: "previous definition" is too vague
16:44 <Laney> ("Fix the script" needs to happen regardless)
16:44 <cyphermox> 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 <sil2100> #vote to grant Rosco2 upload rights to the packageset of { ubuntustudio } - { other flavors }
16:44 <meetingology> Please vote on: to grant Rosco2 upload rights to the packageset of { ubuntustudio } - { other flavors }
16:44 <meetingology> 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 <rbasak> +1
16:44 <meetingology> +1 received from rbasak
16:44 <tsimonq2> +0
16:44 <meetingology> +0 received from tsimonq2
16:44 <cyphermox> -1
16:44 <meetingology> -1 received from cyphermox
16:44 <rbasak> cyphermox: we tried that and the motion didn't pass!
16:45 <cyphermox> rbasak: that wasn't my understanding
16:45 <cyphermox> we tried { give access to the packageset }
16:45 <rbasak> 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 <cyphermox> this needs an explanation
16:46 <cyphermox> I'm -1 because I disagree with teh definition of that packageset.
16:46 <cyphermox> it's vastly different than others, it's not fair for Rosco2 or other applicants.
16:46 <cyphermox> if we redefine what a flavour packageset is, we should make it on the general case.
16:46 <sil2100> So personally, completely personally (and this can be *wrong*), I currently don't really care what's in the packageset currently
16:46 <rbasak> We grant PPU to people, which is vastly different from flavor packagesets, but we consider that acceptable.
16:47 <sil2100> 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 <cyphermox> 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 <rbasak> cyphermox: I think you misunderstand my view at the moment.
16:47 <rbasak> Let me to make it clear.
16:47 <cyphermox> rbasak: however PPUs are based on discreet lists of packages, not abstract sets
16:48 <sil2100> 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 <cyphermox> we've already had to turn people away because they didn't have a list.
16:48 <sil2100> And to me those are two different things that I *personally* want to keep separate
16:48 <rbasak> 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 <cyphermox> sil2100: +1
16:48 <sil2100> rbasak: that is a valid concern, yes
16:49 <rbasak> However, I am willing to grant a subset, distinct from the packageset, for now, as a stop gap to help the flavor.
16:49 <cyphermox> 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 <sil2100> 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 <sil2100> rbasak: but what I'm trying to say is: I understand your concern, yes
16:50 <rbasak> cyphermox: I'm quite happy to vote on the abstract, just as you do on abstract packagesets which is the norm.
16:50 <rbasak> cyphermox: if you're unwilling to vote on the abstract, then sure, generate the list and we can vote on that.
16:51 <rbasak> 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 <cyphermox> rbasak: abstract packageset which is the norm? sorry I don't understand what you mean?
16:52 <cyphermox> when you are reviewing request for a packageset, you know what the packageset contains
16:52 <rbasak> you don't, because there are bugs
16:52 <rbasak> and the packageset changes
16:52 <cyphermox> yes, bugs are fixable
16:52 <cyphermox> and there will be other bugs
16:52 <rbasak> You know what it _currently_ contains, but that isn't the same as what you're agreeing to
16:53 <cyphermox> any changes are reviewed by the DMB
16:53 <cyphermox> 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 <cyphermox> ergo; I always know what is in a pacakgeset, or what is about to be.
16:54 <vorlon> 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 <cyphermox> 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 <rbasak> The motion above is still open.
16:55 <cyphermox> my overarching point is: bugs are fixable, and we shouldn't block an application because there is a bug
16:55 <sil2100> We're in a bit of a pickle here hen
16:55 <rbasak> Is it just cyphermox who disagrees?
16:55 <rbasak> sil2100, slashd?
16:55 <vorlon> 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 <cyphermox> we can say: oh look, we're generally okay, but this here is going to change
16:55 <cyphermox> vorlon: I'm happy you did
16:56 <cyphermox> I disagreed on the exact definition, but you did say it was a minimum?
16:56 <rbasak> cyphermox: I'm not blocking the application on any current bug.
16:56 <rbasak> If you think I am, please re-read my position above.
16:56 <rbasak> It feels to me that you're blocking the current motion on an implementation detail.
16:56 <cyphermox> sil2100: you want to close the vote? I'm not going to change mine.
16:56 <slashd> rbasak, if we vote for Rosco2, I'm +1 to unblock him, but I totally understand rbasak's concern
16:57 <cyphermox> or make sure everyone who should had voted.
16:57 <sil2100> Ok, so I can vote +1 on the current one
16:57 <sil2100> But of course personally I'd prefer the previous one to pass instead
16:58 <slashd> +1
16:58 <meetingology> +1 received from slashd
16:58 <sil2100> I treat the current vote as a 'fallback' to get things moving
16:58 <sil2100> But actually
16:58 <sil2100> This will not get us moving
16:58 <sil2100> Since this one won't pass today as well
16:58 <cyphermox> 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 <cyphermox> perhaps it would be best to table this particular part and go on to vote for Eickmeyer's PPU?
16:59 <rbasak> cyphermox: no, I still don't think you understand my position if you believe that your proposal will work.
16:59 <sil2100> +1 (but I prefer the previous vote to pass)
16:59 <meetingology> +1 (but I prefer the previous vote to pass) received from sil2100
16:59 <sil2100> #endvote
16:59 <meetingology> Voting ended on: to grant Rosco2 upload rights to the packageset of { ubuntustudio } - { other flavors }
16:59 <meetingology> Votes for:3 Votes against:1 Abstentions:1
16:59 <meetingology> Motion carried
17:00 <sil2100> Motion is not carried yet ^
17:00 <sil2100> Anyway, I think we won't solve this today
17:00 <sil2100> vorlon: ^ as you can see this is a very heated discussion, can we get an 'extension' for dealing with teh ubuntustudio situation?
17:00 <sil2100> Possibly till the nearest DMB meeting
17:00 <cyphermox> we still have two meetings
17:00 <cyphermox> (before release)
17:00 <cyphermox> wait, was it two?
17:01 <sil2100> Yes
17:01 <rbasak> I don't think my position is worth blocking Ubuntu Studio over.
17:01 <cyphermox> personally I think that's plenty to resolve the situation
17:02 <sil2100> I think the next action is to actually inform the absent DMB members of the current situation and the current votes open
17:02 <vorlon> sil2100: I would like to see this resolved before beta; I don't know how those dates line up
17:02 <sil2100> e.g. the vote for granting Rosco2 upload rights for the ubuntustudio packageset
17:02 <vorlon> beta is March 28, when is next DMB meeting?
17:03 <rbasak> So I'll switch my vote to +1 to give Rosco2 to the full packageset.
17:03 <sil2100> vorlon: 25th
17:03 <rbasak> If that changes anything.
17:03 <sil2100> So we should be good
17:03 <Eickmeyer> 25th is also beta freeze.
17:03 <cyphermox> rbasak: I wouldn't want you to change your vote because I disagree with the other option
17:03 <sil2100> rbasak: I think we still miss 1 +1 in that case, so we'd have to reach out to absent members
17:04 <sil2100> Let's sort this out till next meeting
17:04 <sil2100> Not much we can do now since we're still missing one +1
17:04 <cyphermox> I think we'll be just fine to sort it out completely before next meeting
17:04 <sil2100> +1
17:04 <slashd> sil2100, I'm okay to give +1 based on my belief for rosco2 to do a good job
17:04 <sil2100> It was a very long and heated meeting
17:05 <sil2100> hmmm
17:05 <sil2100> ;)
17:05 <sil2100> 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 <cyphermox> can we move forward instead and continue over email?
17:05 <sil2100> Like, I would like every DMB member to vote for what they think is correct, always
17:06 <cyphermox> sil2100: +1
17:06 <sil2100> Let's move on as cyphermox proposes, we can deal with this later or through e-mail
17:06 <sil2100> Ok
17:06 <slashd> sound good to me
17:06 <cyphermox> 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 <Rosco2> No problems - thanks all
17:08 <sil2100> #subtopic Eickmeyer for PPU permissions
17:08 <sil2100> #link https://wiki.ubuntu.com/Eickmeyer/PPUApplication
17:08 <sil2100> (the packages are defined in the application)
17:08 <sil2100> Eickmeyer: apologies for the long wait!
17:08 <Eickmeyer> sil2100: No worries. I ran my son to school and back watching on Quasseldroid. :)
17:08 <sil2100> ;)
17:09 <sil2100> Eickmeyer: could you introduce yourself?
17:09 <Eickmeyer> 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 <Eickmeyer> I had previous experience with RPM packaging and have been working on Debian packaging for said past year.
17:10 <Eickmeyer> Jumped from Fedora to Ubuntu Studio when I saw the need for leadership.
17:10 <sil2100> Eickmeyer: \o/
17:10 <sil2100> ;)
17:11 <rbasak> Eickmeyer: welcome, and thank you for sitting through all of this
17:11 <Eickmeyer> Had previously used Ubuntu for the majority of my distro-hoppig time. :)
17:11 <Eickmeyer> rbasak: Thank you.
17:11 <rbasak> Eickmeyer: how familiar would you say you are with respect to Ubuntu-specific development processes that don't apply to Debian?
17:12 <sil2100> (question time o/)
17:14 * sil2100 pokes Eickmeyer
17:14 <Eickmeyer> My concern is for the Ubuntu Studio project to keep moving forward.
17:14 <Eickmeyer> [end intro]
17:14 <sil2100> Eickmeyer: there was a question from rbasak above ^
17:14 <sil2100> ;)
17:15 <Eickmeyer> 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 <rbasak> Oh sorry, I had thought you were done.
17:15 <rbasak> Eickmeyer: OK, thanks. Do you know about proposed migration in Ubuntu?
17:16 <Eickmeyer> 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 <sil2100> Any other questions?
17:17 <rbasak> 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 <slashd> Eickmeyer, talking about proposed, what can influence/impact the release of a package in -proposed ?
17:18 <rbasak> (I'm done with questions - thanks)
17:18 <cyphermox> 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 <slashd> cyphermox, but you never sponsored him ? at least I don't see it in sponsorship miner
17:19 <cyphermox> I have sponsored him, package is still in NEW
17:19 <slashd> cyphermox, ack
17:20 <cyphermox> I have reviewed the other packages uploaded.
17:20 <Eickmeyer> slashd: From what I understand, if that package affects other packages, or has other errors, that can affect it from being migrated.
17:20 <Eickmeyer> By affects I mean negatively.
17:20 <slashd> Eickmeyer, how this package affect other package is reported ? and where would you look at to see it ?
17:21 <Eickmeyer> slashd: The textual output of the proposed-migration scripts, correct?
17:22 <slashd> ok, no more question for me
17:23 <tsimonq2> No questions for me.
17:24 <Eickmeyer> Running Britney locally is a good idea too.
17:24 <tsimonq2> ^ unrelated, I recently wrote some code making thst easy.
17:24 <tsimonq2> :P
17:25 <slashd> vote ?
17:25 <Eickmeyer> Whoops, tsimonq2 did it again.
17:25 <sil2100> Ok, I think it's time to vote
17:25 <sil2100> #vote for granting Eickmeyer PPU rights to packages as per his application
17:25 <meetingology> Please vote on: for granting Eickmeyer PPU rights to packages as per his application
17:25 <meetingology> 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 <slashd> +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 <meetingology> +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 <tsimonq2> -1 I'd like to see more experience with a wider variety of packages
17:26 <meetingology> -1 I'd like to see more experience with a wider variety of packages received from tsimonq2
17:27 <rbasak> +1
17:27 <meetingology> +1 received from rbasak
17:27 <cyphermox> +1
17:27 <meetingology> +1 received from cyphermox
17:27 <rbasak> I'm heavily weight Rosco2's endorsement as someone who is on his team and already uploads these packages.
17:27 <rbasak> I heavily weight
17:28 <rbasak> Sorry typing ahead of thinking today
17:29 <sil2100> +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 <meetingology> +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 <sil2100> Oh, endorsement from cyphermox I missed
17:30 <sil2100> uh
17:30 <sil2100> Well
17:30 <sil2100> #endvote
17:30 <meetingology> Voting ended on: for granting Eickmeyer PPU rights to packages as per his application
17:30 <meetingology> Votes for:2 Votes against:1 Abstentions:2
17:30 <meetingology> Motion carried
17:31 <sil2100> Another vote undecided it seems ^
17:31 <sil2100> Actually
17:32 <sil2100> hm, Eickmeyer's PPU packagelist seems odd
17:32 <sil2100> This is what made me confused, I guess I'm tired
17:33 <sil2100> Eickmeyer: so I see on your wiki application page you seem to mention the list of packages and 'Ubuntu Studio Package Set'
17:33 <rbasak> Oh
17:33 <Eickmeyer> sil2100: Yes, the "Ubuntu Studio Package Set" is really a "hail mary" to save Ubuntu Studio.
17:33 <sil2100> I don't think this is supposed to be there
17:33 <rbasak> -1 on that, sorry.
17:33 <Eickmeyer> I can remove it.
17:33 <sil2100> Eickmeyer: yes, please
17:34 <Eickmeyer> Done
17:34 <sil2100> Since if we remove that, then I can be +1 on the PPU list
17:34 <sil2100> (with cyphermox's endorsement)
17:34 <sil2100> Ok, let's just re-do the vote to be sure:
17:35 <cyphermox> my vote counted it out
17:35 <cyphermox> (since it was obvious from before that was undecided etc etc)
17:35 <sil2100> #vote for granting Eickmeyer PPU rights to packages: carla, grub2-themes-ubuntustudio and ubuntustudio-*
17:35 <meetingology> Please vote on: for granting Eickmeyer PPU rights to packages: carla, grub2-themes-ubuntustudio and ubuntustudio-*
17:35 <meetingology> 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 <rbasak> +1
17:35 <meetingology> +1 received from rbasak
17:35 <cyphermox> +1
17:35 <meetingology> +1 received from cyphermox
17:36 <slashd> +0 for the same reason
17:36 <meetingology> +0 for the same reason received from slashd
17:36 <sil2100> +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 <meetingology> +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 <sil2100> (since it's just a small subset of packages that you acually work on)
17:36 <sil2100> tsimonq2: ^
17:37 <tsimonq2> +0 for the same reason
17:37 <meetingology> +0 for the same reason received from tsimonq2
17:37 <sil2100> #endvote
17:37 <meetingology> Voting ended on: for granting Eickmeyer PPU rights to packages: carla, grub2-themes-ubuntustudio and ubuntustudio-*
17:37 <meetingology> Votes for:3 Votes against:0 Abstentions:2
17:37 <meetingology> Motion carried
17:37 <sil2100> Ok, still undecided, but at least it's clear
17:37 <cyphermox> that's still not a carried; yep
17:37 <sil2100> Eickmeyer: I think this will also have to wait till next meeting (or e-mail)
17:37 <Eickmeyer> Okay.
17:37 <rbasak> Hang on
17:37 <sil2100> Ok, I think we need some action items for those
17:37 <rbasak> I think it is carried
17:38 <sil2100> rbasak: it's not
17:38 <cyphermox> rbasak: oh?
17:38 <sil2100> rbasak: oh
17:38 <rbasak> The absentees cannot cause the motion to fail
17:38 <sil2100> rbasak: wait
17:38 <rbasak> If they both voted -1, it'd be 3-2
17:38 <cyphermox> actually
17:38 <sil2100> rbasak: you are right I think!
17:38 <cyphermox> yes
17:38 <sil2100> Yaay
17:38 <Eickmeyer> \o/
17:38 <sil2100> yay for math \o/
17:38 <sil2100> ;)
17:38 <cyphermox> well
17:38 <cyphermox> it's iffy, but sure ;)
17:38 <sil2100> Eickmeyer: congratulations anyway o/
17:38 <Eickmeyer> Thanks!
17:39 <Rosco2> \o/
17:39 <slashd> Congrats to both of you Rosco2 Eickmeyer
17:39 <sil2100> Now, we need action items for both Rosco2 and Eickmeyer
17:39 <Eickmeyer> Now I'm just hoping for Rosco2 to get the packageset. Any chance we can be cc'd on the emails?
17:39 <rbasak> Reminder: action items for the announcements too, please
17:39 <sil2100> They have similar sets of packages, but I think we'd need 2 separate packagesets anyway
17:39 <sil2100> Any volunteers?
17:39 <rbasak> Eickmeyer: subscribe to devel-permissions@ please!
17:39 <Eickmeyer> rbasak: Already subscribed. :)
17:39 <cyphermox> sil2100: I don't think this needs separate packagesets
17:40 <rbasak> No packagesets - just PPU?
17:40 <sil2100> I mean, PPU's
17:40 <cyphermox> if the list is the same; it can be just one especially since it's quite likely to be temporary
17:40 <sil2100> cyphermox: well, Rosco2 has some more
17:40 <cyphermox> oh
17:40 <cyphermox> in that case two yeah
17:40 <sil2100> cyphermox: since he has the US ones + his Debian packages
17:40 <cyphermox> well
17:41 <cyphermox> this is where it's a little complicated
17:41 <cyphermox> it really should be one PPU list for debian packages
17:41 <cyphermox> and one separate PPU list for anything else.
17:41 <sil2100> Could be that
17:41 <sil2100> cyphermox: on the other hand
17:41 <cyphermox> (so both Erich and Ross can share that)
17:41 <rbasak> Huh?
17:42 <rbasak> What's a PPU list?
17:42 <sil2100> 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 <rbasak> It's an edit-acl command per entry
17:42 <cyphermox> rbasak: packageset
17:42 <cyphermox> sil2100: well, we can also share such packagesets if we create one
17:42 <rbasak> "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-<lpid>"."
17:42 <rbasak> I'm not sure that applies here.
17:42 <sil2100> cyphermox: yeah, but how would you call it? ;)
17:42 <cyphermox> *shrugs*
17:42 <sil2100> cyphermox: I guess it's a bikesheding thing
17:42 <cyphermox> ubuntustudio-tehming?
17:43 <cyphermox> it doesn't matter much
17:43 <sil2100> Ah, right, we do have input-methods already
17:43 <cyphermox> my point was the Debian packages as separate than the ubuntusutdio-
17:43 <sil2100> Makes sense
17:43 <sil2100> rbasak: ah, right
17:43 <rbasak> We did it for GunnarHj because of fonts-*
17:43 <sil2100> rbasak: you are correct, we might not even have to do that
17:43 <cyphermox> 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 <rbasak> I'm not sure why fossfreedom needed it. I wasn't present at that meeting.
17:43 <sil2100> Anyone want to take the action for that?
17:44 <cyphermox> creating any packageset will require TB action
17:44 <sil2100> cyphermox: as mentioned by rbasak, we might not need that
17:44 <rbasak> cyphermox: but so does adding PPU entries
17:44 <cyphermox> rbasak: no
17:44 <sil2100> cyphermox: like, we can just assign PPU rights manually without a packageset
17:44 <cyphermox> yup
17:44 <rbasak> cyphermox: OK. Well you should take the action to add the PPU entries without help from the TB then :-P
17:45 <cyphermox> I was thinking ahead in terms of maintainability
17:45 <sil2100> So we should be good without the TB
17:45 <sil2100> (or at least that was my understanding?)
17:45 <cyphermox> ie. so we don't have to do as much cleanup later, but sure, I'll take the actions
17:45 <sil2100> #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 <sil2100> cyphermox: thanks! ;)
17:45 <rbasak> "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 <sil2100> phew
17:45 <cyphermox> thanks to you sil2100
17:46 <rbasak> sil2100: actions for the announcements please
17:46 <sil2100> rbasak: ah, indeed!
17:46 <rbasak> https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Actions_after_a_successful_applications
17:46 <cyphermox> rbasak: IIRC we can add single PPUs just fine; I remember doing so before
17:46 <cyphermox> we just can't create the packageset
17:46 <sil2100> cyphermox: do you want to do the announcements as well or should I do those to save you time?
17:46 <cyphermox> sil2100: if you can please do the announcements?
17:46 <cyphermox> I've been working on updating the packageset
17:46 <cyphermox> +s
17:47 <sil2100> cyphermox: ok!
17:47 <sil2100> #action sil2100 to send out announcements for Rosco2 and Eickmeyer
17:47 * meetingology sil2100 to send out announcements for Rosco2 and Eickmeyer
17:47 <sil2100> OK!
17:47 <sil2100> #topic AOB
17:47 <sil2100> ...it's not over YET!
17:48 <sil2100> Time for other business, and I think teward wanted to bring something up?
17:48 <teward> I know there's already an AOB on the agenda but... *raises hand*
17:48 <teward> yeah just a suggestion/comment if I may
17:48 <tsimonq2> I understand teward has some AOB
17:48 <tsimonq2> yeah
17:49 <teward> 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 <sil2100> teward: maybe you start, we'll move on to the other one afterwards
17:49 <teward> 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 <teward> 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 <cyphermox> teward: that's why tsimonq2 has an action to add that to the wiki and clarify it :)
17:50 <teward> cyphermox: indeed, but I also suggest perhaps *not* giving that to Simon
17:50 <teward> Simon is currently... *looks* ... fifty documentation tasks behind due to classes/work/otherObligations
17:50 <tsimonq2> I will admit to grilling teward in a personal capacity before I advocate for him :P
17:50 <tsimonq2> hah
17:50 <cyphermox> 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 <teward> ack
17:51 <tsimonq2> Yup.
17:51 <teward> cyphermox: i assume then that this is a discussion point internally as well :)
17:51 <sil2100> teward: well, it wouldn't be just Simon doing the documentation, but we wanted him to start it off
17:51 <teward> indeed.
17:51 <sil2100> And then work together on the final form
17:51 <teward> 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 <cyphermox> teward: perhaps we hadn't made that explicit; but yeah, as per what sil2100  is saying
17:51 <teward> just wanted to get that clarification in there.
17:51 <cyphermox> teward: thanks :)
17:51 <teward> cyphermox: indeed, the quick AOB discussion helps :)
17:51 <teward> </done>  *lurks*
17:51 <cyphermox> yup
17:52 <sil2100> teward: \o/
17:52 <sil2100> Ok, now slashd's topic
17:52 <sil2100> "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 <teward> (it's nice when some AOB discussions're just short and easy xD)
17:52 <sil2100> I think we're all tired and worn off already
17:52 <cyphermox> sil2100: I liked the suggestion of asking by email for a time that would work for them
17:52 <slashd> sil2100, seyeong (my APAC colleague) will send an official request to the ML.
17:52 <tsimonq2> I'm open to showing up in the evening US time.
17:52 <sil2100> cyphermox, slashd: excellent
17:53 <tsimonq2> That's the middle of the night for Europe though.
17:53 <sil2100> I guess it's decided: we wait for an e-mail to the ML and resolve that there
17:53 <cyphermox> tsimonq2: we'll figure something out :)
17:53 <tsimonq2> ok
17:53 <slashd> sil2100, lgtm
17:53 <sil2100> slashd: would that be fine? Let's add an action item to check on this for next meeting
17:54 <tsimonq2> Nothing elsw from me. Who doesn't love a three hour DMB meeting? :)
17:54 <slashd> sil2100, yep
17:54 <tsimonq2> *else
17:54 <sil2100> #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 <sil2100> Ok, I think it's time
17:54 <sil2100> #endmeeting