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