[16:58]  * slangasek waves
[16:59]  * foggalong waves back
[16:59]  * stgraber waves from Bucharest
[16:59]  * mdeslaur waves
[17:00] <infinity> o/
[17:01] <mdeslaur> ok, let's get started
[17:01] <mdeslaur> #startmeeting
[17:01] <meetingology> Meeting started Tue Nov  8 17:01:11 2016 UTC.  The chair is mdeslaur. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:01] <meetingology> Available commands: action commands idea info link nick
[17:01] <mdeslaur> [topic] Apologies
[17:01] <mdeslaur> none
[17:01] <mdeslaur> [topic] Action review
[17:01] <infinity> defer
[17:01] <mdeslaur> infinity: both?
[17:02] <infinity> Without looking, yes.  It's been one of those months.
[17:02] <mdeslaur> ack
[17:02] <mdeslaur> ACTION: mdeslaur to look into flavour CVE tracking
[17:02] <mdeslaur> I updated and fixed the tracking scripts
[17:02] <mdeslaur> results are here: http://people.canonical.com/~ubuntu-security/cve/flavors.html
[17:02] <mdeslaur> while there still may be improvements and adjustments, I think the action item is completed
[17:03] <slangasek> nice!
[17:03] <infinity> mdeslaur: I assume the second link for each flavour includes main?
[17:03] <infinity> Or includes closed?
[17:03] <mdeslaur> that's the intention, but some main packages are showing up in the first link
[17:04] <mdeslaur> I need to fix that
[17:04] <infinity> Well, it's probably a good enough state to move to a second step of pointing the flavour folks at it, so they can start shouldering some responsibility there.
[17:04] <slangasek> mdeslaur: feature request: summary counts on the top-level page :)
[17:05] <mdeslaur> infinity: ok, let me see if I can quickly fix the main issue and then we(I) can send out an email
[17:05] <mdeslaur> slangasek: ack
[17:06] <mdeslaur> [topic] budgie-remix/ubuntu budgie: package-set maintainer application -fossfreedom
[17:07] <slangasek> fossfreedom: hi there
[17:07] <mdeslaur> so...doesn't that a DMB topic?
[17:07] <fossfreedom> Hi !
[17:07] <mdeslaur> hi fossfreedom!
[17:07] <mdeslaur> hi HEXcube
[17:07] <slangasek> for the packageset, yes, that's rightly a DMB topic
[17:07] <HEXcube> Hi
[17:08] <mdeslaur> right
[17:08] <slangasek> fossfreedom, HEXcube: for the packageset topic, can we redirect you to https://wiki.ubuntu.com/DeveloperMembershipBoard ?
[17:08] <fossfreedom> ok thanks.  will read etc.
[17:08] <mdeslaur> [topic] budgie-remix/ubuntu official community flavour application - fossfreedom
[17:08] <slangasek> creating the packageset itself should be non-controversial, provided the TB gives its +1 to the second topic
[17:09] <mdeslaur> fossfreedom: so, can you give us the status on getting all your packages in the archive?
[17:10] <slangasek> [LINK] https://lists.ubuntu.com/archives/technical-board/2016-October/002261.html
[17:10] <fossfreedom> ok - all packages are now in zesty ... except one which requires a version number update.  I've resubmitted that and awaiting a review
[17:10] <slangasek> I was pleased to see a number of these packages go into the archive before 16.10 released
[17:11] <fossfreedom> can I say thanks to jeremy bica and daniel holbach for helping here
[17:12] <slangasek> fossfreedom: what is the remaining package, and where have you submitted it for review?  (not a blocker for us approving you, but I would like to help make sure it's on track)
[17:12] <fossfreedom> let me give you the link...
[17:13] <fossfreedom> https://bugs.launchpad.net/ubuntu/+bug/1594596
[17:13] <fossfreedom> "arc-firefox-theme" -
[17:14] <slangasek> thanks
[17:14] <slangasek> you seem to be doing all the right things to get integrated as an official flavor
[17:15] <infinity> Are there preliminary seeds and metapackages?
[17:15] <slangasek> there are some technical integration points that need to be followed through on ^^ to be truly official
[17:15] <slangasek> the fact that searching wiki.ubuntu.com for 'official flavo[u]rs' returns no results seems like a bug
[17:15] <slangasek> anyone else know if we have a wiki page somewhere documenting the requirements?
[17:16] <infinity> Not sure if we do, or if it just comes up as people try to integrate. :P
[17:16] <stgraber> I thought we did
[17:16] <slangasek> I thought we did also
[17:17] <mdeslaur> I only know of this: https://wiki.ubuntu.com/RecognizedFlavors
[17:17] <stgraber> was going to link to that one
[17:17] <slangasek> aha!
[17:17] <stgraber> that's the one I remembered
[17:17] <mdeslaur> seems like it has what we're looking for
[17:17] <slangasek> thanks, adding some redirects
[17:18] <infinity> Yeah.  That's what their presentation referenced as well, I'd say.
[17:18] <infinity> It doesn't have gritty technical details like seeds/metas, though.
[17:18] <slangasek> ah right, this was the chicken and egg thing where TB had to approve it first ;)
[17:18] <infinity> Just higher level commitment and staffing type things.
[17:19] <slangasek> infinity: yeah, that's buried under "release team agrees to help do the work"
[17:19] <slangasek> so
[17:19] <infinity> And, indeed, I don't expect them to have it all ready before approval, just to have looked at how it works and know what they're getting into.
[17:19] <slangasek> I feel a strong urge to bikeshed the process documented on that page
[17:19] <infinity> I'm shocked.
[17:20] <slangasek> but in the meantime, I don't think it should block us from blessing budgie
[17:20] <slangasek> others?
[17:20] <slangasek> infinity: ;)
[17:20] <infinity> I find it hard to have opinions about flavors until I've worked with them for 6-12 months.  Can we write a process document for firing them? ;)
[17:21] <mdeslaur> Does anyone have any thing else they would like to ask them before we vote?
[17:21] <infinity> But their presentation seems to address what the wiki's looking for.
[17:21] <infinity> The only nit would be the "upload rights" thing, which seems to be a bit of a question mark.
[17:21] <stgraber> infinity: you can write that process and then try it with Edubuntu :)
[17:21] <infinity> Since creating a package set doesn't do much without someone to give rights to.
[17:22] <slangasek> infinity: right - should we require the DMB review first?
[17:22] <mdeslaur> we can make the approval conditional on it
[17:22] <infinity> Yeah, that.
[17:23] <infinity> But unless there's a long history of sponsored uploads, etc, it's not exactly a slam-dunk when someone comes along and says "I want upload rights to a bunch of packages".
[17:23] <infinity> (Maybe there is a history, I haven't been watching)
[17:24] <mdeslaur> ok, so DMB review first?
[17:24] <infinity> Anyhow, I'd be fine with approving the flavour, conditional on approval of uploaders, and a solid time commitment from the lead that they'll be able to work with the cdimage/release folks to get integrated with seedy things and the like.
[17:25] <slangasek> I agree with infinity
[17:25] <infinity> I don't think punting them to the DMB without a decision here is helpful, it'll just end up in a loop.
[17:25] <mdeslaur> ok, let's vote for a conditional approval
[17:25] <slangasek> I don't want us to bounce them back and forth between committee meetings for months at a time
[17:26] <infinity> Feel free to copy/waste my above vomit as the vote question. :P
[17:26] <mdeslaur> [VOTE] Budgie-remix becoming an official flavour, conditional on approval of uploaders by the DMB
[17:26] <meetingology> Please vote on: Budgie-remix becoming an official flavour, conditional on approval of uploaders by the DMB
[17:26] <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)
[17:26] <slangasek> +1
[17:26] <meetingology> +1 received from slangasek
[17:26] <mdeslaur> +1
[17:26] <meetingology> +1 received from mdeslaur
[17:27] <infinity> I'll try to make the appropriate DMB meeting to provide some continuity to the discussion.
[17:27] <infinity> +1
[17:27] <meetingology> +1 received from infinity
[17:27] <stgraber> +1
[17:27] <meetingology> +1 received from stgraber
[17:27] <mdeslaur> [ENDVOTE]
[17:27] <meetingology> Voting ended on: Budgie-remix becoming an official flavour, conditional on approval of uploaders by the DMB
[17:27] <meetingology> Votes for:4 Votes against:0 Abstentions:0
[17:27] <meetingology> Motion carried
[17:27] <mdeslaur> yay, congrats!
[17:27] <infinity> Err, s/budgie-remix/ubuntu-budgie/
[17:27] <infinity> But yeah.
[17:27] <mdeslaur> oh, woops :P
[17:27] <infinity> Or budgebuntu, or whatever.
[17:28] <fossfreedom> all - many thanks on behalf of the team - Ubuntu Budgie!
[17:28] <infinity> I think they stated a preference for Ubuntu Budgie, though. :)
[17:28] <slangasek> fossfreedom: welcome :)
[17:28] <foggalong> Thank you!
[17:28] <slangasek> (ubudgtu)
[17:28] <HEXcube> Yeah, Ubuntu Budgie!
[17:28] <Udara> Thank you very much !
[17:29] <foggalong> It'll always be Bubuntu in my heart
[17:29] <HEXcube> Thanx a lot! 😃
[17:29] <mdeslaur> [topic] drop the powerpc port
[17:29] <mdeslaur> infinity: you'll need to buy a new workstation
[17:29] <infinity> :P
[17:29] <slangasek> oh man was that the holdup?
[17:29] <mdeslaur> yep, our sole remaining user
[17:29] <slangasek> we can take up a collection
[17:30] <infinity> Yeah, not true. :P
[17:30] <doko> well, he still can put them into heating mode without security updates ...
[17:30] <mdeslaur> hehe
[17:30] <infinity> While I do have some PPC kit here at my feet, I'm not the sole user.
[17:30] <infinity> I had someone asking me this morning if we were dropping the port due to Debian's announcement.
[17:30] <infinity> I said I didn't think we had plans to.
[17:31] <infinity> Then I read doko's agenda point. :P
[17:31] <slangasek> well, it's been a discussion point before now
[17:31] <slangasek> I don't expect this to be decided by the TB in this meeting
[17:31] <doko> if you want a new toy, do x32 ;)
[17:31] <infinity> Ick.
[17:31] <slangasek> but I do think we ought to help guide the discussion
[17:32] <infinity> So, long term, I think we should aim to drop *all* 32-bit ports.
[17:32] <infinity> For reasons too long to list.
[17:32] <slangasek> I understand that the question will also be raised on the ubuntu-server list
[17:32] <infinity> But short term, PPC is the most obvious candidate to drop, if we feel we should drop something.
[17:33] <slangasek> yes, and there've been discussions about winding down i386 also
[17:33] <slangasek> so it's not as if we're picking on powerpc disproportionately :)
[17:33] <mdeslaur> I feel like this depends on how many people step up to volunteer maintaining it
[17:33] <infinity> From a maintenance perspective, it's not a huge burden.  The problems are generally in leaf compilers (fpc!) that most users don't actually care about.
[17:33] <infinity> ie: we could just not care about those issues, and it wouldn't actually matter.
[17:33] <doko> define "step up" ...
[17:33] <mdeslaur> well, commit :P
[17:34] <infinity> Define "maintain" is the better question.
[17:34] <slangasek> I contest the claim that it's not a huge burden; there's a diffuse cost that is invisible to those who care about the arch, and which has never been measured
[17:34] <doko> I don't want to end up with people claiming, without doing. and that's the case for powerpc for a long time
[17:35] <mdeslaur> I do believe the burden will become greater if Debian isn't doing it anymore
[17:35] <slangasek> infinity: packages that FTBFS and stall proposed-migration can't just be ignored.  There are generally some arch specific for each !x86 arch at any given moment, and it costs attention to fix these
[17:35] <infinity> doko: The implication there is either that something's very broken, or that you've been fixing all the bugs.  Are either of those true?
[17:36] <slangasek> would we be ok with a policy by the AA team to unconditionally remove powerpc binaries whenever they're seen to hold up migrations?
[17:36] <infinity> slangasek: Yes, this is true.  And sometimes it's PPC-specific.  Rarely, but sometimes.
[17:37] <infinity> slangasek: If removals aren't done haphazardly in a way that bumps the uninstallability count, sure.
[17:38] <slangasek> ok
[17:38] <doko> I don't agree about the "sometimes". everybody has to look at migrations, ftbfs, etc ...
[17:38] <slangasek> mdeslaur: I can take an action with my AA hat to draft a proposed policy around this to ubuntu-release, as a first step
[17:38] <mdeslaur> ok
[17:38] <doko> look at mono for xenial, look at openjdk failures, continue that list
[17:38] <doko> who is still using that?
[17:39] <doko> taht port?
[17:39] <mdeslaur> [ACTION] slangasek to draft a proposed AA policy to ubuntu-release about removing powerpc binaries that hold up migrations
[17:39] <meetingology> ACTION: slangasek to draft a proposed AA policy to ubuntu-release about removing powerpc binaries that hold up migrations
[17:40] <mdeslaur> we can revisit this once we have a list of powerpc binaries that have been removed
[17:40] <doko> so when gcc and binutils stop building, can we remove these from the archive then?
[17:41] <mdeslaur> if nobody fixed them, the choice will be easy
[17:41] <infinity> doko: Short of your making them not build, is that going to happen?
[17:42] <doko> infinity: well, look at the gcc-snapshot ftbfs during the past ... it costs time to look at those, prepare test cases, forward them
[17:42] <doko> who else is doing this work?
[17:42] <slangasek> fwiw there are 22 packages stalled in zesty-proposed at the moment due to powerpc-specific build failures
[17:42] <slangasek> (plus a smattering of 32-bit build failures, and big-endian build failures)
[17:42] <mdeslaur> ouch, that's a lot
[17:43] <slangasek> mdeslaur: not compared to the total -proposed count of 775; but that's another story
[17:43] <infinity> A large chunk of those are all in the same package set.
[17:43] <mdeslaur> sure, but it means _someone_ has to fix 22 packages currently, and that will only get worse
[17:43] <infinity> And dep-wait.
[17:43] <doko> for openjdk-9, powerpc will be the only port still needing the zero vm. who will maintain that?
[17:44] <infinity> doko: openjdk-9 appears to be broken on armhf too.
[17:44] <slangasek> mdeslaur: well, it ebbs and flows.  I don't expect it to increase much in the near term, and indeed we do already remove binaries to unblock migration when it's clear no one's fixing them
[17:44] <doko> sure, but that one has a hotspot port now. oracle open sourced it
[17:46] <mdeslaur> I don't feel comfortable deciding today whether we should remove it or not without it being proposed somewhere and seeing objections
[17:46] <slangasek> doko: "who else is doing the work" - I'm not sure this question is the right way around.  powerpc is a community port; do you feel an obligation to do this work yourself, and if so, why?
[17:47] <doko> slangasek: I can't finish my work if I ignore powerpc issues which hinder migration and ftbfs
[17:47] <infinity> slangasek: So, looking at your analysis, I see a bunch of 32-bit, a few big-endian, a few ppc* (ie: both ports), and so far two powerpc-only (though with chain reactions, like kodi*)
[17:48]  * doko wonders why powerpc ports are doing that analysis only now ...
[17:49] <doko> slangasek: please could you point out who is "powerpc community"?
[17:49] <slangasek> doko: but you shouldn't have to carry water for the powerpc community; and the powerpc community shouldn't have to track status in 100 different places to know what might be blocking you.  shouldn't there be an escalation path for letting a community port's community know about blocking issues, with deadlines for dropping if they don't fix?
[17:50] <infinity> (I would argue that gcc-snapshot doesn't belong on a list of packages that need to be fixed urgently to avoid port death)
[17:51] <slangasek> infinity: sure, in that case I think the real deadline is "when it stops being snapshot"
[17:51] <doko> no, but then it makes death easier when going to the next compiler version
[17:51] <infinity> Except that the stable release process includes porters testing and sorting issues.
[17:51] <infinity> The daily snapshot process doesn't.
[17:51] <infinity> (Maybe it should, but I don't control gcc upstream)
[17:52] <doko> powerpc isn't neith a primary nor secondary GCC release architecture
[17:52] <infinity> The port maintainers still test, submit results, and fix issues.
[17:52] <mdeslaur> doko: so ignore ftbfs on powerpc, and ask an AA to unblock migrations
[17:53] <mdeslaur> and when it bitrots to the point where it doesn't make sense anymore, we'll kill it
[17:53] <slangasek> doko: but I agree with infinity's point here - failures in gcc-snapshot, or failures of packages to build /with/ gcc-snapshot, are not a measure of the health of a port
[17:53] <doko> infinity: who is "port maintainers"?
[17:53] <infinity> I don't recall who the gcc powerpc port maintainer is right now.
[17:53] <slangasek> mdeslaur: that still puts a burden on the broader team, which we don't currently measure
[17:53] <infinity> I assume someone IBMish.
[17:54] <doko> no, not that much interested anymore
[17:54] <mdeslaur> slangasek: to unblock migrations?
[17:54] <slangasek> doko: I do think that you should treat snapshot-related failures as something to signal to the powerpc community, but not take responsibility for fixing yourself (unless you want to)
[17:54] <slangasek> mdeslaur: yes
[17:55] <mdeslaur> can we get an arch disabled from migration blockages?
[17:55] <slangasek> mdeslaur: 1) someone has to notice the migration is blocked, 2) an AA has to remove binary packages, recursively
[17:55] <slangasek> we can, but that's equivalent to saying the port doesn't matter
[17:55] <infinity> mdeslaur: Yes, but that does more harm than good.
[17:55] <doko> slangasek: no, I'm not going to present every issue on a silver tablet to the powerpc porters, and the powerpc porters aren't doing that themself
[17:55] <slangasek> infinity: well, depending on who's measuring the harm and the good. it certainly does save AA time ;)
[17:56] <infinity> slangasek: The way britney's implemented, it does far more harm than good. :P
[17:56] <infinity> (Even to !ppc)
[17:56] <mdeslaur> infinity: if the powerpc community steps up and starts fixing packages, we can always revert
[17:56] <doko> so please can we first define: who are powerpc users?  who are powerpc porters (together with a track of work being done)?
[17:57] <slangasek> doko: ok, if pointing out snapshot problems to the powerpc porters is itself burdensome, then what is the way that they can subscribe to be notified of the failures?
[17:58] <doko> slangasek: watch ftbfs, excuses on a daily basis, fix issues
[17:59] <slangasek> doko: that's something completely different from gcc-snapshot
[17:59] <slangasek> which was what I was asking about
[17:59] <infinity> "on a daily basis" is an unrealistic thing to ask anyone to do, even if it was their job.
[17:59] <doko> slangasek: I don't see this as different. why single out one package?
[17:59] <infinity> I suspect xnox doesn't check excuses for s390x issues every day either.
[18:00] <slangasek> doko: I thought you were talking about test rebuilds using gcc-snapshot, not just build failures /of/ gcc-snapshot.  The latter doesn't seem like it's anything that should be blocking you, gcc-snapshot isn't exactly release-critical for Ubuntu
[18:01] <doko> then do it twice a week, weekly is not enough. because then other developers will invest time to fix issues. and these are not powerpc porters
[18:02] <mdeslaur> ok, I don't think we're going to decide on this issue today
[18:02] <doko> slangasek: so to which porters should issues be reported?
[18:03] <doko> we are trying to keep a port without knowing why we are doing it
[18:03] <slangasek> I agree that there's an issue here, that a community port imposes a burden on the rest of the developer community that is ill-defined and not measured.  It's also difficult to fix it so that the burden does lie with those who feel ownership of the port
[18:03] <slangasek> because we don't actually have subscription mechanisms for things like build failures on an arch
[18:04] <doko> feeling ownership is not enough
[18:04] <slangasek> of course it isn't
[18:04] <slangasek> but I'm pointing out that there's a practical challenge to getting those who do feel ownership to shoulder the burden
[18:05] <mdeslaur> well, we do need to see if anybody actually does feel ownership in the first place
[18:05] <mdeslaur> I suspect not
[18:05] <slangasek> infinity: do you?
[18:06] <slangasek> AIUI there's difference of opinion on how much it's costing us to keep it, but general agreement that we should move towards deprecating 32-bit archs
[18:07] <infinity> I do.  BenC does.  Not sure who else "feels ownership" and has the skills to do anything about it.
[18:07] <doko> when was BenC's last upload to the archive?
[18:07] <infinity> (There's a longer list of people who care about the port but probably can't fix hard issues, like flexiondotorg)
[18:08] <infinity> doko: Probably somewhere around the time Canonical refused to accept money from his company. :P
[18:08] <slangasek> infinity: is there a point of contact for the powerpc community?
[18:09] <slangasek> up to now I've used ubuntu-server as a proxy on the grounds that ubuntu-server was the principal flavor being produced
[18:09] <infinity> slangasek: Not really.  The two flavours that produce PPC images have users, and Ubuntu server does, but there's no ubuntu-ppc community where people hang out.
[18:10] <slangasek> infinity: ok, I posit that if you feel ownership of the port and don't want us to drop it, that's something that needs fixed - there needs to be a clear escalation path to powerpc porters
[18:10] <infinity> (Well, there's #ubuntu-powerpc, but that's pretty much Canonical and IBM and it's toolchain back-and-fort for both ppc* ports, not wider "community")
[18:10] <slangasek> (email escalation path, not IRC :)
[18:10] <doko> that is 64bit only
[18:10] <infinity> doko: That's not true, even if you see it that way.
[18:11] <doko> well, I'm asking there for help, and sometimes but not always get help
[18:11] <slangasek> infinity: do you want to take the action to stand up an ubuntu-powerpc mailing list and notify relevant folks, so that we can see how this would work out in practice?
[18:12] <infinity> slangasek: The latter before the former, I think, but yes.
[18:12] <doko> so for now, I only see one powerpc porter, and one powerpc user (although that might be one company)
[18:12] <infinity> slangasek: I'll round people up and see if there's a group to rally.
[18:12] <slangasek> mdeslaur: ^^ action and gavel us out? :-)
[18:13] <infinity> Very large gavel please.
[18:13] <doko> slangasek: timeline for that?
[18:13] <slangasek> I think we ought to make sure the list is in place in two weeks' time (i.e. before next TB meeting)
[18:13] <mdeslaur> [ACTION] Infinity to gather up powerpc community before next TB meeting
[18:13] <meetingology> ACTION: Infinity to gather up powerpc community before next TB meeting
[18:13] <slangasek> trivial to do it as a launchpad list
[18:14] <mdeslaur> [topic] Mailing list archive
[18:14] <mdeslaur> none
[18:14] <mdeslaur> [topic] Community bugs
[18:14] <mdeslaur> none
[18:14] <mdeslaur> [topic] Next chair
[18:14] <slangasek> I believe I'm in the hot seat
[18:14] <slangasek> stgraber as backup
[18:14] <infinity> Looks like you then steffie, yes.
[18:14] <slangasek> yes?
[18:14] <mdeslaur> slangasek with stgraber as backup
[18:14] <stgraber> sounds good
[18:15] <mdeslaur> anybody have any other topics before I end this thing?
[18:15] <mdeslaur> too late
[18:15] <mdeslaur> #endmeeting
[18:15] <meetingology> Meeting ended Tue Nov  8 18:15:19 2016 UTC.
[18:15] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.2016-11-08-17.01.moin.txt
[18:15] <slangasek> hahaha
[18:15] <mdeslaur> go forth and watch disaster on tv
[18:15] <infinity> Every meeting should end with "too late".
[18:15] <mdeslaur> hehe
[18:15] <infinity> And yes, I was mentioning earlier that this is the first time my TV will be used to watch broadcast TV.
[18:16] <mdeslaur> I know, right? live tv, how retro.
[18:16] <infinity> I've never watched the collapse of a nation live before.
[18:19] <mdeslaur> thanks everyone