[14:56] <slashd> o/
[14:56] <tsimonq2> o/
[14:56] <Eickmeyer> o/
[15:00] <sil2100> o/
[15:00] <Rosco2> o/
[15:00] <tsimonq2> I can't chair today.
[15:01] <rbasak> o/
[15:02] <Eickmeyer> hbd tsimonq2
[15:02] <tsimonq2> Volunteers for chair?
[15:02] <tsimonq2> Eickmeyer: Huh?
[15:02] <Eickmeyer> Happy Birthday? Do I have the date wrong?
[15:02] <tsimonq2> Ah yes, thanks. :)
[15:03] <Eickmeyer> yw
[15:03] <tsimonq2> Wasn't familiar with the acronym.
[15:03] <Eickmeyer> Now you are. :)
[15:03] <tsimonq2> :)
[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> 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:06] <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> ACTION: 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] <cyphermox> sure, there can be improvements; but I don't see it as wrong per se.
[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] <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:17] <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> ACTION: 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> ACTION: 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> ACTION: 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 :)
  *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> ACTION: slashd to follow up on the APAC Ubuntu community coverage
[17:54] <sil2100> Ok, I think it's time
[17:54] <sil2100> #endmeeting
[17:54] <meetingology> Meeting ended Mon Mar 11 17:54:32 2019 UTC.
[17:54] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-03-11-15.05.moin.txt
[17:54] <sil2100> Thanks everyone!
[17:54] <slashd> take care guys !
[17:54] <sil2100> cyphermox: thanks for chairing for the first part of the meeting!
[17:54] <tsimonq2> Thanks!
[17:55] <Eickmeyer> Thanks everyone! Looking forward to the packageset decision.
[17:55] <sil2100> This was a very intense DMB meeting, phew
[17:55] <cyphermox> thanks for taking over
[17:55] <teward> sil2100: drinks are on me then for everyone to relax after that intense meeting :P
[17:55] <teward> never seen one so intense and I've lurked many :P
[17:55] <tsimonq2> I'll take a drink :P
[17:55] <teward> you get water
[17:55] <teward> you aren't of age yet.
[17:55] <tsimonq2> Come find me at LFNW or SELF
[17:55] <Rosco2> Cheers everyone! Now, wheres the fridge.
[17:55] <tsimonq2> hah
[17:55] <tsimonq2> no
[17:55] <tsimonq2> Coffee
[17:56] <tsimonq2> Rosco2: *points at teward*
[17:56] <Eickmeyer> Same. Coffee (It's 11 am here post DST change)
[17:56] <teward> coffee is easy.
[17:56] <Rosco2> European time :-)
[17:56] <tsimonq2> Bad DST is bad.
[17:56] <teward> i have unlimited here :P
[17:56] <tsimonq2> teward: Especially when you've had six cups today. :P
[17:56] <teward> seven*
[17:57] <tsimonq2> aXd
[17:57] <teward> i had another cup since i mentioned 6
[17:57] <tsimonq2> *XD
[18:02] <acheronuk> from another flavour, I appreciate the time put into this :)
[18:39] <tsimonq2> np :)