17:01 #startmeeting 17:01 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 17:01 Available commands: action commands idea info link nick 17:01 [topic] Apologies 17:01 none 17:01 [topic] Action review 17:01 defer 17:01 infinity: both? 17:02 Without looking, yes. It's been one of those months. 17:02 ack 17:02 * mdeslaur mdeslaur to look into flavour CVE tracking 17:02 I updated and fixed the tracking scripts 17:02 results are here: http://people.canonical.com/~ubuntu-security/cve/flavors.html 17:02 while there still may be improvements and adjustments, I think the action item is completed 17:03 nice! 17:03 mdeslaur: I assume the second link for each flavour includes main? 17:03 Or includes closed? 17:03 that's the intention, but some main packages are showing up in the first link 17:04 I need to fix that 17:04 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 mdeslaur: feature request: summary counts on the top-level page :) 17:05 infinity: ok, let me see if I can quickly fix the main issue and then we(I) can send out an email 17:05 slangasek: ack 17:06 [topic] budgie-remix/ubuntu budgie: package-set maintainer application -fossfreedom 17:07 fossfreedom: hi there 17:07 so...doesn't that a DMB topic? 17:07 Hi ! 17:07 hi fossfreedom! 17:07 hi HEXcube 17:07 for the packageset, yes, that's rightly a DMB topic 17:07 Hi 17:08 right 17:08 fossfreedom, HEXcube: for the packageset topic, can we redirect you to https://wiki.ubuntu.com/DeveloperMembershipBoard ? 17:08 ok thanks. will read etc. 17:08 [topic] budgie-remix/ubuntu official community flavour application - fossfreedom 17:08 creating the packageset itself should be non-controversial, provided the TB gives its +1 to the second topic 17:09 fossfreedom: so, can you give us the status on getting all your packages in the archive? 17:10 [LINK] https://lists.ubuntu.com/archives/technical-board/2016-October/002261.html 17:10 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 I was pleased to see a number of these packages go into the archive before 16.10 released 17:11 can I say thanks to jeremy bica and daniel holbach for helping here 17:12 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 let me give you the link... 17:13 https://bugs.launchpad.net/ubuntu/+bug/1594596 17:13 "arc-firefox-theme" - 17:14 thanks 17:14 you seem to be doing all the right things to get integrated as an official flavor 17:15 Are there preliminary seeds and metapackages? 17:15 there are some technical integration points that need to be followed through on ^^ to be truly official 17:15 the fact that searching wiki.ubuntu.com for 'official flavo[u]rs' returns no results seems like a bug 17:15 anyone else know if we have a wiki page somewhere documenting the requirements? 17:16 Not sure if we do, or if it just comes up as people try to integrate. :P 17:16 I thought we did 17:16 I thought we did also 17:17 I only know of this: https://wiki.ubuntu.com/RecognizedFlavors 17:17 was going to link to that one 17:17 aha! 17:17 that's the one I remembered 17:17 seems like it has what we're looking for 17:17 thanks, adding some redirects 17:18 Yeah. That's what their presentation referenced as well, I'd say. 17:18 It doesn't have gritty technical details like seeds/metas, though. 17:18 ah right, this was the chicken and egg thing where TB had to approve it first ;) 17:18 Just higher level commitment and staffing type things. 17:19 infinity: yeah, that's buried under "release team agrees to help do the work" 17:19 so 17:19 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 I feel a strong urge to bikeshed the process documented on that page 17:19 I'm shocked. 17:20 but in the meantime, I don't think it should block us from blessing budgie 17:20 others? 17:20 infinity: ;) 17:20 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 Does anyone have any thing else they would like to ask them before we vote? 17:21 But their presentation seems to address what the wiki's looking for. 17:21 The only nit would be the "upload rights" thing, which seems to be a bit of a question mark. 17:21 infinity: you can write that process and then try it with Edubuntu :) 17:21 Since creating a package set doesn't do much without someone to give rights to. 17:22 infinity: right - should we require the DMB review first? 17:22 we can make the approval conditional on it 17:22 Yeah, that. 17:23 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 (Maybe there is a history, I haven't been watching) 17:24 ok, so DMB review first? 17:24 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 I agree with infinity 17:25 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 ok, let's vote for a conditional approval 17:25 I don't want us to bounce them back and forth between committee meetings for months at a time 17:26 Feel free to copy/waste my above vomit as the vote question. :P 17:26 [VOTE] Budgie-remix becoming an official flavour, conditional on approval of uploaders by the DMB 17:26 Please vote on: Budgie-remix becoming an official flavour, conditional on approval of uploaders by the DMB 17:26 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 +1 17:26 +1 received from slangasek 17:26 +1 17:26 +1 received from mdeslaur 17:26 I'll try to make the appropriate DMB meeting to provide some continuity to the discussion. 17:27 +1 17:27 +1 received from infinity 17:27 +1 17:27 +1 received from stgraber 17:27 [ENDVOTE] 17:27 Voting ended on: Budgie-remix becoming an official flavour, conditional on approval of uploaders by the DMB 17:27 Votes for:4 Votes against:0 Abstentions:0 17:27 Motion carried 17:27 yay, congrats! 17:27 Err, s/budgie-remix/ubuntu-budgie/ 17:27 But yeah. 17:27 oh, woops :P 17:27 Or budgebuntu, or whatever. 17:28 all - many thanks on behalf of the team - Ubuntu Budgie! 17:28 I think they stated a preference for Ubuntu Budgie, though. :) 17:28 fossfreedom: welcome :) 17:28 Thank you! 17:28 (ubudgtu) 17:28 Yeah, Ubuntu Budgie! 17:28 Thank you very much ! 17:29 It'll always be Bubuntu in my heart 17:29 Thanx a lot! 😃 17:29 [topic] drop the powerpc port 17:29 infinity: you'll need to buy a new workstation 17:29 :P 17:29 oh man was that the holdup? 17:29 yep, our sole remaining user 17:29 we can take up a collection 17:30 Yeah, not true. :P 17:30 well, he still can put them into heating mode without security updates ... 17:30 hehe 17:30 While I do have some PPC kit here at my feet, I'm not the sole user. 17:30 I had someone asking me this morning if we were dropping the port due to Debian's announcement. 17:30 I said I didn't think we had plans to. 17:31 Then I read doko's agenda point. :P 17:31 well, it's been a discussion point before now 17:31 I don't expect this to be decided by the TB in this meeting 17:31 if you want a new toy, do x32 ;) 17:31 Ick. 17:31 but I do think we ought to help guide the discussion 17:32 So, long term, I think we should aim to drop *all* 32-bit ports. 17:32 For reasons too long to list. 17:32 I understand that the question will also be raised on the ubuntu-server list 17:32 But short term, PPC is the most obvious candidate to drop, if we feel we should drop something. 17:33 yes, and there've been discussions about winding down i386 also 17:33 so it's not as if we're picking on powerpc disproportionately :) 17:33 I feel like this depends on how many people step up to volunteer maintaining it 17:33 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 ie: we could just not care about those issues, and it wouldn't actually matter. 17:33 define "step up" ... 17:33 well, commit :P 17:34 Define "maintain" is the better question. 17:34 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 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 I do believe the burden will become greater if Debian isn't doing it anymore 17:35 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 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 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 slangasek: Yes, this is true. And sometimes it's PPC-specific. Rarely, but sometimes. 17:37 slangasek: If removals aren't done haphazardly in a way that bumps the uninstallability count, sure. 17:38 ok 17:38 I don't agree about the "sometimes". everybody has to look at migrations, ftbfs, etc ... 17:38 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 ok 17:38 look at mono for xenial, look at openjdk failures, continue that list 17:38 who is still using that? 17:39 taht port? 17:39 [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 we can revisit this once we have a list of powerpc binaries that have been removed 17:40 so when gcc and binutils stop building, can we remove these from the archive then? 17:41 if nobody fixed them, the choice will be easy 17:41 doko: Short of your making them not build, is that going to happen? 17:42 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 who else is doing this work? 17:42 fwiw there are 22 packages stalled in zesty-proposed at the moment due to powerpc-specific build failures 17:42 (plus a smattering of 32-bit build failures, and big-endian build failures) 17:42 ouch, that's a lot 17:43 mdeslaur: not compared to the total -proposed count of 775; but that's another story 17:43 A large chunk of those are all in the same package set. 17:43 sure, but it means _someone_ has to fix 22 packages currently, and that will only get worse 17:43 And dep-wait. 17:43 for openjdk-9, powerpc will be the only port still needing the zero vm. who will maintain that? 17:44 doko: openjdk-9 appears to be broken on armhf too. 17:44 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 sure, but that one has a hotspot port now. oracle open sourced it 17:46 I don't feel comfortable deciding today whether we should remove it or not without it being proposed somewhere and seeing objections 17:46 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 slangasek: I can't finish my work if I ignore powerpc issues which hinder migration and ftbfs 17:47 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 slangasek: please could you point out who is "powerpc community"? 17:49 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 (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 infinity: sure, in that case I think the real deadline is "when it stops being snapshot" 17:51 no, but then it makes death easier when going to the next compiler version 17:51 Except that the stable release process includes porters testing and sorting issues. 17:51 The daily snapshot process doesn't. 17:51 (Maybe it should, but I don't control gcc upstream) 17:52 powerpc isn't neith a primary nor secondary GCC release architecture 17:52 The port maintainers still test, submit results, and fix issues. 17:52 doko: so ignore ftbfs on powerpc, and ask an AA to unblock migrations 17:53 and when it bitrots to the point where it doesn't make sense anymore, we'll kill it 17:53 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 infinity: who is "port maintainers"? 17:53 I don't recall who the gcc powerpc port maintainer is right now. 17:53 mdeslaur: that still puts a burden on the broader team, which we don't currently measure 17:53 I assume someone IBMish. 17:54 no, not that much interested anymore 17:54 slangasek: to unblock migrations? 17:54 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 mdeslaur: yes 17:55 can we get an arch disabled from migration blockages? 17:55 mdeslaur: 1) someone has to notice the migration is blocked, 2) an AA has to remove binary packages, recursively 17:55 we can, but that's equivalent to saying the port doesn't matter 17:55 mdeslaur: Yes, but that does more harm than good. 17:55 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 infinity: well, depending on who's measuring the harm and the good. it certainly does save AA time ;) 17:56 slangasek: The way britney's implemented, it does far more harm than good. :P 17:56 (Even to !ppc) 17:56 infinity: if the powerpc community steps up and starts fixing packages, we can always revert 17:56 so please can we first define: who are powerpc users? who are powerpc porters (together with a track of work being done)? 17:57 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 slangasek: watch ftbfs, excuses on a daily basis, fix issues 17:59 doko: that's something completely different from gcc-snapshot 17:59 which was what I was asking about 17:59 "on a daily basis" is an unrealistic thing to ask anyone to do, even if it was their job. 17:59 slangasek: I don't see this as different. why single out one package? 17:59 I suspect xnox doesn't check excuses for s390x issues every day either. 18:00 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 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 ok, I don't think we're going to decide on this issue today 18:02 slangasek: so to which porters should issues be reported? 18:03 we are trying to keep a port without knowing why we are doing it 18:03 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 because we don't actually have subscription mechanisms for things like build failures on an arch 18:04 feeling ownership is not enough 18:04 of course it isn't 18:04 but I'm pointing out that there's a practical challenge to getting those who do feel ownership to shoulder the burden 18:05 well, we do need to see if anybody actually does feel ownership in the first place 18:05 I suspect not 18:05 infinity: do you? 18:06 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 I do. BenC does. Not sure who else "feels ownership" and has the skills to do anything about it. 18:07 when was BenC's last upload to the archive? 18:07 (There's a longer list of people who care about the port but probably can't fix hard issues, like flexiondotorg) 18:08 doko: Probably somewhere around the time Canonical refused to accept money from his company. :P 18:08 infinity: is there a point of contact for the powerpc community? 18:09 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 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 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 (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 (email escalation path, not IRC :) 18:10 that is 64bit only 18:10 doko: That's not true, even if you see it that way. 18:11 well, I'm asking there for help, and sometimes but not always get help 18:11 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 slangasek: The latter before the former, I think, but yes. 18:12 so for now, I only see one powerpc porter, and one powerpc user (although that might be one company) 18:12 slangasek: I'll round people up and see if there's a group to rally. 18:12 mdeslaur: ^^ action and gavel us out? :-) 18:13 Very large gavel please. 18:13 slangasek: timeline for that? 18:13 I think we ought to make sure the list is in place in two weeks' time (i.e. before next TB meeting) 18:13 [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 trivial to do it as a launchpad list 18:14 [topic] Mailing list archive 18:14 none 18:14 [topic] Community bugs 18:14 none 18:14 [topic] Next chair 18:14 I believe I'm in the hot seat 18:14 stgraber as backup 18:14 Looks like you then steffie, yes. 18:14 yes? 18:14 slangasek with stgraber as backup 18:14 sounds good 18:15 anybody have any other topics before I end this thing? 18:15 too late 18:15 #endmeeting