[14:56] o/ [14:56] o/ [14:56] o/ [15:00] o/ [15:00] o/ [15:00] I can't chair today. [15:01] o/ [15:02] hbd tsimonq2 [15:02] Volunteers for chair? [15:02] Eickmeyer: Huh? [15:02] Happy Birthday? Do I have the date wrong? [15:02] Ah yes, thanks. :) [15:03] yw [15:03] Wasn't familiar with the acronym. [15:03] Now you are. :) [15:03] :) [15:05] #startmeeting Ubuntu Developer Membership Board [15:05] Meeting started Mon Mar 11 15:05:11 2019 UTC. The chair is cyphermox. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [15:05] Available commands: action commands idea info link nick === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice | Ubuntu Developer Membership Board Meeting | Current topic: [15:05] Hey all; just give me a second to look up the agenda please :) [15:05] #link https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda [15:06] #topic Review of previous action items === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice | Ubuntu Developer Membership Board Meeting | Current topic: Review of previous action items [15:06] Oh, cyphermox took it over, thanks o/ [15:06] so; mine is done (recent packageset requests) [15:06] tsimonq2: you had "better document what we expect applicants to know" [15:06] Mine is not quite done yet, I'll have it done for next meeting. [15:07] ack [15:07] let's get to the meat of this meeting then [15:07] #topic Package Set / Per Package Uploader applications === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | be nice | Ubuntu Developer Membership Board Meeting | Current topic: Package Set / Per Package Uploader applications [15:07] Today we look at Rosco2 's and Eickmeyer's applications [15:08] who wants to go first? [15:08] actually [15:08] * Rosco2 nervously puts up hand [15:08] Rosco2: if you're around, you name is up first in the wiki page [15:08] cool :) [15:09] so; link to the application is here: [15:09] #link https://wiki.ubuntu.com/RossGammon/PPUApplication [15:09] Rosco2: would you like to tell us a little more about what you're applying for and all? [15:09] Yes [15:09] I have been working on Ubuntu Studio packages for a while [15:10] I would like to have permission to upload these and a few of my Debian packages [15:10] the list as written on your wiki page? [15:10] Mainly ones from the Debian Multimedia Team [15:10] Yes [15:11] Eventually I would like the US package set, but that is a good astart [15:12] ah, I was going to ask about that [15:12] do you have a timeline? [15:12] Not really, [15:12] my understanding is that the Technical Board's requirement for official flavours be that at least one developer has packageset access [15:12] Just want to be able to help out as much as possible [15:13] Then if granted I would be happy with that :-) [15:13] vorlon: ^ perhaps you're interested in this meeting as you've been in these discussions before [15:13] Could you speak to your recent activity level in Ubuntu? [15:13] Well [15:14] cyphermox: we already have the same situation for Ubuntu Budgie [15:14] cyphermox: yes, hi [15:14] sil2100: yes, I'm aware :/ [15:14] But I guess it's up to the TB to decide, maybe we should push the budgie guys as well [15:15] I want to avoid derailing the meeting and distracting from an already stressful situation for applicants, maybe we can cover that in AOB? [15:15] tsimonq2, The workload on pure US packages is normally 4/5 uploads per cycle [15:15] Sure [15:15] But the team has been much more active this cycle [15:16] Rosco2: How many uploads have you personally driven for Cosmic and Disco? [15:16] So there has been a lot more to review and test [15:16] Just counting [15:17] 6? [15:17] The total packages should be 8 including 2 new. [15:17] Quite a few more have been tidyups after reviewing Erich's ^& Lens work in the team [15:18] Erich, 2 cycles includes more :-) [15:18] Ah, yes. [15:18] I understand those were also driven by others, my point is to gauge your personal involvement with those uploads. [15:19] Well - mainly reviewing the package to get it ready for upload. [15:19] Committing changes (lintian etc) and triaging bugs that might be fixable at the same time [15:20] When you're done, I have questions please [15:21] tsimonq2, more? [15:22] I'm satisfied, thabks. [15:23] Rosco2: how familiar would you say you are with respect to Ubuntu-specific development processes that don't apply to Debian? [15:23] T think I have tackled most of the possible types of uploads in Ubuntu [15:24] Mainly merges & syncs in the development release [15:24] Do you know where to look to find the freeze timetable, documentation on when you may upload what, and how to get an exception? [15:24] I have done an SRU or 3, but there hasn't been a US package needing one recently [15:25] Yes - for a while I was the Test Manager / Release Manager in US, and was sending regular reminders to the team [15:26] We followed the FFE procedure last week with the 2 new packages [15:26] Do you know about proposed migration? [15:26] (in Ubuntu) [15:26] Yes [15:26] * sil2100 has a question as well [15:26] (related) [15:26] Lmms had some problems migrating [15:27] OK, I'm done with quesetions - thanks! [15:27] Failed to build on one architecture, then was stuck due to libc transition [15:27] (but don't let me stop you expanding - that's useful to hear) [15:28] I normally check my Debian packages have moved out of proposed and try and help using execuse.tx and the new tool in archive-tools [15:28] Rosco2: so a follow up question to the one by rbasak: from the upload miner I see you had 3 SRUs in the past, but none of them seem to be 'well prepared' from the SRU POV - if you would have to prepare an SRU to a stable series for one of the US packages, what steps would you need to perform? [15:29] Well step 1 - reread the wiki :-) [15:29] Which page would that be? ;) [15:30] From memory it needs to be tested, the bug description contain the test case [15:30] Are those upload miner entries correctly categorized? They don't look like SRUs to me. [15:30] and justification (targeted changes) and discussion of regression risk [15:31] Then there is normally a requirmeent for verification of the fix before it is released [15:32] rbasak, As I said. It has been a while - I can't actually remebr which was a real SRU [15:33] rbasak: udd.debian.org? it wrongly categorises some of my uploads :/ [15:33] But I do remember doing it at least once or following along in the process. [15:33] rbasak: indeed, the dates do not match [15:33] Rosco2: thanks! [15:34] * sil2100 has no more questions [15:35] If everyone's done, ready for voting? [15:35] cyphermox? [15:36] sorry, yeah, no questions from me [15:36] let's deal with these separately; first the PPU for debian packages maintained [15:37] (and look at my bad grammar) [15:37] #vote Rosco2 PPU for the packages he maintains in Debian [15:37] Please vote on: Rosco2 PPU for the packages he maintains in Debian [15:37] Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) [15:37] +1 [15:37] +1 received from sil2100 [15:37] +1 [15:37] +1 received from rbasak [15:37] +1 [15:37] +1 received from cyphermox [15:37] jbicha sent a +1 as well. [15:38] slashd: ? [15:38] +1 [15:38] +1 received from slashd [15:38] tsimonq2? [15:38] I think this is clearly a successful application anyway. [15:38] +0 [15:38] +0 received from tsimonq2 [15:38] :) [15:38] #endvote [15:38] Voting ended on: Rosco2 PPU for the packages he maintains in Debian [15:38] Votes for:4 Votes against:0 Abstentions:1 [15:38] Motion carried [15:38] that's a motion carried indeed. [15:39] Now for the US ones? [15:39] ok; second thing to vote for: PPU for the ubuntustudio-* packages and carla, grub2-theme-ubuntustudio [15:39] point of order, please [15:39] Technically we can't grant carla yet [15:39] vorlon: yes? [15:40] I understand the application was for the list of individually named packages [15:40] yes [15:40] and I understand there are more packages than that in the ubuntustudio packageset [15:40] yep [15:40] Yes [15:40] is the DMB intending to only vote on PPU for the individually named packages, because that is what Rosco2 asked for? [15:41] I am aware of that, mentioned it earlier -- my plan, if people agree, would be to first vote for the stuff as it is in his wiki application, and then separately vote for the packageset request despite it not being on the request [15:41] ok [15:41] hm, ok [15:41] that sounds fine, I just wasn't sure the latter was also on the agenda, carry on thanks :) [15:42] that way if PPU are an easy motion carried, we don't avoid going over it discussing other things. [15:42] sil2100: rbasak: slashd: objections? [15:42] tsimonq2: ^ [15:42] Not from me. [15:42] no objections [15:43] I think that's a good plan. [15:43] I'm free for a little while meetingwise; so we could either immediately vote for packageset after or defer until after we've also looked at Erich's application (as per the agenda) [15:44] No objections [15:44] I am Ok with waiting - I am sure Erich is gewtting impatient :-) [15:44] #vote rosco2 to gain PPU rights to carla (when NEW processed), grub2-theme-ubuntustudio, and ubuntustudio-* packages listed in his wiki page [15:44] Please vote on: rosco2 to gain PPU rights to carla (when NEW processed), grub2-theme-ubuntustudio, and ubuntustudio-* packages listed in his wiki page [15:44] Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) [15:44] However we won't get a proxy vote from jbicha since he's absent and we can't consider him to be able to send a vote in advance for motions not planned in advance. [15:44] rbasak: I understand [15:44] +1 [15:44] +1 received from rbasak [15:44] +1 [15:44] +1 received from sil2100 [15:44] +1 [15:44] +1 received from slashd [15:44] +1 [15:44] +1 received from cyphermox [15:44] (again, jbicha sent a +1) [15:45] +0 [15:45] +0 received from tsimonq2 [15:45] #endvote [15:45] Voting ended on: rosco2 to gain PPU rights to carla (when NEW processed), grub2-theme-ubuntustudio, and ubuntustudio-* packages listed in his wiki page [15:45] Votes for:4 Votes against:0 Abstentions:1 [15:45] Motion carried [15:45] congrats Rosco2 [15:45] Thanks very much everyone [15:45] I know Eickmeyer's waiting. [15:45] ANd thanks for all the sponsorship upto now [15:45] please stay around; let's review Eickmeyer's application right away :) [15:46] But I think Rosco2's packageset vote might eliminate the current need for urgency [15:46] I'm here. [15:46] let me take an action to set up the accesses [15:46] I agree with rbasak. [15:46] #action cyphermox to give PPU rights to rosco2 [15:46] ACTION: cyphermox to give PPU rights to rosco2 [15:46] To be clear, my +0s are due to not enough recent activity level in my opinion. [15:47] Eickmeyer: so; your application is here: [15:47] Otherwise I'm satisfied with Rosco2's packaging skills. [15:47] #link https://wiki.ubuntu.com/Eickmeyer/PPUApplication [15:47] cyphermox: I think Eickmeyer wants to defer to Rosco2's third vote first? [15:47] oh, is that so? [15:47] sorry I misread [15:48] okay then; [15:48] Yes. That's the more urgent matter. AFAIK, the TB needs one person on the team to have the package set, correct? [15:48] I'm not sure how well defined the requirement is against the packageset specifically, but being able to upload the packageset will surely resolve the TB's concern. [15:48] #vote to grant Rosco2 upload rights to the ubuntustudio packageset [15:48] Please vote on: to grant Rosco2 upload rights to the ubuntustudio packageset [15:48] Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) [15:49] +0 [15:49] +0 received from tsimonq2 [15:49] rbasak: only being able to upload themed packages is not super useful tbh [15:49] Same reasons as stated. [15:49] For reference, here is the current packageset: http://people.canonical.com/~ubuntu-archive/packagesets/disco/ubuntustudio [15:49] However the vote is for the packageset including all future changes to it. [15:49] Yes - the package set is way out of date ATM [15:49] I'm not sure debian-archive-keyring should be in there for example. [15:49] That seems really wrong. [15:50] But I think fixing that is independent of Rosco2 being able to upload to the list. [15:50] So, I know we didn't want to touch this topic here right now but it might affect my vote [15:50] +1; I see evidence of good work on packageing; the applicant is already a Debian Developer, etc. No issues. [15:50] +1; I see evidence of good work on packageing; the applicant is already a Debian Developer, etc. No issues. received from cyphermox [15:50] rbasak: debian-archive-keyring is certainly depended on by something to make it in the packageset [15:50] vorlon: from the TB POV, for ubuntu-studio to still stay as a recognized supported flavor, do they need to have people with upload rights to the whole packageset? [15:51] cyphermox: sure, that's probably how it's brought in, but it's wrong and the automatic generation should blacklist it IMHO. [15:51] sil2100: from my perspective, it needs to be "the whole packageset" as an abstraction, but I agree that the current packageset contents look odd [15:52] rbasak: (it's via apt-offline, which is a direct recommend) [15:52] Ubuntu Studio's flavor status should not affect our vote on an independent applicant's application. [15:52] sil2100: i.e.: I'd be looking for the TB to sign off that there is an uploader trusted to upload all the packages that need to be maintained for the ubuntustudio flavor to be successful [15:52] rbasak: I disagree. Seed might want to handle the package slightly differently, but I definitely don't see this as a blocker [15:52] and the details of what's actually in that packageset can be refined [15:52] cyphermox: not a blocker for this vote, but we (the DMB) should fix it. [15:53] *no* [15:53] ubuntustudio should fix their seed. [15:53] An upload of us-meta is pending. Will look into it [15:54] Rosco2: it's a bit more involved than uploading us-meta, but I can help you with this [15:54] Thnks [15:54] vorlon: what would your (TB hat) view be on packages like gimp? Do you think the flavor developer should be able to upload that? [15:54] (as a requirement) [15:54] err, why did you pick gimp in particular as your example? [15:55] Because it's very not-flavor-specific. [15:55] ubuntustudio is a flavour that is meant to let people to artsy stuff [15:55] (but clearly important to the flavor) [15:55] rbasak: it doesn't match my understanding of how it's meant to work for a common package like gimp to be something we grant upload rights on for a community flavor given that it should already be well-maintained as part of flavors in main [15:56] I concur [15:56] rbasak: however, I also think that's something that can be mediated between the flavors in case of conflict and I don't care much if that mediation takes place through the packagesets or in person-to-person discussions [15:56] There are also kubuntu packages that we tend to leave to kubuntu unless they need help [15:56] in main? [15:56] But I'm not sure that cyphermox does, for what this packageset should include. [15:56] /except/ that if there are particular packages in the packageset whose presence gives the DMB pause in +1ing, in which case we should deal with that with priority ;) [15:57] I am experiencing pause for this reason. [15:57] I am confident to +1 Rosco2 for packages in universe not maintained as part of any other flavor [15:57] I'm not sure if that currently means I'm a +1 for the packageset or not. [15:58] right, in my mind the ideal is that "Rosco2 should be trusted as an US uploader" should be severable from "US uploaders should be able to upload package $foo that is shared with other flavors" [15:58] It's a pretty huge packageset, which is why I asked the question of US maintenance requirement [15:58] I'm not sure everyone is on the same page as how flavour packagesets work. [15:58] cyphermox: agreed [15:58] ^ [15:59] In my view, flavour packageset automatic generation is secondary to what we intend them to be, and where there's a mismatch, we whitelist/blacklist packages to make it so. [15:59] AFAICT (please correct me if I'm wrong), cyphermox sees it the other way round? [15:59] these are not random lists of packages; they are an output of the seed going through germinate. Some of the packages are directly listed in the seeds, others are recommends and whatnot; and there already is some amounts of set generation that ensures common packages land expliclity in core [16:00] What's the advantage to blacklisting packages if other flavor packagesets can upload to it? [16:00] my point is we should not blacklist or whitelist things [16:00] So why isn't gimp in core? [16:00] +1 cyphermox [16:00] +1 cyphermox received from tsimonq2 [16:00] wait [16:00] no [16:00] XD [16:00] because it's not in any other flavour [16:00] ok, I stand correctly [16:00] *corrected [16:00] +0 [16:00] +0 received from tsimonq2 [16:00] it's also in xubuntu [16:00] there [16:00] tsimonq2: yup [16:01] let me kill that off, we'll start over [16:01] #envote [16:01] #endvote [16:01] Voting ended on: to grant Rosco2 upload rights to the ubuntustudio packageset [16:01] Votes for:1 Votes against:0 Abstentions:1 [16:01] Motion carried [16:01] Oh, sorry. I had assumed it was in main. [16:01] ^disregard [16:01] rbasak: that's precisely the problem with reviewing packagesets like these [16:02] we get to recognize some packages and think they ought to be in main or elsewhere. [16:03] anything that would be in main and shared would end up in core; anything else is currently free game; and I for one agree with teh current state of things [16:04] we're all adults and presumably able to handle conflicts and exercise judgement as to whether what we upload is sane and okay for other users of the packages [16:04] I have too many memories of packageset conflicts doing unexpected things. In particular with the server seed. [16:04] cyphermox: by that logic the only upload status should be core dev. [16:04] rbasak: Do you have an example? [16:04] rbasak: what? [16:05] tsimonq2: of packageset conflicts doing unexpected things? Let's not digress. [16:05] rbasak: precisely not: what I'm saying is if xubuntu and ubuntustudio have gimp in their packagesets, they're all old enough to know how to not upload things that will break stuff for one another. [16:05] ie. what we expect of an developer by way of the CoC [16:06] cyphermox: sure, but that's not a reason to eliminate the question of whether a packageset has too wide covefrage. [16:06] rbasak: It'll add to the general argument for whitelisting/blacklisting packagesm [16:06] coverage [16:06] tsimonq2: we can discuss further elsewhere, I think I know exactly what rbasak is talking about,and it's vastly different than Packageset upload rights [16:06] s/packagesm/packages./ [16:06] Alright, sounds good. [16:06] rbasak: we ask that question (too wide coverage) when we review the packageset update report. [16:06] I mean, I understand the question, but I have no issue with the packageset as it currently is [16:07] I'm comfortable with a +1 to Rosco2 for narrow coverage. [16:07] I'm not currently comfortable with giving Rosco2 wide coverage, because of his relatively little involvement recently. [16:07] are we all ready to vote? [16:07] So in deciding whether to +1 the packageset, I need to know what the packageset is intended to cover. [16:07] or do we need to further discuss this? [16:08] Really, the only thing that Ubuntu Studio really touches are the ubuntustudio-* packages and Carla at present time. Everything else is pretty much upstream. [16:08] I understand the concern, but I'm hoping we get the benefit of the doubt. [16:09] Where does everyone else stand currently? [16:09] I'm still at +0. [16:09] rbasak, I'm with you w/ narrow coverage [16:09] Or sure, run the vote and we can find out if you prefer. [16:10] Eickmeyer: ("pretty much upstream" - yes, but if you need to fix something for a release or in SRU, you can't rely on the Debian maintainers to fix it) [16:11] #vote to grant Rosco2 upload rights to the ubuntustudio packageset (take 2) [16:11] Please vote on: to grant Rosco2 upload rights to the ubuntustudio packageset (take 2) [16:11] Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) [16:11] vorlon: I understand. [16:11] +0 [16:11] +0 received from rbasak [16:11] +1 [16:11] +1 received from cyphermox [16:11] +0 [16:11] +0 received from slashd [16:11] +0 [16:11] +0 received from tsimonq2 [16:11] fwiw I see packages listed in http://people.canonical.com/~ubuntu-archive/packagesets/disco/ubuntustudio that definitely *are* in main (gnome-software, langpacks) so I'm not sure how that squares with cyphermox's comments about "everything common is in core" [16:12] I'm still not entirely sure about my vote here [16:12] vorlon: I simplified it quite a bit; the exact code is at https://code.launchpad.net/~developer-membership-board/+junk/packageset [16:13] sure, there can be improvements; but I don't see it as wrong per se. [16:13] I feel that we're stuck on a technicality, but in general our sentiment does actually resolve the TB's concern. [16:13] I have some conflicting feelings: on one hand I suppose flavor maintainers *should* have upload rights to all of the components in their packageset, but the current packageset is quite big and I suppose it'll be like that because of what ubuntustudio actually is [16:13] sil2100: so +0? [16:14] What if we passed a motion agreeing that Rosco2 can upload, more narrowly, ubuntustudio-specific fixes that aren't covered by an existing flavor? [16:14] That would resolve the TB's concern I think. [16:14] Like, US will always have a lot of apps and packages in the packageset as the images come pre-installed with many many tools [16:14] And we could grant PPU as needed, which sounds unlikely anyway. [16:14] rbasak: that would require a specific list of packages [16:14] We could agree to leave that at one DMB member's discretion. [16:15] in that sense, why not bring up by ourselves a list of the packages we feel *shouldn't* be in the pacakgeset and address that? [16:15] Feels like a lot of unnecessary work for something that seems unlikely to be needed. [16:15] I don't follow [16:15] you will eventually have uploaders for the ubutnustudio pacakgeset [16:15] We'd need to find consensus on that list and that'll take considerable time. [16:16] and if you feel ubuntustudio is wrong; then you should also look at xubuntu, lubuntu, etc. [16:16] Instead, if we all trust each other to be agreed on what "narrow" means, then we could just leave it at that, and approve PPU for those things using only one DMB member, like we do for existing DD uploaders. [16:16] otoh, having to round-trip to (a member of) the DMB for each package a US developer needs to upload is onerous, and scarcely better than going through the sponsorship queue [16:16] I'm just proposing a way forward to resolve this quickly. [16:16] his current PPU request will already cover 90% [16:17] #endvote [16:17] Voting ended on: to grant Rosco2 upload rights to the ubuntustudio packageset (take 2) [16:17] Votes for:1 Votes against:0 Abstentions:3 [16:17] Motion carried [16:17] meetingology: that's not a motion carried. [16:17] :) [16:17] Much quicker than going through the sponsorship queue IMHO, as a review would be unnecessary. Sponsorship in this case would be merely agreeing the PPU in principle, rather than having to round trip the TB, instead of actually having to review. [16:17] sil2100: I considered you a +0 fwiw; being unsure. [16:17] can we move on to Erich's application? [16:17] i.e. if it's not maintainable as a packageset, then there's a round trip for each package that has to be added to PPU, at exactly the time when this would cause friction for development [16:18] cyphermox: I think we should find a way forward for Rosco2 first as the urgent matter. [16:18] I believe that's what Eickmeyer wants too? [16:18] cyphermox: too bad this was introduced into the agenda so late, since I was actually starting on leaning towards +1'ing [16:18] But well [16:19] did we not already arrive at a resolution, given that he already has access to ubuntustudio-* as per earlier votes? [16:19] Yes. We need something that will satisfy the TB's requirement, otherwise 19.04 will likely get denied. [16:19] I am assuming that, given the reasons the last motion didn't carry, an equivalent motion for Eickmeyer also won't carry. [16:19] So we should spend our time trying to resolve the current flavor situation as requested by the TB as a priority [16:19] I can be back at the next meeting with a defined package set? [16:19] can I ask what the point of a packageset is that the DMB doesn't think anyone should be granted upload rights to? My understanding of packagesets is that they exist purely as objects to attach permissions to [16:19] vorlon: +1 [16:20] I don't think "anyone should be" is fair here. [16:20] This is a special case. In the usual case there would be an established set of developers already able to upload the packageset. [16:20] And we would only be considering whether somebody should be added to that set. [16:21] so unless the DMB's intent is to say that US is not releasable because there are no developers qualified to have upload rights on the packageset, IMHO far better to change the contents of the packageset to match what you think the US devs should be uploading [16:21] Sure [16:21] How should we resolve that list? [16:22] The TB has some idea since that set must be sufficient to meet their requiremnts. [16:22] Is this the DMB challenging the concept of flavour packagesets as has existed up until now, or the particular (apparently) buggy entries in ubuntustudio? [16:22] I'm not sure we have any idea right now, tbh. [16:23] We seem to differ on what a packageset even means. [16:23] rbasak: speaking as a single member of the TB, I think a packageset that is the disjunction of the contents of the US image, and all other flavor images, is sufficient for the requirement [16:23] cyphermox: anyway, for the last vote count me as a +1 actually [16:23] sil2100: thanks. [16:24] (but also, as noted above, the current packageset definitely looks buggy wrt including packages from main) [16:24] Anyway, seeing the results of the vote, the motion can still pass by votes of absent members [16:25] OK, so there are two paths forward right now that I can see. [16:25] I'm +1 to give Rosco2 upload to the set that vorlon defines above. If others agree, then that is a path to resolving the current issue. [16:25] Or, we can wait to see if the absent members will pass the previous motion. [16:27] I think first and foremost people who are in disagreement with the contents of the packageset as it currently is should have a look at the packageset update script and propose fixes; or agree to give upload rights as it is with the modulo that the contents will change a bit after a review. [16:28] I don't agree. You're the one trying to pass a motion with a broken packageset. [16:28] (and ill-defined proposed correctoins to that packageset) [16:28] The bugs pointed out are likely because the script isn't handling the desktop-minimal seed, FWIW [16:28] seed*s* [16:28] possibly [16:29] rbasak: it's fine not to agree, I'm trying to point out that I'm not sure that's a way forward. your "set vorlon defines above" doesn't currently exist and isn't all that better defined. [16:29] What if we just created a secondary manual packageset so we don't need to fix the script to resolve the current situation? [16:30] rbasak: what would be the contents of it? [16:30] https://paste.ubuntu.com/p/mWwQFjzPQ3/ [16:30] With that, gnome-software ends up in ubuntu-desktop [16:30] If that fixes it, then great, thanks :) [16:30] Laney: solid. [16:31] that does sound like it would fix it. [16:31] Of course you might want to make the real patch use globs or something [16:31] yup yup [16:31] I'll take care of that [16:31]