15:25 <rbasak> #startmeeting Developer Membership Board
15:25 <meetingology> Meeting started Mon Feb 13 15:25:16 2017 UTC.  The chair is rbasak. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
15:25 <meetingology> 
15:25 <meetingology> Available commands: action commands idea info link nick
15:25 <rbasak> #topic Review of previous action items
15:25 <rbasak> rbasak to get mapreri's PPU additions done by the TB (done)
15:25 <rbasak> rbasak to address GunnarHj's im-config xenial question on the ML (done)
15:25 <rbasak> rbasak to start a discussion on the ML regarding the possibility of setting up a specialized team with access to upload packages to stable releases only (done)
15:25 <rbasak> So all done.
15:25 <mapreri> yeah, done \o/
15:25 <rbasak> I see no applications on the agenda, so straight to:
15:26 <rbasak> #topic Outstanding mailing list requests to assign
15:26 <rbasak> Are there any?
15:26 <rbasak> "Please add xfdashboard to xubuntu packageset"
15:26 <cyphermox> I can do that
15:26 <jbicha> I believe fossfreedom's application has been waiting for votes for a while
15:27 <cyphermox> I suppose I'll need to do another refresh of the packageset for Kubuntu today
15:27 <rbasak> Thanks!
15:27 <rbasak> #action cyphermox to handle Sean Davis' xfdashboard packageset request
15:27 * meetingology cyphermox to handle Sean Davis' xfdashboard packageset request
15:28 <rbasak> #action cyphermox to refresh Kubuntu packageset
15:28 * meetingology cyphermox to refresh Kubuntu packageset
15:29 <rbasak> Looks like micahg, cyphermox, sil2000 and I have already voted on fossfreedom's request.
15:29 <micahg> yeah, that was addressed in a meeting
15:30 <rbasak> Oh, and BenC voted too.
15:31 <rbasak> jbicha: so fossfreedom needs a +1 from one or both of infinity or bdmurray, and neither are here.
15:31 <rbasak> jbicha: everyone else has voted I think.
15:31 <cyphermox> yeah, I don't remember that there was a mail about that -- the outcome was roughly that we needed to start defining a packageset before people applied to join it
15:32 <rbasak> Well, I prefer to do it the other way round - agree in principle to a yet-to-be-defined packageset, then agree the packageset.
15:32 <rbasak> But yeah, the packageset does eventually need to be defined.
15:32 <cyphermox> well, we can't approve joining something that doesn't exist
15:33 <micahg> it needs to be defined, not created before people can apply, we can defer creation until someone actually applies successfully
15:33 <cyphermox> so, I would say, having a list of the few budgie-specific packages first would be a good thing
15:33 <cyphermox> semantics
15:33 <rbasak> I really don't think this matters.
15:33 <rbasak> Anyway, this can't proceed without a +1 vote from bdmurray or infinity.
15:34 <cyphermox> the LP tasks aren't a big deal, but I'm not going to approve a packageset being "whatever X puts in list Y" just like that, until I know that X is a core-dev, at least
15:34 <rbasak> It would be the DMB.
15:34 <cyphermox> or that the packages are very clearly within the purview of the list
15:34 <cyphermox> so how we've always defined packagesets was:
15:34 <cyphermox> figure out a phrase that generalizes what goes in it
15:35 <cyphermox> then check package against definition, if it fits, add to packageset
15:35 <rbasak> I still don't think this matters.
15:35 <cyphermox> why?
15:35 <rbasak> It's a bootstrapping problem. Unless fossfreedom gets a +1, even in principle, what the packageset might contain is moot.
15:36 <rbasak> And you've already voted.
15:36 <cyphermox> I'm already +1 for letting him upload some budgie-specific packages
15:36 <rbasak> Right. And he doesn't have enough +1s.
15:36 <rbasak> (AFAICT)
15:36 <cyphermox> that's a different problem
15:36 <rbasak> So let's get bdmurray and infinity to vote.
15:37 <rbasak> Until then, is there anything further to discuss on this?
15:37 <cyphermox> I'm certainly not +1 for letting him upload network-manager, for example. are you?
15:37 <rbasak> No.
15:37 <rbasak> But the DMB will not put network-manager into any future budgie packageset. I certainly wouldn't vote for that.
15:37 <cyphermox> well then, are you +1 for budgie-welcome or whatever that package is?
15:37 <rbasak> Sure.
15:38 <rbasak> I mean for the packageset.
15:38 <cyphermox> not for fossfreedom uploading?
15:38 <rbasak> Not for fossfreedom I'm afraid, as I voted -1 for him to join any budgie packageset for reasons I've given.
15:38 <cyphermox> I don't recall the reasons
15:38 <rbasak> https://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-12-12-19.03.log.html
15:40 <rbasak> Is there anything further to discuss on this topic right now?
15:40 <rbasak> If not let's move on.
15:40 <cyphermox> no
15:41 <rbasak> I don't see anything else outstanding on the ML. Dave Chiluk's vote appears to be progressing.
15:41 <rbasak> #topic Any other business
15:41 <rbasak> I'd like feedback on my ML thread about SRU uploaders please.
15:42 <rbasak> Nobody on the DMB has replied.
15:43 <rbasak> Based on the other replies so far, I'm in favour of having a new class of uploader - SRU uploaders, who can upload anything to the queues in stable releases. It seems that LP will support this. They'll still get a review from ~ubuntu-sru of course.
15:43 <rbasak> But I have no idea what anyone else on the DMB thinks.
15:43 <rbasak> Please tell me.
15:48 <chiluk> I think our team would appreciate the intermediary positition for sure.
15:48 <chiluk> And thanks to those who've already voted.
15:50 <chiluk> rbasak.  I don't see a vote from you.  We could finish the vote now assuming you are a +1 on that.
15:50 <chiluk> it'd be nice to put that to rest.
15:51 <rbasak> I'll need to review, but I don't remember being confident about voting +1 for core dev. That's why I'd like to resolve the SRU uploader question.
15:51 <chiluk> I realize you are probably wanting to grant sru-uploader .
15:51 <rbasak> Right
15:51 <sil2100> Sorry for being late, I always seem to think the meeting is an hour later...
15:51 <chiluk> that's fine. I won't hold it against you.
15:51 <rbasak> I'd also like to know what other DMB members think about what a core dev should mean.
15:51 <micahg> sil2100: in another few weeks it will be ;)
15:55 <rbasak> Anyone? Or are you all reading/thinking?
15:56 <micahg> rbasak: I think I'm in the same boat as you
15:56 <rbasak> OK, thanks.
15:56 <rbasak> cyphermox? sil2100? BenC? Opinions?
15:57 <micahg> (waiting to see outcome of SRU uploader discussion)
15:57 <rbasak> Oh
15:57 <rbasak> Well...what do you think about the SRU uploader discussion? :)
15:58 <cyphermox> rbasak: I think it's fine, but it "adds" work to the SRU team (more careful review, but then again, you always need to be carefully reviewing the packages). You're in that team though, so you already know about it
15:58 <micahg> I'm a bit conflicted, it's a novel idea for sure, I'm struggling with if it'll really solve an issue and if it's a direction we want to drive upload rights
15:58 <cyphermox> (that means I'm +1)
15:59 * sil2100 needs to get some context, one moment
15:59 <micahg> and I was worried about extra burden on SRU team as cyphermox mentioned
15:59 <rbasak> cyphermox: thanks. Yeah, I'm always carefully reviewing anyway, and I think we should only give this to people we trust can do SRUs correctly (and well).
16:00 <rbasak> I don't think we need uploaders to understand things like development release proposed migration and merges.
16:01 <rbasak> cyphermox: so I don't think there's really anything we have to worry about with respect to the quality of uploads that the SRU team will see. Any concern about that for an individual and I'd be -1 to give that person SRU uploader permissions.
16:01 <cyphermox> well, they need to understand proposed migration to a degree anyway
16:02 <rbasak> I'm only looking to remove requirements that clearly don't apply to SRUs, but do to core devs, to get people uploading SRUs sooner.
16:03 <rbasak> If, in your judgement of the requirements that are left, a candidate doesn't meet them, then I'd encourage you to vote -1 for SRU uploader anyway.
16:03 <cyphermox> yeah yeah
16:15 <sil2100> I'm +0 on the SRU-uploaders team
16:16 <sil2100> Since even though I think in some cases it might be useful, I'm not sure that it's worth the trouble of getting it done, since I don't know if we'd have a lot of people applying for such a team membership
16:16 <sil2100> Although I must say I d o not know how much work is required to get it implemented
16:16 <slashd> sil2100, there will at least ~10 ppl from my team that would be willing to apply for this
16:16 <chiluk> sil2100: we have about 20 on my team that would be interested
16:17 <slashd> yeah
16:17 <slashd> 20 sorry
16:17 <tinoco> =)
16:17 <rbasak> If it works, I believe it is just a matter of an LP team and an ACL entry by the TB.
16:17 <rbasak> No more work than a new packageset.
16:17 <tinoco> all of them following discussion
16:17 <chiluk> slashd: cloudy folks need to do sru's as well.
16:17 <slashd> chiluk, yep
16:18 <sil2100> hm, ok, so there is need for that then, but you must remember that getting upload rights for that team will be similar to what we give to core-devs, so anyway possibly those people could have applied for core-dev as well
16:18 <rbasak> BenC?
16:18 <chiluk> sil2100: which is exactly what I did.
16:19 <tinoco> sil2100: we wouldn't be touching devel
16:19 <tinoco> rbasak: right ?
16:19 <rbasak> tinoco: right. You'd still need a sponsor for devel.
16:19 <chiluk> tinoco in most cases.
16:19 <BenC> I would be +1 in theory, but I’m +/-0 at this point.
16:19 <tinoco> which raises question .. we would start SRU (upload) without sponsor for devel ?
16:19 <rbasak> Which is often a prerequisite for an SRU. However, I hope that it'll help speed things up (one sponsor needed once, rather than multiple times as stuff gets developed)
16:19 <micahg> another unanswered question is whether or not we grant membership to this team, I would suggest not to keep the bar for entry lower.  However, it seems the SRU team might be flooded with requests.  Has that team grown sufficiently to handle such an influx of uploads?
16:20 <sil2100> Yeah, just stable, but stable has even a bigger emphasis on good uploads, so uploaders need to have the knowledge - yes, there's the additional step of ubuntu-sru doing reviews of the uploads before accepting, but still
16:20 <BenC> I’m personally more geared toward an SRU role for the STS team and we would vote on who, from that team could fill that role to unblock the team.
16:20 <chiluk> micahg: it would be no more than current.
16:20 <rbasak> Also I think it'll provide a nice stepping stone.
16:20 <BenC> They would promote their best candidate
16:21 <rbasak> micahg: I'm not sure the SRU numbers would go up. STS will still drive the same number of (Canonical) customer requests. My intention is to reduce the latency.
16:21 <rbasak> micahg: but if the SRU numbers did go up, then I'd expect Canonical to put more into ~ubuntu-sru. Right now the majority of ~ubuntu-sru work is handled by Canonical staff anyway.
16:21 <chiluk> correct rbasak... numbers should stay about the same.  Maybe slightly higher by allowing us more time to work instead of harass uploaders
16:22 <rbasak> micahg: I recently joined ~ubuntu-sru to alleviate the load, as has sil2100 - and we're both sponsored by Canonical to do this.
16:22 <chiluk> rbasak..becoming a member of ubuntu-sru has been one of my stated goals all along.
16:22 <sil2100> Anyway, I'm fine with any outcome
16:24 <rbasak> Thank you everyone for your opinions.
16:24 <rbasak> I'll propose to add an ~ubuntu-sru-uploaders team then. I'll respond to the mailing list.
16:25 <rbasak> And we can discuss it there, and vote for it either on the list or at the next meeting.
16:25 <rbasak> I think we'd need a quorate vote.
16:25 <rbasak> Any other AOB?
16:31 <rbasak> OK, thanks all!
16:31 <rbasak> #endmeeting