15:02 <cyphermox> #startmeeting DMB meeting
15:02 <meetingology> Meeting started Mon Sep 26 15:02:08 2016 UTC.  The chair is cyphermox. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
15:02 <meetingology> 
15:02 <meetingology> Available commands: action commands idea info link nick
15:02 <cyphermox> #topic Review of previous action items
15:02 <cyphermox> sil2100 asked me to chair, since he was going to be on a uncertain connection
15:02 <BenC> Has it reall been two weeks since the last meeting? My internal clock is misrepresenting terribly.
15:03 * rbasak is also on an uncertain connection
15:03 <cyphermox> BenC: it has
15:03 <BenC> And on that note, I must appologize for not updating the agenda.
15:03 <cyphermox> no infinity here, but I'll poke him to do his PPU stuff for Gunnar.
15:03 <rbasak> That's done actually.
15:03 <cyphermox> oh
15:03 <rbasak> slangasek took care of it for us.
15:03 <cyphermox> good
15:03 <cyphermox> what about the PPU acces for Otto?
15:04 <rbasak> That I didn't have in my mind when I asked him, sorry.
15:04 <cyphermox> ok, I will then
15:04 <rbasak> If someone wants to prepare the edit-acl command for slangasek, I'm sure he'd be happy to oblige.
15:04 <cyphermox> my tasks were done
15:04 <cyphermox> yup
15:04 <cyphermox> sil2100's tasks were done (libdumbnet and zerofree for ubuntu-cloud)
15:05 <cyphermox> and finally mine (nacc to add to core-dev and annoucing results) are done too -- so looks like we just need to cover Otto's PPU now
15:05 <cyphermox> I see no applications on the agenda...
15:06 <cyphermox> BenC: was there anything that should be on today's agenda?
15:06 <BenC> We pushed “Nicholas Skaggs and (Juju Delegated Team) (September 12th)” to this meeting.
15:06 <cyphermox> balloons: are you around?
15:07 <balloons> o/
15:07 <balloons> Happy Monday to you all
15:08 <cyphermox> #topic Juju Delegated Team
15:08 <rbasak> o/
15:08 <rbasak> I wasn't expecting to be available today, but I happen to be free and with a connection available right now.
15:09 <cyphermox> ok!
15:09 <cyphermox> well, we have an email thread describing the request for a Juju PPU team.
15:10 <cyphermox> is everyone familiar with that thread or with last meeting's discussion so we can skip right to voting on the team creation? is there anything we need to discuss on that regard? (or was the voting done already?)
15:11 <BenC> I’m good
15:12 <bdmurray> I'm not caught up on the thread
15:13 <cyphermox> rbasak had concerns with the complexity of the packages, and whether they shouldn't just require core-dev
15:13 <cyphermox> the thing is, we should usually consider PPU uploader teams separate from who asked to have that access .. can we sufficiently well define the packageset?
15:14 <rbasak> I believe that all the packages currently requested have the property that they are only dependencies of Juju and nothing else.
15:14 <rbasak> So "Juju and supporting packages that aren't dependencies for anything other than Juju" or a more concise form of that maybe?
15:16 <BenC> Yeah, let’s get the package set out of the way. I think that’s fairly well defined.
15:16 <BenC> And uncontested, for the most part.
15:17 <rbasak> If we were to decide that Juju can only be uploaded to by core devs, then there would be no point in having a packageset.
15:18 <rbasak> I realise that it's a bit circular though. I don't mind which way round we do it.
15:18 <rbasak> As you say, I think everyone agrees what the packageset should be.
15:19 <cyphermox> well, I don't think it has to only be core developers. people can show interest in only juju and show that they can handle these special packages correctly without necessarily qualifying or willing to be core-dev
15:19 <micahg> cyphermox: that's a point of contention
15:20 <BenC> I agree. I think it’s actually more likely that some one would work on juju and not want or need core, than the other way around.
15:20 <cyphermox> micahg: could you elaborate?
15:20 <BenC> micahg: Is it contended because there’s an opinion that you need to be at the level of a core-dev to work on it correcly, or because you should be a core dev to do it?
15:20 <micahg> https://lists.ubuntu.com/archives/devel-permissions/2016-September/000979.html
15:22 <BenC> I agree, there needs to be a higher level of expertise for anyone working on juju, but I don’t agree that you should need core-dev permissions to do so.
15:22 <cyphermox> uploads are uploads, we're not here to check if someone uploading is doing a bugfix or not
15:23 <rbasak> What if we ask all DMB members here to express their opinion on my questions A-E in that email? Would that help? Are there any further distinctions or nuances in opinion that this would miss?
15:23 <cyphermox> AFAIK we've worked the same way for other packages for which uploads have consequences -- that's why we look at the packageset and who requests access separately
15:23 <micahg> I agree on that point, I'm still not sure about whether or not someone should be core-dev for juju, I'm leaning towards it's plumbing for package management, so people should have a decent understand of how things work
15:24 <BenC> A) Yes, B) No
15:25 <BenC> Given that, I move that we define juju as a package set and to allow PPU access to it on a case-by-case basis.
15:27 <cyphermox> seems to be like "bugfix-only uploads for the PPU" is unenforceable, and arguably something that goes beyond the scope of the DMB
15:28 <BenC> Yeah, and most of these points can easily bog us down to the point of hindering progress rather than enabling.
15:28 <BenC> Which I think is our main goal.
15:28 <cyphermox> perhaps we could vote on the packageset, then vote on rbasak's points and bring this up to the next TB meeting?
15:28 <cyphermox> BenC: err, what? :)
15:29 <BenC> We should be enabling progress and development rather than hindering it :)
15:29 <cyphermox> oh, ok :)
15:29 <BenC> Order of gramatical operations failure on my part.
15:30 <rbasak> I think that given it's within the scope of the DMB to deny an application for PPU, it's also within the scope of the DMB to permit a limited PPU only. Whether or not we choose to do it, or whether or not it's a good idea, is a separate matter.
15:30 <cyphermox> #vote for the creation of a juju packageset defined as "Juju and supporting packages that aren't dependencies for anything other than Juju"
15:30 <meetingology> Please vote on: for the creation of a juju packageset defined as "Juju and supporting packages that aren't dependencies for anything other than Juju"
15:30 <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)
15:31 <rbasak> +1
15:31 <meetingology> +1 received from rbasak
15:31 <BenC> +1
15:31 <meetingology> +1 received from BenC
15:31 <bdmurray> +1
15:31 <meetingology> +1 received from bdmurray
15:31 <cyphermox> +1
15:31 <meetingology> +1 received from cyphermox
15:31 <micahg> +0
15:31 <meetingology> +0 received from micahg
15:32 <cyphermox> #endvote
15:32 <meetingology> Voting ended on: for the creation of a juju packageset defined as "Juju and supporting packages that aren't dependencies for anything other than Juju"
15:32 <meetingology> Votes for:4 Votes against:0 Abstentions:1
15:32 <meetingology> Motion carried
15:32 <rbasak> I'm not sure we need to send this to the TB, unless we're hung or really unsure or something. We can still decide to our best ability and allow balloons (or anyone else) to take it to the TB if unhappy still though.
15:33 <cyphermox> rbasak: that's not what I meant though
15:33 <rbasak> No?
15:33 <cyphermox> I think we ought to proceed as usual to do the vote for the packageset, vote on the applicants, and then bring up this discussion on ubuntu-devel perhaps?
15:33 <cyphermox> and if need be, have a decision made by the TB
15:34 <cyphermox> even if juju is complicated, I don't think it qualifies as stuff that only core-devs should ever upload
15:34 <cyphermox> I think very few such packages exist
15:35 <cyphermox> even boot stuff typically has bad consequences if you do stuff wrong, but we can have very knowledgeable uploaders ready to do such uploads
15:36 <cyphermox> #topic Nicholas Skaggs for juju packageset upload rights
15:36 <rbasak> I have no objection to bring it up on ubuntu-devel if you would like to do that.
15:36 <cyphermox> balloons: could you tell us more about what changed since last meeting?
15:36 * cyphermox kicks Launchpad, would be nice to see upload history right about now
15:37 <balloons> cyphermox, you can at least still see http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*&sponsor_search=name&sponsoree=*Skaggs*&sponsoree_search=name
15:37 <balloons> but yea :-(
15:37 <balloons> Anyways, I sent along an email about juju packaging history as I knew it, and my invovlement with it
15:37 <micahg> yes, but boot loaders are very focused, yes, results can be disastrous, but there's specific knowledge involved, packaging plumbing would seemingly require knowledge of how other packages interact and can potentially interact with each other, which implies archive-wide understanding
15:38 <balloons> There's also an on-going debate about 32-bit uploads, and work on getting an RC into the archive
15:38 <cyphermox> micahg: juju doesn't affect the archive, only the system on which you run it
15:38 <balloons> cyphermox, did you have anything specific you want an update on?
15:39 <cyphermox> balloons: not necessarily, but I wasn't at the last meeting, so trying to catch up with approximate resources
15:39 <balloons> here's my mail btw https://lists.ubuntu.com/archives/devel-permissions/2016-September/000965.html
15:39 <BenC> balloons: I have a single question: How do you plan ro help resolve some of the packaging issues being raised?
15:40 <BenC> Speficially, without vague things like “I’m going to make juju great again” :)
15:40 <micahg> cyphermox: right, but isn't the idea to be a layer on top of the package manager to make it even easier to install groups of packages?
15:40 <balloons> BenC, :-). Are you speaking about issues like the 32-bit issue?
15:41 <cyphermox> micahg: following specific rules which aren't part of juju itself, and those recipes are reviewed differently, etc.
15:41 <cyphermox> micahg: it's not very different from chef/puppet, etc.
15:41 <BenC> Well, there seems to be a huge discussion on how best to move forward with juju packaging to satisfy some current problems. Things raised last DMB meeting.
15:41 <cyphermox> ie. you're always free to destroy your computer, or your datacenter, if you so choose.
15:41 <balloons> My goal in general has been to try and make juju a better upstream partner. I've sought to do that by addressing the various packaging issues raised before I started working on the package. This included things like breaking out dependencies and doing regular uploads
15:42 <BenC> As juju PPU #1, how would you lead that movement?
15:43 <BenC> balloons: Sorry to come across as pushy, but not past. What are your future plans?
15:43 <balloons> I push for open discussions on hard issues and seek resolution. It's not ok to just stop doing things once they get hard.
15:44 <balloons> My future plans are to beef up the autopkgtests a bit more, and make the juju ci packaging mirror what goes into the archive
15:44 <balloons> I want to reduce the release timing for pushing something into a ppa to into the devel archive to nil
15:46 <micahg> balloons: not to open up a can of worms, but is there a reason that juju isn't part of the CI train?
15:46 <cjwatson> wut
15:46 <cjwatson> most packages aren't
15:47 <micahg> even the canonical developed ones
15:47 <balloons> micahg, the CI train for phone images?
15:47 <balloons> if so, the answer is simply that it doesn't ship on those images
15:47 <micahg> for the archive
15:47 <cjwatson> right, bileto (formerly called the CI train) mainly focuses on the code used on the phone; it's certainly possible to use it for other things, but might well be an impedance mismatch in a lot of cases, and is in no way a requirement
15:47 <cyphermox> the CI train isn't meant just for phone images though
15:48 <rbasak> Juju does have autopkgtests, assuming they're still there. I wrote a couple.
15:48 <cjwatson> and in particular most server packages don't use bileto
15:48 <cyphermox> otoh, cjwatson is right, and we shouldn't use it as a crutch to make it easier to do uploads
15:48 <balloons> rbasak, absolutely, and they are still there. Specifically, I'm going to try and stamp out archive issues with LXD, cloud-init, or snaps breaking us (or vice versa)
15:48 <micahg> it was one potential solution to the "we want point releases quickly"
15:49 <balloons> as an aside, who does the manual qa on a silo if it's not going on the phone?
15:50 <cyphermox> you, or some other person designated for these uploads.
15:50 <sil2100> o/ Sorry for being late, on mobile but around
15:50 <balloons> micahg, my solution for that has been to integrate autopkgtesting into our CI, along with running things like lint, and checking for copyrights, etc
15:50 <sil2100> The QA process is only for vivid and phone stuff, so other series just get released as is
15:51 <balloons> cyphermox, ahh interesting. So I do an upload, get a silo, then I do the signoff?
15:51 <sil2100> Bileto, in this regard, can be used for any package anywhere - if, of course, it fits the project needs
15:51 <cyphermox> we're drifting away from the subject though, should we go on to vote?
15:52 <sil2100> Since as cjwatson mentioned, bileto might 'get in the way' if you dont have autopkgtest or follow some specific release process
15:52 <sil2100> Yeah, sorry about that
15:54 <cyphermox> #vote for Nicholas Skaggs to get uploads rights for the juju packageset
15:54 <meetingology> Please vote on: for Nicholas Skaggs to get uploads rights for the juju packageset
15: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)
15:54 <balloons> so rbasak, when I say "beef up autopkgtests", I mean adding tests to ensure uploads to lxd, cloud-init, snap-confine don't break our juju packaging or vice versa. We've struggled with catching LXD breakages before they hit the archive
15:55 <rbasak> balloons: that wasn't my question :-)
15:56 <rbasak> -1 for reasons I explained at https://lists.ubuntu.com/archives/devel-permissions/2016-September/000979.html
15:56 <meetingology> -1 for reasons I explained at https://lists.ubuntu.com/archives/devel-permissions/2016-September/000979.html received from rbasak
15:57 <cyphermox> +0, I see some uploads, but I can't look at a few, and I would prefer to see more uploads of other packages that will be on the package set.
15:57 <meetingology> +0, I see some uploads, but I can't look at a few, and I would prefer to see more uploads of other packages that will be on the package set. received from cyphermox
15:58 <BenC> +0
15:58 <meetingology> +0 received from BenC
15:58 <sil2100> +0
15:58 <meetingology> +0 received from sil2100
15:59 <micahg> -1  I agree with most of what rbasak said
15:59 <meetingology> -1  I agree with most of what rbasak said received from micahg
15:59 <BenC> I trust baloons capability, but I think the first person on juju PPU needs more of a leadership role than a technical one.
16:00 <cyphermox> #endvote
16:00 <meetingology> Voting ended on: for Nicholas Skaggs to get uploads rights for the juju packageset
16:00 <meetingology> Votes for:0 Votes against:2 Abstentions:3
16:00 <meetingology> Motion denied
16:01 <balloons> Thanks for your consideration all. On rbasak's comments, as I told him, I do hope to see some wider discussion as I think he brought up some interesting points around packages and ppu permissions
16:01 <sil2100> I think we all would prefer you to do a few more uploads through sponsoring for now, and certainly re-try in a bit
16:01 <BenC> Agreed on that.
16:02 <balloons> yea, my uploads for things like mongodb never showed up in the miner
16:02 <balloons> I can work to make sure my name gets attached to things more; it'll happen naturally anyway
16:02 <rbasak> It's OK if they don't show up on the sponsorship miner - just point to them in your (re-)application and explain your involvement.
16:02 <rbasak> (with an endorsement from the uploader also describing/confirming your involvement, etc)
16:03 <cyphermox> #topic Any other business
16:03 <bdmurray> Is there a bug in the sponsorship miner then?
16:04 <balloons> bdmurray, seems unlikely. More likely is that my sponser uploaded and it has there name (probably very few if any of these). And for the other things, it likely carries someone else who I colloborated with as the uploader
16:07 <cyphermox> so, no AOB
16:07 <sil2100> Not from me
16:08 <cyphermox> but I did forget to write down the ACTION for creating the packageset.. who wants to do it?
16:08 <sil2100> I could try
16:08 <sil2100> The juju packageset, right?
16:08 <cyphermox> yes
16:08 <rbasak> Is there any point doing it now?
16:09 <sil2100> I would get on it when Im back or tomorrow then if that's needed
16:09 <cyphermox> well, you don't have to DO it, just own the action so that we eventually have it done
16:09 <rbasak> I suppose it would make it easy to add someone to when it's ready.
16:09 <cyphermox> rbasak: not now, but let's not forget.
16:09 * cyphermox sil2100 to deal with the juju packageset creation
16:09 <cyphermox> #endmeeting