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> 
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 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 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 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