== Meeting information == * #ubuntu-meeting: Developer Membership Board, 13 Jul at 19:06 — 20:06 UTC * Full logs at [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2020/ubuntu-meeting.2020-07-13-19.06.log.html]] == Meeting summary == === Review of previous action items === The discussion about "Review of previous action items" started at 19:07. * ''ACTION:'' rafaeldtinoco link team delegation from DMB KB page when reading ddstreet updates (carried over) * ''ACTION:'' rafaeldtinoco to check edubuntu seed <-> pkgset relationship (generation) and if edubuntu pkgsets can be dropped (carried over) * ''ACTION:'' rafaeldtinoco to create, for now, a small "what-to-do" for pkgset changes in -devel (document exceptions inclusion for DMB team) (carried over) === Outstanding mailing list requests to assign === The discussion about "Outstanding mailing list requests to assign" started at 19:11. * ''LINK:'' https://lists.ubuntu.com/archives/devel-permissions/2020-July/001539.html * ''LINK:'' https://paste.ubuntu.com/p/YW4wTcB6V9/ * ''Vote:'' Create a DKMS packageset defined as "Packages that ship DKMS modules that need updating to support new kernel versions" once we have further agreed upon at least one uploader to be able to upload to this packageset. (Carried) * ''Vote:'' Create a DKMS packageset uploading team once we have further agreed upon at least one uploader to be added to this team. This team will be authorised to upload to the DKMS packageset subject to two requirements. Requirement 1: that they coordinate as required by the teams that already handle these packages; for example if a non-trivial fix is required that has wider consequences than just the (Carried) === Verify ubuntu-budgie packages, possibly remove fossfreedom personal packageset if no longer needed === The discussion about "Verify ubuntu-budgie packages, possibly remove fossfreedom personal packageset if no longer needed" started at 20:02. === Any other business === The discussion about "Any other business" started at 20:04. == Vote results == * [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2020/ubuntu-meeting.2020-07-13-19.06.log.html#172 Create a DKMS packageset defined as "Packages that ship DKMS modules that need updating to support new kernel versions" once we have further agreed upon at least one uploader to be able to upload to this packageset.]] * Motion carried (For/Against/Abstained 2/0/0) * Voters rbasak, rafaeldtinoco * [[http://ubottu.com/meetingology/logs/ubuntu-meeting/2020/ubuntu-meeting.2020-07-13-19.06.log.html#192 Create a DKMS packageset uploading team once we have further agreed upon at least one uploader to be added to this team. This team will be authorised to upload to the DKMS packageset subject to two requirements. Requirement 1: that they coordinate as required by the teams that already handle these packages; for example if a non-trivial fix is required that has wider consequences than just the]] * Motion carried (For/Against/Abstained 2/0/0) * Voters rbasak, rafaeldtinoco == Action items, by person == * ddstreet * rafaeldtinoco link team delegation from DMB KB page when reading ddstreet updates (carried over) * rafaeldtinoco * rafaeldtinoco link team delegation from DMB KB page when reading ddstreet updates (carried over) * rafaeldtinoco to check edubuntu seed <-> pkgset relationship (generation) and if edubuntu pkgsets can be dropped (carried over) * rafaeldtinoco to create, for now, a small "what-to-do" for pkgset changes in -devel (document exceptions inclusion for DMB team) (carried over) == Done items == * (none) == People present (lines said) == * rafaeldtinoco (114) * rbasak (81) * meetingology (22) * fginther (6) * teward (1) * sil2100 (1) * ddstreet (1) == Full Log == 19:06 #startmeeting Developer Membership Board 19:06 Meeting started Mon Jul 13 19:06:58 2020 UTC. The chair is rafaeldtinoco. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 19:06 19:06 Available commands: action commands idea info link nick 19:07 #chair rafaeldtinoco 19:07 Current chairs: rafaeldtinoco 19:07 #topic Review of previous action items 19:07 rafaeldtinoco to put pkgset tooling to automatically update pkgsets (crontab) 19:08 this is done ^. pkgset changes will be done tomorrow after some exception addictions to the exceptions file 19:08 I'm still missing the wiki instructions (next items) 19:09 #action rafaeldtinoco link team delegation from DMB KB page when reading ddstreet updates (carried over) 19:09 * meetingology rafaeldtinoco link team delegation from DMB KB page when reading ddstreet updates (carried over) 19:09 when instructions are ready 19:09 #action rafaeldtinoco to check edubuntu seed <-> pkgset relationship (generation) and if edubuntu pkgsets can be dropped (carried over) 19:09 * meetingology rafaeldtinoco to check edubuntu seed <-> pkgset relationship (generation) and if edubuntu pkgsets can be dropped (carried over) 19:09 rafaeldtinoco add jackd2 as an exception (from ubuntu-server to audio-plugins perhaps) 19:09 done for the tomorrow run 19:10 #action rafaeldtinoco to create, for now, a small "what-to-do" for pkgset changes in -devel (document exceptions inclusion for DMB team) (carried over) 19:10 * meetingology rafaeldtinoco to create, for now, a small "what-to-do" for pkgset changes in -devel (document exceptions inclusion for DMB team) (carried over) 19:10 carrying this over. after tomorrow's pkgset changes I'll create and link to the wiki 19:11 #title Outstanding mailing list requests to assign 19:11 oops 19:11 #topic Outstanding mailing list requests to assign 19:12 ddstreet: there is a req for a delegate team 19:12 to a list of packages.. I believe we have to ask AA for the team creation putting dmb as the administrator 19:12 like you did before, right ? 19:12 Request for delagate team for DKMS modules (Francis Ginther) 19:13 https://lists.ubuntu.com/archives/devel-permissions/2020-July/001539.html 19:13 we are able to create the team ourself, but creation of the packageset has to be sent to the TB, at least that's my understanding 19:13 o/ 19:13 I think there are two separate requests here really. 19:14 rbasak: go ahead pls 19:14 One is to create an appropriate packageset for DKMS uploads 19:14 The other is to delegate membership management of that team. 19:14 yep 19:14 IMHO, it'll be easier if we treat them separately 19:14 sounds fair 19:14 need a volunteer for those 19:15 (as im already late for the pkgset scripts) 19:15 They're both decisions that will need voting on by the board as a whole I think 19:15 rbasak: even if the given users 19:15 already have permissions ? 19:15 One complicating factor here is that the DKMS fixing packageset can probably be expected to have quite a bit of overlap with uploaders of those packages 19:15 rafaeldtinoco: I don't think they do? 19:16 yep likely not (perhaps colin only ?) but yep, they dont 19:16 fginther: ^ am I right about that? 19:16 overlap with uploaders of those packages> eg. virtualbox 19:17 rbasak, you mean folks like colin already having per-package upload rights to some of those? Yes, I think there will be a few cases of this. 19:17 That may need coordination with people who generally upload that package. 19:17 fginther: yes, but really I mean the inverse - are there people who cannot currently upload those packages? 19:17 (in the proposed list of members) 19:18 Yes, some of the people on the list I proposed do not already have access to any of these packages 19:18 they have may uploads through sponsors only 19:18 Thanks 19:19 On the complicating factor I mentioned about, the complication in my view is that it seems odd to me that when an existing team is already close to a package, a separate team (eg. the DKMS maintainence team) would decide for themselves to add new people who can upload that package without reference to the team that generally maintains it. 19:20 Though, to be clear, this is clearly a good thing that we want to enable :) 19:20 oops i'm late 19:20 rbasak: what if we consider this a seed ? 19:20 "like a seed" 19:20 Same here 19:20 (that the people who volunteer to keep the DKMS packages in good shape not be blocked, that is) 19:21 and we can have voting in adding/removing ppl from the "seed" 19:21 rafaeldtinoco: that's fine but it's the same difficulty as we already have with seeds I think. How overlaps are handled has never been very well defined 19:21 to gain rights etc 19:21 ppu rights would be still kept (per package basis) 19:21 the whole list would be managed as a pkgset 19:21 and we would vote to add new developers 19:22 just like ubuntustudio or xubuntu, etc 19:22 Sure - I think that's the proposal :) 19:22 should a seed be created then (first ?) 19:23 with all those pkgs 19:23 I'm not sure why we need a seed 19:23 Can this just be a packageset? 19:23 well adding/removing pkgs from the seed 19:23 would turn this automatically managed 19:23 "Packages that ship DKMS modules that need updating to support new kernel version" 19:23 "Packages that ship DKMS modules that need updating to support new kernel versions" 19:24 We can add/remove packages to a packageset just the same as we can to a seed 19:24 we do, yep 19:24 not automatically, but yep 19:24 Changing seeds is also not automatic :) 19:24 yep 19:24 ok 19:24 sounds good.. im 1/2 suggesting 1/2 asking 19:24 using your experience 19:25 #chair rbasak 19:25 Current chairs: rafaeldtinoco rbasak 19:25 mind adding the actions ? 19:25 We haven't decided anything yet! 19:25 to create the pkgset with all those packages 19:26 and then we would have to vote individually 19:26 Sure - but we still need to decide on criteria and process for adding uploaders to that packageset 19:26 to add them to a team having rights 19:26 i see 19:26 having work sponsored ? 19:26 on dkms packages ? 19:26 (like MOTU ?) 19:27 Sponsored by whom? Who is allowed to be a sponsor for these packages, and how do we decide who can do that? That's what we need to decide. 19:27 fginther: who has been sponsoring (majorly) the work ? 19:28 That's a good question. Can the existing sponsors speak to the appropriateness of the request and the initial proposed member list? 19:28 I believe mostly Alberto Milone and Timo Aaltonen 19:32 Can we ask them what level of endorsement they're willing to provide for the invididual proposed initial members to be uploading to these packages? 19:32 That's how a normal PPU application would work, and it makes sense to me as a starting point for this more complex request. 19:33 (I don't think a new delegate team has been created in at least ten years!) 19:33 rbasak: are you thinking on enabling sponsors/coredevs (to this delegate team) first 19:33 and then going 1 by 1 in the application according to their application ? 19:33 rafaeldtinoco: core devs can already upload/sponsor these pacakges 19:34 yep, i know (just did a edit-acl query on both) 19:34 Oh 19:34 You mean for delegation decisions 19:34 yep 19:34 Because of the complication I mentioned above, I'm not sure it even makes sense for the delegate team to the same as the uploading team in this case. 19:34 It's not like it's a team responsible for their own product 19:35 eg. if the kernel team makes a mess of kernel packaging, the kernel team have to clean up the mess 19:35 But that's not necessarily the case if someone drives by fixing a DKMS issue (good) at the cost of the rest of the packaging (bad) 19:36 yep we have some crossed things here 19:36 Here's what I propose 19:36 to make progress 19:36 ohhh 19:36 dpdk should get out of this list 19:36 We start by agreeing to create a packageset for this, though there's no reason to actually create it until we have uploaders. 19:37 We ask existing sponsors for endorsements for an initial set of uploaders, and judge them by normal standards as we might for PPU. 19:37 asking sponsored uploads ? 19:37 (so we can check ?) 19:38 I would add two requirements for uploaders acting under the privilege of this packageset: 1) that they coordinate as required by the teams that already handle these packages - if a non-trivial fix is required that has wider consequences than just the DKMS package, for example, that the maintaining teams get consulted first; and 2) no uploading of things not related to DKMS - regular sponsorship 19:38 required 19:38 rafaeldtinoco: yes 19:39 Then we grant packageset uploaders initially without delegation 19:39 (1) merge reviews would satisfy that 19:39 (2) agreed 19:39 (1) agreed, but I wouldn't want to require them. Some maintenance teams have other workflows. As long as the teams are satisfied that's what matters. 19:40 for (2) warning about migration and regressions as well (responsible until the migration happens) 19:40 Yes - all the normal stuff about taking responsibility for uploads applies 19:40 ok 19:40 Then we see how it goes, and can consider delegation later. 19:40 so you would do an initial 19:40 packageset + PPU ? 19:40 to each of them 19:41 Yes - creation of a packageset and an uploading team initially managed by the DMB, and we consider adding members to that team individually. 19:41 based on the outcome of the sponsors feedback 19:41 and our voting 19:42 Right 19:42 sounds nice 19:42 fginther: how does that sound to you? 19:42 And does anyone else have comments? 19:43 That sounds reasonable 19:43 Thanks for proposing this 19:44 Thanks. Let me put a motion together 19:44 rafaeldtinoco: why did you say that dpdk should be excluded? 19:44 i think cpaelzer takes care of it 19:45 not sure about the kernel modules 19:46 that can be checked/addressed with the pkgset creation 19:46 and taking in consideration that uploads will have to be synced with whoever is in charge of the package uploads usually 19:46 IMHO, that wouldn't disqualify dkms from this packageset 19:47 The packageset uploaders would be expected to coordinate with cpaelzer as required, which could mean that cpaelzer continues to take care of it. 19:47 y3p 19:47 But if cpaelzer is out, the packageset uploaders would still be able to do what is required, which I think is the goal anyway 19:48 makes sense 19:48 i just have one concern 19:48 that is.. about enforcing that this coordination happens.. but we dont have a way to enforce among core devs currently, for example.. so it is the same. 19:50 All we can do is set our expectations 19:51 ok.. so your suggestion does not require voting, but the upload rights will need 19:51 Assuming good faith, we can steer people who we think are mismatching our expectations. 19:51 and one of the actions is to ask feedback from the current sponsors 19:51 Ultimately the DMB can remove people from uploading teams. 19:52 I think we should vote on the following motions 19:52 yes, and usually on upload conflicts/issues usually a conversation "please sync with me next time" is enough 19:52 https://paste.ubuntu.com/p/YW4wTcB6V9/ 19:53 Any comments, suggestions, proposed amendements before I start a vote for these? 19:53 not sure we have quorum (and if we dont id suggest that we continue through the mailing list) 19:53 no questions 19:54 #vote Create a DKMS packageset defined as "Packages that ship DKMS modules that need updating to support new kernel versions" once we have further agreed upon at least one uploader to be able to upload to this packageset. 19:54 Please vote on: Create a DKMS packageset defined as "Packages that ship DKMS modules that need updating to support new kernel versions" once we have further agreed upon at least one uploader to be able to upload to this packageset. 19:54 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) 19:54 +1 19:54 +1 received from rbasak 19:54 +1 19:54 +1 received from rafaeldtinoco 19:54 sil2100, slashd, ddstreet: ^ able to vote? 19:56 teward as well ^ 19:58 I guess we'll have to take this to the mailing list. 19:58 yep 19:58 I'll post my proposed motions there and ask for votes 19:58 #endvote 19:58 Voting ended on: Create a DKMS packageset defined as "Packages that ship DKMS modules that need updating to support new kernel versions" once we have further agreed upon at least one uploader to be able to upload to this packageset. 19:58 Votes for:2 Votes against:0 Abstentions:0 19:58 Motion carried 19:58 but do put here the other one 19:58 so we have documented 19:58 if you dont mind 19:59 We might as well get some votes in I suppose. 19:59 #vote Create a DKMS packageset uploading team once we have further agreed upon at least one uploader to be added to this team. This team will be authorised to upload to the DKMS packageset subject to two requirements. Requirement 1: that they coordinate as required by the teams that already handle these packages; for example if a non-trivial fix is required that has wider consequences than just the 19:59 Please vote on: Create a DKMS packageset uploading team once we have further agreed upon at least one uploader to be added to this team. This team will be authorised to upload to the DKMS packageset subject to two requirements. Requirement 1: that they coordinate as required by the teams that already handle these packages; for example if a non-trivial fix is required that has wider consequences than just the 19:59 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) 19:59 DKMS package, then the team will be expected to be consulted first. Requirement 2: no uploading of things not related to DKMS when exercising the privileges of this team. If that means that a team member cannot upload, the normal sponsorship process will need to be followed. 19:59 FTR, I put in these restrictions in the hope that it will reduce the bar required to get applicants added to the team. 19:59 +1 19:59 +1 received from rbasak 19:59 +1 19:59 +1 received from rafaeldtinoco 19:59 The others clearly aren't here right now, so 19:59 #endvote 19:59 Voting ended on: Create a DKMS packageset uploading team once we have further agreed upon at least one uploader to be added to this team. This team will be authorised to upload to the DKMS packageset subject to two requirements. Requirement 1: that they coordinate as required by the teams that already handle these packages; for example if a non-trivial fix is required that has wider consequences than just the 19:59 Votes for:2 Votes against:0 Abstentions:0 19:59 Motion carried 19:59 I'll follow up on the ML 19:59 nice! tks! 19:59 Any further comments for this agenda item? 20:00 not from me 20:01 rafaeldtinoco: back to you then to continue with the agenda please? 20:02 definitely 20:02 thanks! 20:02 #topic Verify ubuntu-budgie packages, possibly remove fossfreedom personal packageset if no longer needed 20:02 pos 20:02 ops.. this was supposed to be an item of TB bugs 20:02 but... 20:02 Verify ubuntu-budgie packages, possibly remove fossfreedom personal packageset if no longer needed 20:03 we havent heard feedback from fossfreedom regarding this.. 20:04 i believe we can move on, but will wait another meeting on that item 20:04 to discuss when we have more quorum 20:04 #topic Any other business 20:04 any other business anyone would like to bring ? 20:04 ill wait for ~1 minute here before closing the meeting 20:06 alright.. calling it then 20:06 @endmeeting 20:06 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)