[19:00] <rbasak> o/
[19:02] <ddstreet> o/ here but in mtg so won't be able to participate much
[19:04]  * fginther is here if there are any questions regarding my delegate team request
[19:04] <slashd> o/ sorry I'm late
[19:04] <rafaeldtinoco> o/
[19:04] <slashd> same as ddstreet, I'm here but sprinting at the same time
[19:05] <rafaeldtinoco> I think everybody is busy today =\
[19:05] <slashd> do we have something on the agenda ?
[19:05] <rafaeldtinoco> yep lots of things for me (pkgsets)
[19:05] <rafaeldtinoco> ill open the meeting and go over it
[19:05] <rafaeldtinoco> if others are all busy
[19:05] <rafaeldtinoco> so I can update status
[19:06] <rafaeldtinoco> #startmeeting Developer Membership Board
[19:06] <meetingology> 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] <meetingology> Available commands: action commands idea info link nick
[19:07] <rafaeldtinoco> #chair rafaeldtinoco
[19:07] <meetingology> Current chairs: rafaeldtinoco
[19:07] <rafaeldtinoco> #topic Review of previous action items
[19:07] <rafaeldtinoco> rafaeldtinoco to put pkgset tooling to automatically update pkgsets (crontab)
[19:08] <rafaeldtinoco> this is done ^. pkgset changes will be done tomorrow after some exception addictions to the exceptions file
[19:08] <rafaeldtinoco> I'm still missing the wiki instructions (next items)
[19:09] <rafaeldtinoco> #action rafaeldtinoco link team delegation from DMB KB page when reading ddstreet updates (carried over)
[19:09] <meetingology> ACTION: rafaeldtinoco link team delegation from DMB KB page when reading ddstreet updates (carried over)
[19:09] <rafaeldtinoco> when instructions are ready
[19:09] <rafaeldtinoco> #action rafaeldtinoco to check edubuntu seed <-> pkgset relationship (generation) and if edubuntu pkgsets can be dropped (carried over)
[19:09] <meetingology> ACTION: rafaeldtinoco to check edubuntu seed <-> pkgset relationship (generation) and if edubuntu pkgsets can be dropped (carried over)
[19:09] <rafaeldtinoco> rafaeldtinoco add jackd2 as an exception (from ubuntu-server to audio-plugins perhaps)
[19:09] <rafaeldtinoco> done for the tomorrow run
[19:10] <rafaeldtinoco> #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> 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] <rafaeldtinoco> carrying this over. after tomorrow's pkgset changes I'll create and link to the wiki
[19:11] <rafaeldtinoco> #title Outstanding mailing list requests to assign
[19:11] <rafaeldtinoco> oops
[19:11] <rafaeldtinoco> #topic Outstanding mailing list requests to assign
[19:12] <rafaeldtinoco> ddstreet: there is a req for a delegate team
[19:12] <rafaeldtinoco> to a list of packages.. I believe we have to ask AA for the team creation putting dmb as the administrator
[19:12] <rafaeldtinoco> like you did before, right ?
[19:12] <rafaeldtinoco> Request for delagate team for DKMS modules (Francis Ginther)
[19:13] <rafaeldtinoco> https://lists.ubuntu.com/archives/devel-permissions/2020-July/001539.html
[19:13] <ddstreet> 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] <rbasak> o/
[19:13] <rbasak> I think there are two separate requests here really.
[19:14] <rafaeldtinoco> rbasak: go ahead pls
[19:14] <rbasak> One is to create an appropriate packageset for DKMS uploads
[19:14] <rbasak> The other is to delegate membership management of that team.
[19:14] <rafaeldtinoco> yep
[19:14] <rbasak> IMHO, it'll be easier if we treat them separately
[19:14] <rafaeldtinoco> sounds fair
[19:14] <rafaeldtinoco> need a volunteer for those
[19:15] <rafaeldtinoco> (as im already late for the pkgset scripts)
[19:15] <rbasak> They're both decisions that will need voting on by the board as a whole I think
[19:15] <rafaeldtinoco> rbasak: even if the given users
[19:15] <rafaeldtinoco> already have permissions ?
[19:15] <rbasak> 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] <rbasak> rafaeldtinoco: I don't think they do?
[19:16] <rafaeldtinoco> yep likely not (perhaps colin only ?) but yep, they dont
[19:16] <rbasak> fginther: ^ am I right about that?
[19:16] <rbasak> overlap with uploaders of those packages> eg. virtualbox
[19:17] <fginther> 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] <rbasak> That may need coordination with people who generally upload that package.
[19:17] <rbasak> fginther: yes, but really I mean the inverse - are there people who cannot currently upload those packages?
[19:17] <rbasak> (in the proposed list of members)
[19:18] <fginther> Yes, some of the people on the list I proposed do not already have access to any of these packages
[19:18] <fginther> they have may uploads through sponsors only
[19:18] <rbasak> Thanks
[19:19] <rbasak> 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] <rbasak> Though, to be clear, this is clearly a good thing that we want to enable :)
[19:20] <teward> oops i'm late
[19:20] <rafaeldtinoco> rbasak: what if we consider this a seed ?
[19:20] <rafaeldtinoco> "like a seed"
[19:20] <sil2100> Same here
[19:20] <rbasak> (that the people who volunteer to keep the DKMS packages in good shape not be blocked, that is)
[19:21] <rafaeldtinoco> and we can have voting in adding/removing ppl from the "seed"
[19:21] <rbasak> 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] <rafaeldtinoco> to gain rights etc
[19:21] <rafaeldtinoco> ppu rights would be still kept (per package basis)
[19:21] <rafaeldtinoco> the whole list would be managed as a pkgset
[19:21] <rafaeldtinoco> and we would vote to add new developers
[19:22] <rafaeldtinoco> just like ubuntustudio or xubuntu, etc
[19:22] <rbasak> Sure - I think that's the proposal :)
[19:22] <rafaeldtinoco> should a seed be created then (first ?)
[19:23] <rafaeldtinoco> with all those pkgs
[19:23] <rbasak> I'm not sure why we need a seed
[19:23] <rbasak> Can this just be a packageset?
[19:23] <rafaeldtinoco> well adding/removing pkgs from the seed
[19:23] <rafaeldtinoco> would turn this automatically managed
[19:23] <rbasak> "Packages that ship DKMS modules that need updating to support new kernel version"
[19:23] <rbasak> "Packages that ship DKMS modules that need updating to support new kernel versions"
[19:24] <rbasak> We can add/remove packages to a packageset just the same as we can to a seed
[19:24] <rafaeldtinoco> we do, yep
[19:24] <rafaeldtinoco> not automatically, but yep
[19:24] <rbasak> Changing seeds is also not automatic :)
[19:24] <rafaeldtinoco> yep
[19:24] <rafaeldtinoco> ok
[19:24] <rafaeldtinoco> sounds good.. im 1/2 suggesting 1/2 asking
[19:24] <rafaeldtinoco> using your experience
[19:25] <rafaeldtinoco> #chair rbasak
[19:25] <meetingology> Current chairs: rafaeldtinoco rbasak
[19:25] <rafaeldtinoco> mind adding the actions ?
[19:25] <rbasak> We haven't decided anything yet!
[19:25] <rafaeldtinoco> to create the pkgset with all those packages
[19:26] <rafaeldtinoco> and then we would have to vote individually
[19:26] <rbasak> Sure - but we still need to decide on criteria and process for adding uploaders to that packageset
[19:26] <rafaeldtinoco> to add them to a team having rights
[19:26] <rafaeldtinoco> i see
[19:26] <rafaeldtinoco> having work sponsored ?
[19:26] <rafaeldtinoco> on dkms packages ?
[19:26] <rafaeldtinoco> (like MOTU ?)
[19:27] <rbasak> 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] <rafaeldtinoco> fginther: who has been sponsoring (majorly) the work ?
[19:28] <rbasak> That's a good question. Can the existing sponsors speak to the appropriateness of the request and the initial proposed member list?
[19:28] <fginther> I believe mostly Alberto Milone and Timo Aaltonen
[19:32] <rbasak> 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] <rbasak> 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] <rbasak> (I don't think a new delegate team has been created in at least ten years!)
[19:33] <rafaeldtinoco> rbasak: are you thinking on enabling sponsors/coredevs (to this delegate team) first
[19:33] <rafaeldtinoco> and then going 1 by 1 in the application according to their application ?
[19:33] <rbasak> rafaeldtinoco: core devs can already upload/sponsor these pacakges
[19:34] <rafaeldtinoco> yep, i know (just did a edit-acl query on both)
[19:34] <rbasak> Oh
[19:34] <rbasak> You mean for delegation decisions
[19:34] <rafaeldtinoco> yep
[19:34] <rbasak> 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] <rbasak> It's not like it's a team responsible for their own product
[19:35] <rbasak> eg. if the kernel team makes a mess of kernel packaging, the kernel team have to clean up the mess
[19:35] <rbasak> 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] <rafaeldtinoco> yep we have some crossed things here
[19:36] <rbasak> Here's what I propose
[19:36] <rbasak> to make progress
[19:36] <rafaeldtinoco> ohhh
[19:36] <rafaeldtinoco> dpdk should get out of this list
[19:36] <rbasak> 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] <rbasak> 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] <rafaeldtinoco> asking sponsored uploads ?
[19:37] <rafaeldtinoco> (so we can check ?)
[19:38] <rbasak> 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] <rbasak> required
[19:38] <rbasak> rafaeldtinoco: yes
[19:39] <rbasak> Then we grant packageset uploaders initially without delegation
[19:39] <rafaeldtinoco> (1) merge reviews would satisfy that
[19:39] <rafaeldtinoco> (2) agreed
[19:39] <rbasak> (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] <rafaeldtinoco> for (2) warning about migration and regressions as well (responsible until the migration happens)
[19:40] <rbasak> Yes - all the normal stuff about taking responsibility for uploads applies
[19:40] <rafaeldtinoco> ok
[19:40] <rbasak> Then we see how it goes, and can consider delegation later.
[19:40] <rafaeldtinoco> so you would do an initial
[19:40] <rafaeldtinoco> packageset + PPU ?
[19:40] <rafaeldtinoco> to each of them
[19:41] <rbasak> 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] <rafaeldtinoco> based on the outcome of the sponsors feedback
[19:41] <rafaeldtinoco> and our voting
[19:42] <rbasak> Right
[19:42] <rafaeldtinoco> sounds nice
[19:42] <rbasak> fginther: how does that sound to you?
[19:42] <rbasak> And does anyone else have comments?
[19:43] <fginther> That sounds reasonable
[19:43] <fginther> Thanks for proposing this
[19:44] <rbasak> Thanks. Let me put a motion together
[19:44] <rbasak> rafaeldtinoco: why did you say that dpdk should be excluded?
[19:44] <rafaeldtinoco> i think cpaelzer takes care of it
[19:45] <rafaeldtinoco> not sure about the kernel modules
[19:46] <rafaeldtinoco> that can be checked/addressed with the pkgset creation
[19:46] <rafaeldtinoco> and taking in consideration that uploads will have to be synced with whoever is in charge of the package uploads usually
[19:46] <rbasak> IMHO, that wouldn't disqualify dkms from this packageset
[19:47] <rbasak> 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] <rafaeldtinoco> y3p
[19:47] <rbasak> 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] <rafaeldtinoco> makes sense
[19:48] <rafaeldtinoco> i just have one concern
[19:48] <rafaeldtinoco> 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] <rbasak> All we can do is set our expectations
[19:51] <rafaeldtinoco> ok.. so your suggestion does not require voting, but the upload rights will need
[19:51] <rbasak> Assuming good faith, we can steer people who we think are mismatching our expectations.
[19:51] <rafaeldtinoco> and one of the actions is to ask feedback from the current sponsors
[19:51] <rbasak> Ultimately the DMB can remove people from uploading teams.
[19:52] <rbasak> I think we should vote on the following motions
[19:52] <rafaeldtinoco> yes, and usually on upload conflicts/issues usually a conversation "please sync with me next time" is enough
[19:52] <rbasak> https://paste.ubuntu.com/p/YW4wTcB6V9/
[19:53] <rbasak> Any comments, suggestions, proposed amendements before I start a vote for these?
[19:53] <rafaeldtinoco> not sure we have quorum (and if we dont id suggest that we continue through the mailing list)
[19:53] <rafaeldtinoco> no questions
[19:54] <rbasak> #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] <meetingology> 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] <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)
[19:54] <rbasak> +1
[19:54] <meetingology> +1 received from rbasak
[19:54] <rafaeldtinoco> +1
[19:54] <meetingology> +1 received from rafaeldtinoco
[19:54] <rbasak> sil2100, slashd, ddstreet: ^ able to vote?
[19:56] <rafaeldtinoco> teward as well ^
[19:58] <rbasak> I guess we'll have to take this to the mailing list.
[19:58] <rafaeldtinoco> yep
[19:58] <rbasak> I'll post my proposed motions there and ask for votes
[19:58] <rbasak> #endvote
[19:58] <meetingology> 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] <meetingology> Votes for:2 Votes against:0 Abstentions:0
[19:58] <meetingology> Motion carried
[19:58] <rafaeldtinoco> but do put here the other one
[19:58] <rafaeldtinoco> so we have documented
[19:58] <rafaeldtinoco> if you dont mind
[19:59] <rbasak> We might as well get some votes in I suppose.
[19:59] <rbasak> #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] <meetingology> 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] <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)
[19:59] <rbasak> 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] <rbasak> 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] <rbasak> +1
[19:59] <meetingology> +1 received from rbasak
[19:59] <rafaeldtinoco> +1
[19:59] <meetingology> +1 received from rafaeldtinoco
[19:59] <rbasak> The others clearly aren't here right now, so
[19:59] <rbasak> #endvote
[19:59] <meetingology> 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] <meetingology> Votes for:2 Votes against:0 Abstentions:0
[19:59] <meetingology> Motion carried
[19:59] <rbasak> I'll follow up on the ML
[19:59] <rafaeldtinoco> nice! tks!
[19:59] <rbasak> Any further comments for this agenda item?
[20:00] <rafaeldtinoco> not from me
[20:01] <rbasak> rafaeldtinoco: back to you then to continue with the agenda please?
[20:02] <rafaeldtinoco> definitely
[20:02] <rafaeldtinoco> thanks!
[20:02] <rafaeldtinoco> #topic Verify ubuntu-budgie packages, possibly remove fossfreedom personal packageset if no longer needed
[20:02] <rafaeldtinoco> pos
[20:02] <rafaeldtinoco> ops.. this was supposed to be an item of TB bugs
[20:02] <rafaeldtinoco> but...
[20:02] <rafaeldtinoco> Verify ubuntu-budgie packages, possibly remove fossfreedom personal packageset if no longer needed
[20:03] <rafaeldtinoco> we havent heard feedback from fossfreedom regarding this..
[20:04] <rafaeldtinoco> i believe we can move on, but will wait another meeting on that item
[20:04] <rafaeldtinoco> to discuss when we have more quorum
[20:04] <rafaeldtinoco> #topic Any other business
[20:04] <rafaeldtinoco> any other business anyone would like to bring ?
[20:04] <rafaeldtinoco> ill wait for ~1 minute here before closing the meeting
[20:06] <rafaeldtinoco> alright.. calling it then
[20:06] <rafaeldtinoco> @endmeeting
[20:06] <rafaeldtinoco> #endmeeting
[20:06] <meetingology> Meeting ended Mon Jul 13 20:06:13 2020 UTC.
[20:06] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2020/ubuntu-meeting.2020-07-13-19.06.moin.txt
[20:06] <rafaeldtinoco> thank you all!
[20:07]  * rafaeldtinoco will update the agenda items in wiki
[20:12] <teward> sorry I got called off for work stuff >.>
[20:12] <teward> hate it when work stuff crops up
[21:00] <slashd> rbasak: sorry just get noticed, we run into severals mtg here my apologize
[21:00] <slashd> apologies