18:58:25 #startmeeting 18:58:25 Meeting started Sun Sep 14 18:58:25 2014 UTC. The chair is jmw. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:58:25 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:58:29 #lurk 18:58:39 #meetingtopic Architecture Qualification 18:58:47 #meetingname arch-qual 18:59:22 by way of explanation, I offered to chair in place of adsb as he isn't very keen on such things 18:59:31 release team: if you're present, please say hi 18:59:34 hi 18:59:35 hi 18:59:37 hi 18:59:49 hi 18:59:59 DSA: Mithrandir, are you happy to speak for dsa? 19:00:13 go Mithrandir, go! 19:00:17 I am 19:00:23 ah weasel, you can too :) 19:00:31 I do think we have a bunch of people to correct me if I turn out to be too silly 19:00:49 porters: if you're present and available for questions, please say so and which port 19:01:24 hi, I am there for mips*, s390x, and ppc64el (if it applies to this meeting) 19:01:43 * zumbi is around (arm*) 19:01:49 we might need to re-ask that at inidividual ports if necessary 19:01:54 yes, I will do 19:02:14 I assume that's it 19:02:34 other than that, feel free to be in the channel and follow along, but please refrain from chipping in 19:02:35 which order do we go? 19:02:39 ok, let's start with the easy ones 19:02:45 #topic amd64/i386 19:02:55 no concerns from DSA. 19:02:58 are there any serious objections to keeping these ports in? 19:03:07 no 19:03:09 nah 19:03:15 hi 19:03:26 only a joke objection to the 32bit one. so no. 19:03:30 good 19:03:35 is the security team represented? 19:03:38 #agree amd64/i386 stay 19:03:53 btw, I think pkern, aurel32 and I also are here for buildd if necessary. 19:03:58 carnil: around? 19:03:58 excellent 19:04:07 next 19:04:12 i guess Q_ also for buildd 19:04:14 I think sparc is also easy btw 19:04:14 #topic hurd-i386 19:04:24 no concerns from DSA. 19:04:33 jcristau: sort of only, I was going to dissaper soon for today 19:04:55 No DSA'ed buildds afaik? 19:05:00 hurd-i386 is already marked 'no'; are there any really good reasons to change that? 19:05:00 as in, if we release hurd-i386, we can support it. That might be a not-insignificant if, though. 19:05:02 well, that could be fixed easily 19:05:14 jmw: moment ... 19:05:17 aba: And might raise DSA concerns. :P 19:05:22 carnil: ok, too bad. thanks. 19:05:41 https://release.debian.org/jessie/arch_qualify.html is the arch page I'm working from, by the way 19:05:41 jmw: we had a hard time the last two times to find any reason to keep it out from release, apart from "everyone knows it's too broken" 19:06:01 that's not convincing for me, so I think we should either have a good reason to keep it out, and add it. 19:06:07 of course, RMs might just ignore me :) 19:06:20 s,and,or 19:06:32 adsb? 19:06:51 I must admit I haven't looked at the status there for a while 19:06:56 we discussed about "keeps up", but that was mostly an wanna-build stats error 19:06:59 I guess that'd require a list of hurd issues that'd suddenly be RC and all. Seems rather late. 19:07:00 I note there is less than 80% build coverage for hurd 19:07:22 jmw: that's from the way stats are done 19:07:27 aba: ok 19:07:39 if packages are db-uninst, they are not in the "not covered"-stats, but things depending on such packages are 19:07:59 "depending" = build-depending 19:08:22 carnil: there is an concern for buildd-fast-sec on the arch page. do you have any thoughts there? 19:08:36 jmw: that's because theris currently not security buildd 19:08:40 none at all? ok 19:08:49 actually hurd could easily have a fast one, as soon as it has DSAed buildds 19:08:55 jmw: security buildds are always DSAed 19:09:03 (because of access to embargoed queue) 19:09:08 yes 19:09:28 pkern: we could e.g. decide to require such a list of things while adding it to testing (and the issues are not RC), and decide in $time to either drop them again, or make the issues RC. 19:09:28 i think the coverage is an issue... 19:09:30 "easily" if hurd itself is "fast". (Just sayin'. My experience with the porterboxes was bad.) 19:09:45 pkern: last I looked at build times it wasn't that bad. 19:09:52 Okay. 19:09:55 pkern: I suspect any DSA machines are a tad faster than the current porterboxes. 19:10:03 I guess in the end it needs to run in Xen to be fast or something. 19:10:22 https://buildd.debian.org/status/logs.php?pkg=meanwhile that's a small package 19:10:27 but hurd isn't so bad here 19:10:40 I also see only a handful of popcon returns for hurd, which I know is also not a foolproof method; our criteria is for >50 users 19:10:53 So hurd is no longer the reason for many bugs still appearing on bugs.d.o because versions were out of date? ;) 19:10:55 (depending on measurement, popcon says about 20) 19:11:11 jmw: (ooi) users or installations? 19:11:30 Mithrandir: inst. vote is ~10 19:11:35 Mithrandir: users, if we want to keep s390x 19:11:37 pkern: it got a bit better. 19:11:49 oh sorry, for the criteria? 50 users 19:11:59 (and it was always users, not installations, at least in the vancouver mail explecitly explained) 19:12:38 tbh, I'd have hoped a bit more active things from hurd porters in old versions cleanup and coverage, but I need to admit that things are better than I always thought. 19:12:49 ok, thanks. 19:13:34 what are the RM concerns listed? 19:14:01 given our experience so far with !linux ports, I'm not convinced it's going to go well. having one as "tech-preview" for several releases is bad enough 19:14:35 ok, we need to come to a decision. hurd is currently not in testing; personally I have concerns over archive coverage and user count. 19:14:46 so we should write the reaosns down 19:15:00 howeer, I think it would also be fair to add that things are better but not good enough then 19:15:09 aba: I think that's a fair assessment 19:15:19 we also still have 10 ports to go through 19:15:36 so we have archive coverage, user count, and the not optimal experience with !linux-ports 19:15:56 (and also that we miss a list of potential RC issues, and perhaps a bit more activity from the porters - but last please in a nice way) 19:16:03 is that all, or something else? 19:16:09 There was a removal request some time ago that hurd had (some) uploads done with disabled test suite. 19:16:36 I want to move on. are there any serious objections to gently saying 'no' to hurd? 19:16:45 jcristau, adsb: ^ is that ok all? 19:16:53 yes, please move one 19:16:56 on 19:17:02 ansgar: that shouldn't happen. We perhaps should communicate that explicitly to the porters then (except if they already notied themselves) 19:17:09 jmw: sure, move on 19:17:17 #info the hurd situation is improved, but not enough 19:17:26 #agree hurd-i386 will not be a release architecture 19:17:33 #topic sparc 19:17:36 dead. 19:17:37 rip. 19:17:39 dead 19:17:42 bye, bye 19:17:48 there are serious concerns still outstanding; I am marking this not releasable 19:17:56 #agree sparc will not be a release architecture 19:18:00 (that seems to be easier then the one before) 19:18:14 #topic armel/armhf 19:18:22 DSA has concerns. 19:18:28 Mithrandir: I believe you have concerns here 19:18:33 Multiple, in fact. 19:18:49 low geographical redundancy, if we lose a DC, the rest is unable to keep up 19:19:06 actually, let me just cut and paste: 19:19:08 - Low geographical redunancy. If we lose a DC, the rest can't keep up. 19:19:10 - Poor remote manageability: Daisy-chaining of serial consoles and lack of remote power. Needs manual intervention to boot after power failure. 19:19:12 - some currently running non-debian.org kernels. ick. 19:19:14 OK, assuming those concerns are addressed in full well before the release. 19:19:15 Mithrandir: we could still keep up with security if we lose a DC? 19:19:19 #info DSA have multiple concerns 19:19:19 aba: yes. 19:19:23 aba: #749134 19:19:33 (I believe so) 19:19:36 Mithrandir: only if ancina isn't decommissioned 19:19:46 ancina will go. 19:19:47 I think we need to make sure that at minimum 19:19:50 and even then i'm not sure 19:19:55 then I have a concern, sorry. 19:20:12 jcristau: as in, keep up with security only if ancina isn't decommissioned? 19:20:25 Mithrandir: ancina is the only machine remote from the others, yes? 19:20:29 can we move one box elsewhere? because we should have geographic available security updates for anything in (old)stable. 19:20:30 ancina must be decomissied 19:20:38 decomissioned* 19:20:47 ansgar: thanks 19:20:48 we have armhf stuff at York 19:20:58 Mithrandir: ok, that could run armel chroots? 19:21:04 yes 19:21:08 ancina does not have upstream kernel support 19:21:09 so we could add security buildds there (in worst case) 19:21:10 #info ancina is the only machine remote from the others, and due to be decommissioned 19:21:24 jmw: only remote armel 19:21:31 #undo 19:21:33 so for armhf it is already ok, and for armel we could add new chroots in york 19:21:36 +? 19:21:37 #info ancina is the only armel machine remote from the others, and due to be decommissioned 19:21:47 but we want to move to doing armel in a chroot anyway and armhf in the host system 19:21:50 then we should create an armel sec buildd in york if possible? 19:22:07 so this is something we could take care with our current hw. 19:22:24 we still have the issue of "if one DC fails, unstable can't keep up" 19:22:27 if there is a machine in york that can do armel/armhf, security is not really a concern 19:22:32 (which however IM'HO i sless relevant) 19:22:38 (we have *two* MX53 hosts at ynic. that's the total of non-arm-hosted armhf hw) 19:22:46 it's 15 minutes to do so, we are not going to discuss that for hours 19:22:47 aurel32: sure, but IMHO we should setup the chroot before we need it :) 19:22:58 #info there are two armhf machines remote from the others, both at ynic 19:22:58 for security I think we can tick it ok 19:23:07 how for unstable? 19:23:15 hahaha. 19:23:32 well, this question actually goes to the RMs, because they have to live with the fallout :) 19:23:48 unstable cannot keep up with only york machines 19:23:59 sure, but I also think it's not really that big a deal 19:24:01 AIUI, unstable suffered when york flooded. 19:24:13 aba: that's not your call, though. You don't have to live with suffering machines. 19:24:16 because it only affcts unstable. 19:24:20 Mithrandir: note hardware has changed 19:24:35 (now it is faster, but only at ARM) 19:24:51 zumbi: right, so it'd probably be ok with flooded york, but not flooded arm. 19:25:16 is ARM considered a risky location, or could we live with it? 19:25:18 Has Arm itself been less reliable than the others? (connectivity, power, etc.) 19:25:22 right, sending some of the ARM machines somewhere else should fix the issue 19:25:25 <_rene_> aba: which then indirecly affects testing as stuff with bugfixes doesn't get built and block and... and that's more important than "just" unstable 19:25:51 _rene_: we could always ignore one arch at testin migration if necessary. 19:25:51 zumbi: no, it doesn't fix it, due to their poor remote management properties. 19:25:57 jmw: at worst case, ARM machines are quite common to setup buildd anywhere 19:26:03 we can't have random DC people go in and poke bare devboards. 19:26:38 so, conclusion? 19:26:42 #info if ARM failed, the hardware there could be relocated 19:26:44 jmw: it's a bit painful for various admin-y reasons, but in terms of power etc, it's not terrible. They do a fair bit of maintenance leading to outages. 19:26:51 jmw: Could it be? 19:26:54 is this bad enough for DSA that we should remove it from testing? 19:27:08 jmw: that's not what i hear.. 19:27:19 #undo 19:27:23 jmw: not if the DC burns down. 19:27:28 ok, zumbi was less concrete that I read 19:27:34 which, as some people might remember, has actually happened. 19:27:35 Mithrandir: true. 19:27:55 ok, is this a blocker for DSA? 19:28:20 yes 19:28:35 it was a half-blocker for wheezy, nothing got better, things were painful. 19:28:40 we would like the pain to stop. 19:29:01 is that the redundancy or the current dc? 19:29:03 or both? 19:29:03 is there any scope to improve the situation between now and release? i.e. more hardware 19:29:25 (carefully placed, geographically...) 19:29:38 I certainly believe an improvement is possible. It's not like ARM lacks for engineering resources and we have hosting available for suitable hardware. 19:29:39 jmw: I believe so, porters will do as much as possible to fix it up 19:29:55 so I don't think the first move is to remove armel and armhf from testing.. 19:29:58 can we give them a warning and a deadline? 19:29:58 #info DSA did not see an improvement in the situation during the last cycle 19:30:17 ivodd: sounds good to me 19:30:22 ok, I'd like somebody to liaise with ARM about additional hardware, please 19:30:24 yeah 19:30:27 meanwhile: 19:30:43 #agree armel/armhf hardware situation is not a blocker at this stage, but the situation needs to improve before release 19:30:47 additional hw, or remote mgmt? 19:30:52 jcristau: either, really 19:30:56 we also had RM concerns btw, are they gone? 19:30:56 jcristau: both. 19:31:02 oh, sorry 19:31:03 right. 19:31:04 RM concerns? 19:31:11 https://release.debian.org/jessie/arch_qualify.html says so 19:31:17 jmw: DSA can talk to them about that. I don't know what form you want to communicate the result of this meeting, but they should probably know before it hits d-d-a or similar. 19:31:24 I think the concern was from before the hardware upgrades 19:31:25 no additional hardware, but geolocation redundancy 19:31:30 IIRC they were only a followup on DSA concerns, so probably we have done them now as well 19:31:49 but we should mark them as "done" somewhere 19:31:51 the RM concerns were around up-to-dateness. which is related to hardware, yeah 19:31:58 that was before they changed the buildd hw 19:31:59 ok, so RM concerns done? 19:32:01 zumbi: we should be able to keep up with one lost DC. If that just means shifting hw around + fixing it so it auto-boots and is nice to work with, great. 19:32:02 good. 19:32:10 #action DSA liaise with ARM about hardware and remote management, best-effort 19:32:34 (should I update the arch-table, or does someone else want to?) 19:32:44 Mithrandir: an off-the-record chat with Sledge might be a worthwhile starting point, he's a useful ally 19:32:51 ok, I'm going to move on 19:32:59 as DSA considers this a blocker, we should make it clear that they can be dropped later on if the issues aren't fixed 19:33:07 Mithrandir: right, there is enough machines at ARM do send some out and still keep up (also those are faster) 19:33:10 jmw: absolutely. 19:33:10 #topic kfreebsd-amd64/kfreebsd-i386 19:33:27 we seem to have vague RM concerns for this one 19:33:41 not so vague 19:33:47 jcristau: go 19:33:48 there's about 1 active porter 19:33:52 which is not enough 19:33:57 no DSA concerns for kfreebsd. 19:33:58 it concerns me that the change causing #756464 was in testing for three months before anyone found it, and still isn't fixed 19:34:07 also that. 19:34:18 well, s/found/reported/, but 19:34:19 #info only one porter appears to be active 19:34:41 #info RC bugs do not appear to be found quickly nor fixed in a suitable timeframe 19:34:44 #750836 isn't great either, although I got the impression people were less concerned about that 19:35:13 I started to updae the web page 19:35:27 I also see few (although >50) popcon returns for inst of the kernel v9, and they want to move to v10 relatively late in this cycle 19:35:54 I really don't see it as a promising architecture at the moment, considering it must be maintained for the next 3 years 19:36:07 it's been downgraded because it was worked around elsewhere, but the workaround in libpcap means disabling functionality that worked in wheezy. and I think the patch should be fairly trivial 19:36:19 for stable, do we have the concern thatit breaks in our hands while stable? 19:36:30 or that it doesn't survive the next cycle start? 19:36:48 #752194 looks fairly nasty... 19:36:53 well right now anyone upgrading from wheezy will have their machine break 19:37:13 yeah, that's the one I mentioned earlier (merged?) 19:37:16 praps 19:37:41 it doesn't appear to have a response, either, since june 19:37:44 KiBi also seemed concerned wrt installer breakage. (OTOH for full disclosure s390x is probably in a similar boat with very light testing.) 19:37:55 yes, he did 19:37:59 in that case, perhaps we should also issue an warning, and say if they don't manage it in time we might need to remove them? 19:38:08 are we generally of the opinion that this isn't release suitable? 19:38:16 #info there appear to be significant unresolved upgrade problems 19:38:29 as-is, I'm not convinced it's suitable 19:38:31 jmw: i am 19:38:36 aba: we're weeks from freeze. I think it's too late for warnings 19:38:46 jmw: we just did one for arm*. 19:38:54 or do we believe thisone here is unsolvable? 19:39:23 (if it's unsolvable in that time, a warning doesn't make sense of course) 19:39:30 <20140818234006.GM1999@mraw.org> looks like a warning to me 19:39:46 I don't see arm* as being a release problem, but a resources problem. this is a package quality problem 19:39:48 actually the kernel issue could probably be fixed with a transition package 19:40:07 I'm going to move to remove kfreebsd* from the release list, today. objections? 19:40:13 the problem with a warning for "you're not enough people doing enough" is the usual response is "we'll try harder", which doesn't work. The arm stuff is a one time change, not ongoing. 19:40:14 yes 19:40:18 aba? 19:40:20 let me read the mai lplease 19:41:05 Mithrandir: sure, it only works if *additional* people come up 19:41:32 I personally think a final warning would be better, but if I'm the only one just go ahead 19:41:50 which still could lead to removing from next release of course 19:42:11 I'm not convinced there's going to be any actual progress, as Mithrandir says 19:42:37 next? 19:42:40 as I said, if I'm the only one with that opinion, it#s ok to go ahead 19:42:43 #756464 should have been trivial to spot 19:42:55 #agree kfreebsd-amd64/kfreebsd-i386 will not be release architectures 19:43:07 I really hope these things are working.. anyway. 19:43:22 #topic mips/mipsel 19:43:24 if anyone works hard enough to convince us quickly enough, most things are possible... 19:43:36 I'm lumping these together, but they could be treated separately if anyone wishes it 19:43:45 they probably should be 19:43:48 Mithrandir: dsa has concerns listed for this 19:43:58 are they still present? 19:44:08 we do, I was late to the meeting, so maybe weasel could expand? 19:44:16 weasel: ^ 19:44:17 sure. 19:44:26 (thanks) 19:44:30 for mips, we are unhappy with the HW we currently have. 19:44:38 but new HW is in the pipeline. 19:45:00 we're commissioning a new DC (AQL) in the UK that will host HW provided by imgtec. 19:45:09 and that DC can then also host additional mipsel gear. 19:45:15 (for kbsd I added "too many unfixed RC bugs" as RM concerns) 19:45:43 #info DSA has concerns, but they should be alleviated soon with a new datacentre and hardware 19:45:46 so, while the current situation is probably not ok, we have faith it will improve significantly within the year. 19:45:50 <_rene_> and mips? 19:46:04 the new hardware is for mips 19:46:04 <_rene_> at least my feeling is that mips has a harder time to keep up than mipsel... 19:46:21 right now, yes, but the new DC is hopefully going to resolve that 19:46:23 _rene_: AQL is (at first) for mips. it can *also* take mipsel gear. 19:46:25 yes mips is not really able to follow unstable, only on the medium term 19:46:35 we have a bitof new mipsel hw already, but mips not yet 19:46:43 <_rene_> ah, ok, I just saw the "mipsel gear" 19:46:45 <_rene_> nevermind :) 19:46:46 _rene_: that's correct 19:46:55 that's it from DSA. 19:46:56 (mips (much) slower than mipsel) 19:47:01 the mips hardware is already there, but we are missing the infrastructure in the datacenter afaik 19:47:30 "have" was "in use as buildds" above 19:47:35 ok, that sounds like it's going to be taken care of just fine. we also have RM concerns but they appear to be the same 19:47:40 from #d-a earlier, that sounded about to get fixed though? 19:47:40 are there any other points to be made? 19:47:59 I'd put the RMs concerns as "see DSA" then on the web page 19:48:07 aba, please do that 19:48:27 we also should set a deadline (as we did with arm) 19:48:29 they'll at least have the same resolution (or won't) 19:48:57 weasel: how is the mips porterbox? will that be resolved with this new hardware too? 19:49:15 jmw: yes 19:49:23 jmw: I expect us to throw out all the movidis machines at ubc, once we have a sufficient number of new mips hosts we like. 19:49:30 ok 19:49:49 so my feeling is that mips/mipsel are both ok, assuming this new hardware goes to plan 19:49:50 (that might not happen within a month or two, but it should happen relatively soon) 19:49:59 that's our impression, yes. 19:50:06 we can presumably maintain the status quo for now without any deal-breakers 19:50:32 #agree mips/mipsel will be release architectures 19:50:40 #topic powerpc 19:50:57 I don't have a lot of information about this one 19:50:59 no DSA concerns (yet) 19:51:08 RMs? 19:51:25 not that I know of 19:51:33 it's, like i386, an arch that's likely to be gone in not too long, but it's not problematic for us at this point. 19:51:39 that works for me 19:51:45 #agree powerpc will be a release architecture 19:51:50 (tbh, I think we'll slowly run out of 32bit-releases soon. but not this time) 19:51:54 #topic s390x 19:51:54 there's a "partial upstream support" note, but no expansion. but yeah, I suspect it'll hop along happily this time 19:52:09 I also don't have much info for s390x, other than it replaced s390 and appears to be doing just fine 19:52:43 DSA: minor concern: rely on sponsors for HW and not being worked on. 19:52:55 Mithrandir: that's unchanged? 19:52:57 as a porter, my main concern is that we are dropping big-endian architectures slowly 19:52:58 yes 19:53:03 aba: ^ 19:53:04 Mithrandir: What's not being worked on? 19:53:30 Mithrandir: does it get worse (like on arm*), or is it just the same? 19:53:35 pkern: getting rid of the reliance of a single vendor sponsoring all our gear. 19:53:38 I'm a bit concerned about s390x's state right now, but I don't have specifics. We recently had severe ABI breakage in unstable which might not yet be rectified completely. 19:53:43 Mithrandir: Like ARM? 19:53:45 aurel32: yes, I also have that concern. 19:53:59 pkern: ARM gear is easy to buy. 19:54:03 s390x not so much 19:54:04 Mithrandir: I thought we had two different? 19:54:10 we got a 3rd hosting location in the meantime for s390x 19:54:12 or did my memory mix it up? 19:54:14 #info DSA have concerns about a single source of hardware, sponsored, and it doesn't appear to be improving 19:54:20 aurel32: from there different companies? 19:54:26 s,there,three, 19:54:28 jmw: it's a mild concern though, not a blocker. 19:54:33 Mithrandir, noted 19:54:34 note that we have 3 sponsors there for the machines 19:54:37 do we actually expect to have any issues with the current sponsors? 19:54:42 adsb: no. 19:54:45 k 19:54:49 just checking 19:54:49 ok, then we are not depending on one company but there 19:54:53 but three. 19:54:56 (bad fingers) 19:55:04 I think that sounds ok-ish to me 19:55:05 I think it's a tad unfair given that we went from 1 location to 3. 19:55:07 but only IBM produce such machines 19:55:26 Mithrandir: could we live with that we now have 3 locations? 19:55:48 It's more important that unstable actually works. It'd probably make sense to give a deadline for confirmation that it actually works and warn. 19:56:03 yes, we can live with it. If we couldn't, I'd not have said "mild concern" 19:56:09 the s390 thing is just a mild/minor concern. something to keep in mind. 19:56:10 ok, so we could go ahead 19:56:14 good. 19:56:15 #info we do have redundant locations. DSA's concern is only mild 19:56:17 it's not, by any means, a blocker at this time. 19:56:23 Once s390x is in stable it likely does not break again. 19:56:44 ok, I move that it's releasable unless there are deal-breakers during freeze. objections? 19:56:45 ok, so I think we agree and could go to the next ones 19:57:13 I hear no objections :) 19:57:14 #agree s390x will be a release architecture 19:57:37 now, new architectures. I realise feelings may be strong here, please try not to flood the channel 19:57:53 which one first? 19:57:59 ppc64el is IMHO releaseable 19:58:09 let's start with arm64, since it appears (to me) less progressed than ppc64el, so we may be able to carry some decision to the latter 19:58:12 #topic arm64 19:58:14 (but we need to make the minor details like buildds etc) 19:58:16 #info arm64 is a new port 19:58:30 Mithrandir, weasel ? 19:58:35 multiple concerns: 19:58:40 I thought so :) 19:58:52 - Expensive hardware, so hard to replace if it breaks 19:59:11 - No porterbox due to silly no-iran-nk-cuba requirements. Being worked on by ARM lawyers 19:59:28 - existing hosts have very poor managability (e.g. no remote power/reset; no oob management; no remote reinstall) 19:59:33 - no location redundancy 19:59:40 Mithrandir: aren't the first two expected to be fixed in 6-12 months when hw is more common? 19:59:49 (and the others are same as armhf/le?) 19:59:55 in 6-12 months is post release 19:59:57 #info DSA have multiple concerns; hardware availability, management of existing hosts, no geographic redundancy 20:00:04 6-12 months is a long time away 20:00:04 i don't think that's ok 20:00:07 jcristau: not doubting about that 20:00:09 aba: we have _no_ location redunancy for arm64 20:00:11 it's also very much up in the air 20:00:23 Mithrandir: sure, that sounds to me like "not yet" 20:00:48 we're ok with the port if those points are addressed in full well before the release. 20:01:01 i.e. now 20:01:09 well, or in a fortnight 20:01:25 I've only heard a freeze date, not a suggested freeze length, so that is hard to comment on 20:01:40 the boostrap is also nowhere near done afaict? 20:01:42 suffice to say we do not wish the freeze to drag 20:01:57 dropping a port isn't hard to do 20:01:58 jcristau: IMHO lacks mostly build power, until it's worse than ppc64el 20:02:04 we have set agressive internal targets 20:02:07 jcristau: AIUI, that's correct. That's not really a DSA concern, though. 20:02:26 there's 87 !debian packages right now 20:02:27 Mithrandir: sure 20:02:32 (but absolutely on-topic for the meeting. :-) 20:02:49 aba: i don't care why it's not done 20:02:50 but we 20:03:09 jcristau: that wasn't an excuse but an explanaition 20:03:12 're close to freeze and the arch isn't bootstraped in sid, i think that's relevant for arch qual 20:03:28 jcristau: so you'd say "no" 20:03:30 +? 20:03:33 (just to be clear) 20:03:39 I do think it's difficult for us to be strict with other ports while giving arm64 a free license 20:03:43 at this point, yes 20:03:50 anyone here for "yes, it should be in"? 20:03:54 it's not in good shape by any of our criteria, though it does have committed porters 20:04:02 arm porters maybe? 20:04:12 zumbi: ? 20:04:12 that would be interesting to have comments from them 20:04:24 <_rene_> I'd agree with this, but then we should keep armh at least (don't mind about armel, except maybe raspberry people), I don't think we should drop arm completely :) 20:04:26 * weasel would like to see both arm64 and ppc64el in. 20:04:32 <_rene_> armhf 20:04:32 it's been making good progress, at least, just not there yet aiui 20:04:41 _rene_: I don't think we want to drop armhf/le 20:04:44 I believe Sledge is travelling right now 20:04:48 he is 20:04:50 yes, the level of commitment from arm64 porters is good. 20:05:08 we could maybe delay the decision, but not by much 20:05:26 actually if we add a new arch to testing, we should do it for all at the same time 20:05:33 i'm not going to stop anyone adding it to testing and see what it looks like in a month, but it's clearly not in good shape now. 20:05:42 aba: well, I have no clear word I can say about arm64, it is just too new, but it should improve over time 20:05:42 i.e. in case we add ppc64el, then we should add arm64 the same time 20:05:47 #info the port is not yet bootstrapped into sid 20:05:58 jcristau: that was a thought I was having, yes 20:06:02 (of course as jcristau said we still could drop it later) 20:06:21 there's nothing stopping them from tracking testing and doing a jessie-arm64-unoff. 20:06:28 Mithrandir: absolutely 20:06:35 like we did for the first iteration of amd64, back in the day. 20:06:52 so we have strong DSA concerns, not bootstraped into sid yet, but consider to add it now to give them time to fix that (or be dropped again before release)? 20:06:56 are we looking at technology preview then? 20:07:05 I don't think so 20:07:10 "technology preview" doesn't mean anything. 20:07:19 debian on linux is something we quite experienced 20:07:27 and it has to be ok or it will be dropped 20:07:34 yeah, it's "just" another port there 20:07:48 I have as: concerns-rm: "not fully bootstrapped into sid yet" 20:07:51 do we have any way of knowing how successful a testing migration might be for these ports if we tried it right now? 20:07:59 s/migration/bootstrap 20:08:04 jmw: you mean testing sourcing? 20:08:18 should be possible given enough buildd power (uh) plus a bit of time 20:08:26 but freeze makes it easier not harder 20:08:37 (I have done it before, and I could do it again) 20:08:57 I'd be open to trying it very soon, and making a better informed decision in a couple of weeks time. but I don't know if that's really feasible 20:09:15 I forget the details of how we did the bootstrap last time. I know nthykier believes britney should be able to do it unaided, but I don't think you can without either a quite chunky initial force-hint or a by-hand import of a set of initial packages 20:09:32 adsb: nah, just set it to break+fucked, and let britney do the rest 20:09:45 and then binNMU special packages in testing 20:09:59 (at least that's how we did armel plus kbsds) 20:10:08 * jcristau thinks this is off topic 20:10:15 * aba agrees 20:10:16 yeah, sorry 20:10:30 if it's feasible in principle, I'd welcome volunteers to try it and report back 20:10:48 and meanwhile we can record a 'release arch in principle, assuming successful' in the minutes 20:10:57 jmw: if it (plus ppc64el) is in testing, I'd take a look 20:11:01 aba, thanks 20:11:01 and assuming DSA concerns addressed? 20:11:20 Mithrandir: obviously 20:11:20 the lack of porterbox is a non-starter for release imo 20:11:26 Mithrandir: is the blocker currently all lawyer-based? 20:11:30 Mithrandir: I put that as "strong" on the web page 20:11:46 jmw: the other half was same as the other arms 20:11:49 #action aba to try a testing bootstrap of arm64 and ppc64el 20:11:52 jcristau: it might be that the porters are able to get ARM to pony up more HW if they point out that they're at a real risk of missing the train. 20:11:57 it can go either way. 20:12:00 jmw: only if it's really in testing of course 20:12:00 aba: location redundancy is Strong too. 20:12:09 aba, ok 20:12:12 weasel: I put all DSA comments as storng 20:12:15 (for the web page) 20:12:23 (good. they are.) 20:12:28 the DSA concerns for arm64 do worry me 20:13:04 weasel, Mithrandir: anything we need to explicitly minute so that we could go ahead? 20:13:11 I'd like to get a yes/no for the port tonight, but I fear that may not be realistic 20:13:30 jmw: it's a "we try it out, but might need to drop it again" I think 20:13:37 that WFM. 20:13:38 aba, agreed 20:13:44 (and the drop could happen prior to the release) 20:13:52 yeah. we should have tried it before tbh :( (and yes, I know it was suggested previously) 20:14:03 sorryfor doing so 20:14:04 the drop will probably end up being during freeze, I don't think we'll get a resolution before then 20:14:57 #agree arm64 is a release architecture in principle, providing a testing bootstrap is successful and DSA's hardware concerns can be alleviated. if there are significant problems, the architecture may be dropped before release 20:15:05 #topic ppc64el 20:15:13 arm64 for website: candidate: "only if issues are fully resolved prior to release" 20:15:16 we need to be very clear about what needs to be done by when to not have some very disappointed porters for arm64 then 20:15:25 ack 20:15:42 DSA: two concerns from DSA, one mild: relying on sponsors for HW, like for s390x 20:15:43 definiltly 20:15:49 mild concern, not a blocker 20:15:56 ^ definitly = arm64 20:15:56 #info mild DSA concern about hardware, not a blocker 20:16:10 The other is a single DC location only 20:16:21 this is being worked on and seems to be making good progress. 20:16:22 Mithrandir: the current VMs are at two different DCs 20:16:23 Mithrandir: there is a second (non-dsa) buildd now 20:16:31 aba: not the debian.org owned ones 20:16:41 weasel: sure, we need to move to DSAed ones 20:16:53 Mithrandir: are you confident the single DC location will be resolved? 20:16:54 but leitao is actively working on getting us a power8/power7+ box at OSL. 20:17:02 or weasel 20:17:12 the shipping to OSUOSL should happen soon 20:17:16 excellent 20:17:17 presumably at some point there'll be a DSAed porter box too 20:17:17 yes. it's being worked on and it should happen soonish. 20:17:28 the last mails i have seen are about the address / phone number 20:17:34 #info DSA concerns about hardware location are expected to be resolved imminently 20:17:37 yes, I'm confident it'll happen. They seemed very on the ball at debconf. 20:17:44 adsb: yes. mainly blocking on being installable, and ideally being in testing :) 20:17:46 also we still have the offer about IBM in France or possibly in Canada 20:17:54 but that would mean yet another location 20:18:01 the port coverage seems to be very promising. are there RM concerns apart from bootstrapping testing? 20:18:07 for the web page that is now: concerns-dsa: "rely on sponsors for hardware (mild concern); no geo-redundancy (strong, being worked on) 20:18:11 I need to go now, since I have a plane to catch tomorrow morning, but I'm sure weasel can speak up if there are more DSA input. 20:18:11 weasel: ppft :) 20:18:19 Mithrandir: good flight 20:18:21 jmw: not from me 20:18:32 Mithrandir: thanks for your input 20:18:34 I shall be toasting from the town of London tomorrow. 20:19:06 (of course we also need a DSAed porter box etc, but well.) 20:19:19 are there any objections to a similar ok-in-principle for ppc64el? 20:19:39 I think it's more obvious here what we want 20:19:50 just the geo-redundancy needs to be resolved 20:19:54 wfm (and has more chance of getting the concerns fixed, I suspect) 20:20:21 #agree ppc64el is a release architecture in principle, providing a testing bootstrap is successful and DSA's hardware concerns can be alleviated. if there are significant problems, the architecture may be dropped before release 20:20:23 there's also only 3 non-bootstrapped packages remaining on ppc64el 20:20:26 for website: candidate: "yes (if geo-redundancy is ok)" 20:20:38 adsb: one of them cant build on any arch (openldap) 20:20:39 yes, the port is much better progressed than arm64 20:20:46 adsb: unfortunately for the last 3, it's on any arch 20:20:49 ok, I think we've covered all arches. did I miss any? 20:20:53 the othertwo are rc buggy because they're rejected by ftp-master 20:21:01 due to newer packages taken over binary packages 20:21:05 * jcristau heads to bed 20:21:07 good night 20:21:12 jcristau: good night 20:21:13 jcristau: thanks, and good night 20:21:13 aurel32: aba: thanks for the information 20:21:18 jcristau: o/ 20:21:22 yes, openjpeg is a huge mess 20:21:25 jmw: I think we're done 20:21:30 jmw: I'd like to also add mips64el but that was too slow for now :) 20:21:36 #unlurk 20:21:42 thanks everybody for your input 20:21:43 (and I think it's better to resolve the mipsel issues first) 20:21:46 #endmeeting