20:00:35 <jmw> #startmeeting
20:00:35 <MeetBot> Meeting started Sun Oct 30 20:00:35 2016 UTC.  The chair is jmw. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:35 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:42 * Sledge waves
20:01:03 <jmw> #meetingname Architecture Qualification for Stretch
20:01:03 <MeetBot> The meeting name has been set to 'architecture_qualification_for_stretch'
20:01:15 <jmw> #lurk
20:02:12 <jmw> ok, release team please wave
20:02:18 <nthykier> o/
20:02:33 <jmw> (seems to be all the meetbot things I did last time, anyway)
20:02:51 <adsb> o/
20:03:25 <adsb> not a great showing
20:03:31 <adsb> jcristau sent apologies
20:03:58 <jmw> pochu wasn't expecting to be here but is allegedly not away, so might be
20:04:49 <jmw> that must be all. this could be interesting
20:04:57 <jmw> anyone representing DSA?
20:06:25 <aurel32> note that i am there, but i prefer not do represent DSA
20:06:36 <aurel32> weasel waved above
20:06:52 <aurel32> s/not do/not to/
20:09:01 <jmw> porters?
20:10:00 * Sledge waves
20:10:23 <aurel32> i am there for mips* and s390x (that's why i don't want to represent DSA)
20:12:05 <jmw> I'm not convinced this is going to work
20:12:12 <jmw> let's start with the easy ones and see how we go
20:12:19 <nthykier> sgtm
20:12:20 <jmw> #topic amd64/i386
20:12:27 <jmw> any objections to these two?
20:12:54 <nthykier> None from me
20:13:02 <adsb> nope
20:13:11 <jmw> #agree amd64/i386 stay
20:13:35 <jmw> #topic amd64/armhf/armel
20:13:51 <jmw> arm64 seems uncontroversial to me
20:14:20 <nthykier> Ack
20:14:24 <nthykier> (from me)
20:14:39 * vagrantc notes arm64 is prone to typos as amd64
20:14:52 <adsb> yes (to both)
20:15:05 <nthykier> jmw: you got the topic wrong :)
20:15:07 <jmw> armel and armhf have dsa mild concern for local admin; assuming these are the machines at ARM, they're well resourced and committed
20:15:17 <jmw> fixing
20:15:19 <jmw> #undo
20:15:26 <jmw> #topic arm64/armhf/armel
20:15:49 <jmw> so unless someone says that a stronger concern, I'm not worried by it
20:16:06 <jmw> and they have only indirect upstream support, which I'm also not worried about unless someone complains
20:16:23 <nthykier> Ack from me on those two as well
20:16:42 <jmw> Sledge: want to add another arm architecture? :)
20:16:44 <adsb> aye
20:16:47 <adsb> no. bad jmw
20:17:08 <nthykier> oh
20:17:22 <adsb> oh?
20:17:33 <nthykier> was armel going to be removed after Stretch?
20:17:38 <jmw> #info DSA has mild concerns over armel/armhf local admin requirement, but the host is well-resourced, works normal hours and isn't going away any time soon
20:17:47 <adsb> nthykier: that was my understanding, yes
20:17:49 <adsb> Sledge: ^^
20:18:03 <Sledge> acl
20:18:03 <jmw> #info armel/armhf have only indirect upstream support through the family, but that's not considered a big issue
20:18:14 <jmw> #agree arm64/armel/armhf stay
20:18:26 <Sledge> sorry on mobile... crap signal
20:18:35 <jmw> pfft 'after stretch' is years away yet
20:18:50 <nthykier> jmw: before buster then
20:19:13 <jmw> not an issue for today though?
20:19:20 <nthykier> true
20:19:53 <jmw> ok other easy ones
20:19:58 <jmw> #topic s390x
20:20:11 <jmw> #info DSA relies on sponsors for hardware (mild concern)
20:20:20 <jmw> that's all I know is a problem for this one
20:20:39 <nthykier> Ack from me
20:20:46 <adsb> sure
20:20:49 <jmw> it's unchanged from jessie
20:20:57 <jmw> #agree s390x stays
20:21:21 <jmw> so that leaves mips friends and powerpc, unless there are any new arches I don't know about
20:21:59 <jmw> #topic mips/mips64el/mipsel
20:22:07 <aurel32> and ppc64el, unless you count it as powerpc
20:22:09 <KiBi> o/ (sorry for the lag)
20:22:19 <jmw> ohai
20:22:29 <jmw> aurel32, right
20:22:46 <jmw> mips64el seems more straightforward than the others: it's marked 'only if resolved' but I don't see any actual issues
20:22:56 <jmw> oh no upstream support. but no known issues
20:23:01 <aurel32> about upstream support
20:23:06 <jmw> healthy porter population
20:23:15 <aurel32> we contacted Matthew Fortune, a MIPS GCC maintainer
20:23:28 * jcowgill has arrived after forgetting about the clock change...
20:23:39 <aurel32> and he considers mips* is covered by the mipsisa64-elf target
20:23:51 <aurel32> quoting him: "In reality the embedded mipsisa64-elf target can be used to demonstate pretty much any bug in mips therefore making every mips architecture a primary one."
20:25:11 <jmw> that sounds pretty positive
20:25:23 <aurel32> also note that #834147 is fixed
20:25:36 <jmw> and there is nothing else for mips64el, so adsb nthykier thoughts?
20:26:22 <adsb> did everything get rebuild? istr there was one package remaining a while ago
20:26:29 <nthykier> I did
20:26:33 <nthykier> It*
20:26:34 <adsb> (I admit to not having had sufficient tuits to check)
20:26:43 <adsb> don't think I have any issues then
20:26:46 <nthykier> During the previous RT meeting (over 1 month ago) it was mentioned that it was missing (a part of) mariadb was not built though
20:26:51 <aurel32> https://ftp-master.debian.org/users/mhy/mipsel64import.txt
20:27:23 <aurel32> nthykier: mariadb has been fixed too (at that time the patch was in the bts, not yet applied)
20:27:31 <jmw> http://meetbot.debian.net/debian-release/2016/debian-release.2016-09-28-19.00.html was the meeting
20:28:22 <aurel32> that was #838557
20:28:30 <jmw> and with 834147 fixed as well, does that take care of mips/mipsel as well? or was there an underlying concern with that?
20:28:54 <adsb> the usual concern has been upstream toolchain support afair
20:30:11 <nthykier> well, with #838557 and #834147 fixed, plus upstream support, I am not aware of any other concerns
20:30:44 <nthykier> So at this rate, mips64el gets an ack from me
20:30:55 <jmw> toolchain support isn't such a big issue for stable, is it?
20:31:07 <jmw> but I am not srm, so
20:32:36 <jmw> and I guess we'd have coverage from Matthew Fortune on that
20:32:41 <jmw> any objections to all three staying?
20:32:49 <adsb> as long as things get rebuilt successfully, there's no specific SRM concerns
20:33:03 <adsb> (in general, for any of the current set)
20:33:41 <nthykier> ack from me
20:33:41 <adsb> and yes, that statement sounds positive for ongoing support at least
20:33:44 <jmw> #agree mips/mips64el/mipsel stay
20:33:57 <jmw> last but not least
20:34:03 <jmw> #topic powerpc/ppc64el
20:34:38 <jmw> #info DSA relies on sponsors for hardware (mild concern)
20:34:40 <nthykier> I think we should talk about them as separate architectures (to avoid confusion)
20:34:46 <adsb> yes
20:34:47 <jmw> yes, just about to
20:34:48 <jmw> #undo
20:34:49 <jmw> #undo
20:34:56 <jmw> #topic ppc64el
20:34:59 <jmw> this one should be easier
20:35:02 <jmw> #info DSA relies on sponsors for hardware (mild concern)
20:35:24 <jmw> fine for porters
20:35:31 <jmw> upstream support?
20:35:54 <jmw> #save
20:36:23 <adsb> we had an external concern raised about all of the porters being from upstream, but from the responses I don't think that's an issue in practice
20:36:34 <jmw> #meetingtopic Architecture Qualification for Stretch
20:37:11 <jmw> they are certainly putting lots of resources into it
20:37:27 <jmw> so I think we're probably fine for this cycle
20:37:40 <bunk> adsb: My concern is that they are from one company, and this is a single point of failure.
20:38:09 <ana> jmw: use #topic
20:38:22 <jmw> no, I meant what I did
20:38:34 <jmw> #save
20:38:39 <adsb> bunk: yes, but that company is also upstream
20:39:24 <adsb> anyway
20:40:13 <jmw> objections to keeping ppc64el?
20:40:19 <adsb> not from me
20:40:46 <nthykier> None from me
20:40:47 <jmw> #topic ppc64el stays
20:40:56 <jmw> er
20:40:58 <jmw> #undo
20:41:01 <jmw> #info ppc64el stays
20:41:08 <jmw> #topic powerpc
20:41:24 <jmw> this one is more of an issue
20:42:03 <jmw> is lack of porters still the main issue?
20:42:31 <nthykier> I believe it is the only blocker known
20:43:00 <jmw> (was it really zero?)
20:43:41 <jmw> #info Lack of porters is a blocker
20:43:49 <bunk> jmw: AdrianG asked several times after the roll call what it would take for him to become an official porter
20:44:14 <nthykier> When I tallied the answers from the roll-call, I got only a mail from Christoph Biedl as a porter of ppc.  Although he explicitly stated that he could not be the "main porter" of ppc
20:44:55 <nthykier> After the results were announced, AdrianG said he would be like to be signed up as a porter
20:45:13 <jmw> how do you feel about him?
20:45:21 <jmw> I'd rather have porters with a track record personally :s
20:45:33 <jmw> 3-5 years is a long time in which to get bore
20:45:34 <jmw> d
20:45:46 <adsb> 1 and a bit still wouldn't be a great number
20:46:53 <nthykier> I do not think I have any experience with Andrian (I think I have had at most 10 minutes of conversation at DebConf16 plus a few mails since the porter roll call)
20:47:27 <nthykier> So I have nothing technical to judge him beyond what he claims to have done
20:47:38 <nthykier> (i.e. maintain various architectures at -ports)
20:48:03 <Sledge> I would worry about time with other ports too...
20:49:11 <nthykier> FTR, according to popcon, it is our 4th most popular architecture: amd64, i386, armel (655), powerpc (444)
20:49:53 <nthykier> Not sure if that means a lot though
20:50:21 <jmw> yeh, that's the swing I'm trying to balance up
20:50:38 <bunk> there are not many Linux distributions left that support all the ppc macs
20:51:10 <jmw> the question in my mind is do we do those users more of a disservice by being realistic and dropping the port, giving them a couple of years of LTS, or by releasing with it but struggling afterwards
20:51:58 <Sledge> do we have ppc lts?
20:52:04 <jmw> good question
20:52:07 <bunk> no
20:52:21 <jmw> no (ref: https://wiki.debian.org/LTS/)
20:52:49 <jmw> so at most 18 months
20:52:50 <Sledge> but no experirnced ppc porters either...
20:56:04 <nthykier> Can someone remind me about the hardward - do they still produce new powerpc machines or is that all ppc64+ppc64el now?
20:56:10 <adsb> we've dropped ports before that are apparently popular with users but not porters - see sparc
20:56:37 <ansgar> nthykier: https://lists.debian.org/debian-sparc/2016/09/msg00036.html says there is still new hardware.
20:56:53 <aurel32> nthykier: there are two class of users
20:56:57 <aurel32> nthykier: old apple macs
20:57:02 <ansgar> On embedded CPUs at least.
20:57:05 <aurel32> (not produced anymore)
20:57:12 <aurel32> and embedded (still produced)
20:57:36 <nthykier> and our marketshare is both or only the "old apple macs"?
20:57:48 <nthykier> (presumed to be?)
20:57:50 <aurel32> the new server class hardware is using ppc64 or ppc64el
20:58:01 <aurel32> no idea
20:58:12 <bunk> powerpc works on 64bit big endian hardware
20:58:43 <bunk> (new Freescale CPUs, including new AmigaOne hardware)
20:59:37 <bunk> just like other 32bit ports work on 64bit hardware
21:00:10 <nthykier> ok
21:01:11 <aurel32> note that DSA runs the powerpc buildds as VMs on the POWER8 machines, running ppc64el on the host
21:01:22 <nthykier> To be honest, I am conflicted - on one hand, I want to drop it because I don't want it to end up like "another sparc", not to mention the porters having a bus factor of 1.
21:02:07 <nthykier> On the other hand, beyond the porters having a bus factor of <2, there are to my knowledge no severe reported issues
21:02:33 <jmw> my feelings exactly
21:03:10 <bunk> Is there any chance of finding additional porters? The responses AdrianG got sounded to me like a combined attempt to shut down the port (even if it might not have been intended) by at least 3 people.
21:03:32 <jmw> I'd be happier with risking a bus factor of 1 if we had a good track record, but I'm concerned that at the moment we don't really have anything to go on
21:03:50 <jmw> we've given enough opportunities for porters to come forwards
21:04:16 <jmw> being aware of discussions about the port's viability is a good barometer for commitment IMO
21:04:26 <bunk> jmw: That was not my impression after reading the emails.
21:05:27 <bunk> To me, this sounded like the exact opposite of motivating additional people to come forward for powerpc.
21:05:54 <nthykier> bunk: Are you referring to the porter roll-call itself or the mails /after/ it?
21:06:49 <bunk> nthykier: to the answers by you, Matthias and Moritz when AdrianG asked to become a porter after the roll-call.
21:06:56 <Q_> alpha was also working perfectly when it was removed.
21:07:25 <Sledge> tbh，we should not be motivatibg porters here，just counting them
21:08:10 <bunk> nthykier: my impression from the emails was you wanted to have the port excluded from stretch
21:08:11 <Sledge> imo porters sbould already be visibly active
21:11:07 <nthykier> bunk: After the roll call, right?
21:11:32 <bunk> nthykier: yes
21:14:43 <nthykier> That was based on the number of porters
21:15:56 <nthykier> I had hoped to see something (technical) from Adrian between then and now, so I had something useful to decide on, but I haven't seen any (which is not to say he didn't do anything)
21:16:03 <adsb> and afaik the one actual idenfitifed issue with mariadb hasn't been dealt with yet
21:16:29 <jmw> I see a little traffic on debian-powerpc, but not a lot
21:17:06 <nthykier> adsb: do you have a link?
21:17:26 <jmw> nthykier: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 I think
21:17:33 <adsb> yes
21:18:08 <adsb> <slrnnu838i.208.jmm@inutil.org> was in reply to adrian's "I'd be happy to pick up powerpc" (which isn't the best wording ever)
21:18:21 <jmw> which is fixed in stretch, but there's no traffic from the prospective porters on that bug
21:18:52 <adsb> with it being copied to -powerpc ~3 weeks ago
21:19:06 <adsb> certainly there's been no followups to -release
21:19:50 <adsb> and yes, fixed in stretch, but FTBFS in stable for reasons neither the maintainer nor upstream seem to be able to resolve
21:20:16 <jmw> ok I want to wrap this up, and I think I'm coming to a conclusion
21:20:18 <adsb> well, upstream were copied on the thread around the stable issue originally, and we heard nothing back there either
21:21:45 <jmw> so my view is that we want a high-quality release over its full lifetime (3+ years) and across all ports, and I don't think we're in a position to make that assertion for powerpc any longer. I would rather give 18 months graceful EOL to users than to land them in it when we have issues
21:21:59 <jmw> if more porters come forwards for buster, there's no reason it can't be added again
21:23:29 <adsb> I don't think we ever have re-added a dropped port, fwiw
21:23:35 <jmw> that doesn't mean we can't
21:23:43 <jmw> but you're not wrong
21:23:45 <KiBi> adsb: yeah, was wondering about that..
21:24:19 <adsb> but I have to agree with Sledge's earlier comments, in general. the question we asked was "is anyone working on powerpc" not "is anyone prepared to say they will if we say it's going away", which aren't the same thing
21:25:05 <nthykier> Which is also what we were trying to determine via the roll-call (although with limited success)
21:25:15 <nthykier> (i.e. who is working on the port)
21:25:31 <adsb> yes, that's what I meant
21:25:52 <aurel32> when a port is not a release architecture anymore, it needs a lot more porters to cope with the bugs, which is why they are usually not added back
21:26:12 <Sledge> nthykier: worked for other arches...
21:27:35 <Q_> aurel32: You mean people stop caring that their packages don't build on an arch and so don't fix it themself?
21:28:15 <adsb> evidence suggests some people don't care if their package builds on most release architectures either </old grump>
21:28:43 <aurel32> Q_: that's one part yes
21:29:19 <aurel32> Q_: there is also all the work to be done around transitions
21:29:30 <aurel32> usually binNMUs are scheduled, but not necessarily tracked later
21:30:12 <aurel32> (well that was just answering adsb comment, not to help with the decision)
21:30:18 <nthykier> getting back to ppc: jmw, I am inclined to agree with you.
21:31:57 <adsb> likewise, much as I dislike dropping things
21:32:50 <jmw> ok
21:32:59 <jmw> #agree powerpc will not be a release architecture for Stretch
21:33:14 <adsb> I look forward to a torrent of "I'll do it!" mails
21:33:28 <pochu> adsb: the mips64el package that needed a rebuild was db5.3, which was rebuilt before we added mips64el to testing
21:33:35 <jmw> #info For the avoidance of doubt, it's not the release team's decision whether powerpc stays in the main archive for sid or is moved to ports
21:33:48 <adsb> ooo, a pochu
21:33:51 <adsb> pochu: ta
21:33:51 <KiBi> adsb: we love those don't we
21:33:58 <adsb> KiBi: oh so
21:34:13 <jmw> #topic AOB
21:34:19 <jmw> ok so that is all the ports, any other business?
21:34:34 <jmw> #action jmw write summary of decisions
21:34:34 <aurel32> yes
21:34:41 <jmw> aurel32: go
21:35:00 <aurel32> could we try to improve the arch qualification process for the next time
21:35:17 <aurel32> it seems the table has been copied over years, but hasn't been changed that much
21:35:38 <Sledge> nod
21:35:41 <aurel32> some parts are not necessarily clear (or have been interpreted different ways)
21:35:48 <aurel32> and some things are probably missing
21:35:54 <aurel32> for example we don't talk about kernel support
21:36:02 <aurel32> which was actually an issue for sparc
21:36:27 <jmw> aurel32: can you send suggestions by mail? and we can schedule them for a meeting in the next cycle
21:36:44 <ansgar> aurel32: Something like "Do porters run testing/unstable (userland, kernel)?"
21:37:06 <aurel32> yes, I personally can send suggestions, but I guess we should really start a discussion
21:37:24 <aurel32> ansgar: doesn't necessarily mean there is upstream kernel support
21:37:33 <aurel32> ansgar: also with that argument, the toolchain is userland
21:37:51 <jmw> aurel32: a discussion would be good, but I'd rather get into the next cycle first
21:37:55 <ansgar> aurel32: Well, no, but it makes it more likely that issues are detected before a release.
21:38:05 <aurel32> jmw: ok
21:38:14 <jmw> but thoughts while it's still fresh would still be valuable, we can use them as references when that time comes
21:38:18 <aurel32> another point, is that we could probably split that in 2 parts:
21:38:37 <aurel32> - one at the beginning of a cycle: is the architecture going to be a pain for the release team to handle during the cycle
21:38:51 <aurel32> - one at the end of a cycle: is it ready to be a stable architecture
21:39:02 <aurel32> with slightly different points there
21:39:10 <jmw> #action general: suggestions for improving this process by mail please
21:39:20 <jmw> #action jmw schedule discussion of process improvement in next cycle
21:39:22 <aurel32> ok, i'll send an email in the next days/weeks
21:39:29 <jmw> thanks
21:39:32 <jmw> anything else?
21:39:47 <adsb> one, but it's not arch-qual related
21:39:53 <Sledge> aurel32 had my point...
21:40:15 <jmw> #endmeeting