path: root/meeting-logs/20170910.txt

13:10 <@WilliamH> Ok folks, let's get started.
13:10 <@WilliamH> The agenda is here: https://archives.gentoo.org/gentoo-project/message/2feef121978b6af7fb66ebc8e6626c59
13:10  * darth_dilfridge here
13:10 <@WilliamH> roll call:
13:10  * darth_tamiko here
13:10  * K_F here
13:10  * slyfox here
13:10  * mgorny here
13:10  * ulm|phone here
13:10  * WilliamH here
13:11 <@WilliamH> point 2, the hppa architecture.
13:11 <@darth_dilfridge> so I pinged jer on #gentoo-hppa and suggested we should talk, but never got a response
13:11 <@WilliamH> bug 629554
13:11 <+willikins> WilliamH: https://bugs.gentoo.org/629554 "HPPA arch stabilization problem"; Gentoo Linux, Current packages; IN_P; blueknight:qa
13:12 <@slyfox> i've got access to hppa@ to see in which status it is
13:12 <@darth_dilfridge> granted that was only yesterday, but usually he's very responsive
13:12 <@slyfox> the userspace is quite working. going through stable backlog now
13:12 <@darth_tamiko> darth_dilfridge: I will ping him as well.
13:12 <@darth_tamiko> Maybe he is around right now. :-)
13:12 <@mgorny> slyfox: so are you interested in doing that long-term?
13:13 <@slyfox> sure
13:13 <@K_F> as a generic point of order, I'd recommend we open the floor to the one requesting the item on the agenda as a routine
13:13 <@WilliamH> That was mgorny wasn't it?
13:13 <@K_F> soap iirc
13:13 <@mgorny> Soap__
13:13 <@mgorny> or rather, soap wanted it gone completely
13:13 <@mgorny> original proposal came from security team
13:14 <@mgorny> lemme find the bug
13:14 <@darth_dilfridge> Herr Seifert bitte zur Information...
13:14 <@WilliamH> The problem, as I see it personally is that one man arch teams kill us.
13:14 <@mgorny> bug 629554
13:14 <+willikins> mgorny: https://bugs.gentoo.org/629554 "HPPA arch stabilization problem"; Gentoo Linux, Current packages; IN_P; blueknight:qa
13:14 <@mgorny> #c8 states my proposal for a generic solution
13:14 <@WilliamH> As I said on the ml arch teams can do a lot 
13:15  * WilliamH is reading the bug
13:15 <@darth_dilfridge> (if present, alive and willing)
13:16 <@mgorny> as far as i understand, there's some glitch between hppa team and other gentoo devs which resulted in hppa team refusing to do the work
13:16 <@darth_tamiko> Which is effectively one person.
13:16 <@mgorny> but if slyfox is willing to take the work over, i'm all happy to let him
13:17 <@K_F> from a security perspective, cleanup isn't really too vital, it would mainly be an issue for QA if dependencies etc gets too complex due to old slots ettc
13:17 <@slyfox> there is a few users on #gentoo-hppa
13:17 <@slyfox> Dakon helps me a lot with it
13:17 <@darth_tamiko> The problem with our current model of ~arch and arch and stabiliziation is the simple fact that ebuild maintenance involves a number of unrelated projects (arch teams) and you have to wait a considerable amount of time for them to react.
13:17 <@mgorny> slyfox: how much time do you expect it will take to make hppa match other arches?
13:17 <@K_F> but I'm not seeing any real work for hppa with jer on sabbatical on stabilization work
13:17 <@slyfox> mgorny: don't know
13:17 <@darth_tamiko> This is not so much a problem for amd64 and x86 because those are - let's face it - the 98% of our developer and user base.
13:18 <@WilliamH> darth_tamiko: ++
13:18 <@K_F> and an arch with BUS factor of 1 isn't viable to begin with
13:18 <@darth_tamiko> So, what I see is that we could simply radically change our procedure for all non amd64 and x86 arches.
13:19 <@mgorny> slyfox: ballpark figure?
13:19 <@WilliamH> slyfox: you know you can also decide that packages shouldn't be stable on hppa and by moving hppa keywords in older versions to ~hppa
13:19 <@darth_tamiko> So what would be nice would be a compromise that allows (a) even small arch teams to exist and maintain an architecture, (b) a package maintainer to do their job.
13:19 <@slyfox> 2 months?
13:19 <@mgorny> kinda long
13:19 <@slyfox> WilliamH: sure. i plan to dekeyword quite a bit as hppa hardware is quite slow
13:19 <@mgorny> slyfox: are you convinced you won't lose interest?
13:19 <@WilliamH> darth_tamiko: imo that compromise is for arch teams to destabilize packages they don't see as important for their stable tree
13:20 <@darth_tamiko> Agreed.
13:20 <@mgorny> WilliamH: but destabilizing is also a lot of work
13:20 <@K_F> slyfox: I'm wondering, if you don't have any real hardware, or know anyone that relies on it, what is the incentive to do the work?
13:20 <@mgorny> especially that we don't have many split packages, and a lot of use flags instead
13:20 <@WilliamH> mgorny: sure, but what else do you suggest?
13:20 <@WilliamH> mgorny: the option then is to flip the profiles to dev
13:20 <@mgorny> for hppa, i'd say let slyfox do the work and have a backup plan
13:21 <@darth_dilfridge> ++
13:21 <@mgorny> i don't like the idea of breaking hppa completely if there's incentive to keep it working
13:21 <@darth_tamiko> But what about we codify this a bit?
13:21 <@darth_dilfridge> which will probably also lead to normalization of the "dont touch my profile" rules
13:21 <@WilliamH> imo arch teams should focus on @system packages *first*
13:21  * ulm reading the backlog
13:21 <@WilliamH> I want to remove old openrc for example.
13:22 <@darth_tamiko> For example, certain architectures should only keyword @system packages?
13:22 <@mgorny> darth_tamiko: @system packages have various far-away deps
13:22 <@K_F> darth_tamiko: keyword might be harsh, stable..
13:22 <@mgorny> like you end up stabilizing most of texlive because doc building
13:22 <@ulm> mgorny: there are use stable masks for that
13:22 <@WilliamH> mgorny: sure, I get that.
13:23 <@mgorny> ulm: not everything is use-conditional
13:23 <+leio> creative package.use.stable.mask reduces that for @system-only; but that's not really very useful to users, just some catalyst users oddities
13:23 <@ulm> mgorny: true
13:23 <@mgorny> plus, figuring it all out is probably more work than actually stabilizing it
13:23 <@WilliamH> Doesn't repoman tell you what you need to stabilize?
13:24 <@mgorny> WilliamH: it does; but it won't guess what you can avoid
13:24 <@darth_tamiko> Alternatively, if our goal is to only stabilize packages that we tried to build, what about introducing automatic tinderboxes for these architectures and stabilize (semi-)automatically?
13:24 <@WilliamH> If you stabilize something and it has an unstable dep repoman protests last time I checked.
13:24 <@slyfox> darth_tamiko: i'd be all for that
13:24 <@darth_dilfridge> we're getting into an infinite loop again
13:24 <+kent\n> need a tool really that can tell you tree-wide which packages can be de-keyworded without consequence.
13:24 <@mgorny> darth_tamiko: please stick with things that can actually happen
13:25 <@K_F> if build-only testing we're better off leaving it in ~arch
13:25 <@darth_dilfridge> I guess we more or less agree that -given someone does the work- keeping hppa is good
13:25 <@slyfox> yeah. someone nedds to formulate 1-sentence (or a few) and we vote on that
13:25 <@ulm> slyfox: go ahead :)
13:25 <@mgorny> well, i think my formula was quite good
13:25 <@WilliamH> K_F: that's what the runtime required flag is for in stable requests. if that is no it can go straight to stable.
13:25 <+leio> maybe declare the stable WG dead for starters *g
13:25 <@mgorny> give hppa $m weeks to fix stable; if they fail, we drop to ~hppa
13:25 <@slyfox> sounds ok
13:26 <@WilliamH> mgorny: what do you mean by fix stable?
13:26 <@mgorny> we can also extend it to another $n weeks to see whether ~hppa can keep up, in case we want exp
13:26 <@mgorny> WilliamH: let's say do noticeable work
13:27 <@mgorny> move it forward
13:27 <@mgorny> as long as hppa stablereqs are being closed, it works for me
13:27 <@mgorny> i wouldn't expect them to catch up with other arches but at least not have huge backlog
13:27 <@darth_dilfridge> one of our big data analysts should come up with a "freshness measure"
13:28 <@mgorny> we can also help by setting some priorities
13:28 <@slyfox> ia64 is a good example: 0 stablereq, 0 keywordreq :)
13:28 <@WilliamH> imo for any arch team, @system packages and their dependencies should be handled first
13:28 <@slyfox> but getting trend is hard, yes
13:29 <@mgorny> alternatively
13:29 <+kent\n> darth_dilfridge: getting access to bugzilla through SQL instead of that slothful JSON API would help there
13:29 <@mgorny> we defer this to slyfox
13:29 <@mgorny> if he decides he can't handle stable hppa, he has our support to drop it to ~arch
13:29 <@ulm> I wonder what the long term perspective for hppa is, though
13:29 <@ulm> the hardware went out of production when?
13:30 <@slyfox> before ia64 :)
13:30 <@darth_tamiko> mgorny: I think this is a good compromise.
13:30 <@WilliamH> mgorny: there's no need to defer anything, any arch team can already do that.
13:30 <@ulm> certainly the situation won't improve with time
13:30 <@darth_tamiko> One question.
13:30 <@darth_tamiko> How many active users of hppa, sparc and ia64 do we have anyway?
13:31 <@WilliamH> mgorny: That's what I said on the list. arch teams can drop to dev or destabilize packages without involving us at all.
13:31 <@slyfox> ulm: i'd say as long as toolchain stops support for arch and nobody can fix it it will die very fast
13:31 <@darth_tamiko> And alpha.
13:31 <@darth_dilfridge> when the last power supply has failed, the last disk replaced, the last graphics card molten, only then will we realize that a dead arch is dead.
13:31 <@WilliamH> darth_tamiko: that's a good question.
13:31 <@mgorny> WilliamH: but that actually requires a living arch team
13:31 <@WilliamH> darth_tamiko: no one really knows.
13:31 <@darth_tamiko> If we could only pick 5 arches to support, what shall those 5 be?
13:32 <@mgorny> if arch team has 2 members, both of them unresponsive
13:32 <@slyfox> darth_tamiko: each of #-arch channels has a few users
13:32 <@mgorny> it would be weird if someone else joined in and decided to ~arch immediately
13:32 <@darth_tamiko> slyfox: That doesn't mean terribly much.
13:32 <@K_F> ulm: based on the very scientific dataset, server support for hppa ended in 2013
13:32 <@WilliamH> slyfox: how many -- 5? 500? 50000?
13:32 <@darth_tamiko> slyfox: #gentoo-unregistered and #gentoo-overflow have roughly ~250 users as well.
13:32 <@slyfox> WilliamH: 2-3
13:33 <@ulm> K_F: ok
13:33 <@WilliamH> The question then becomes, do 2-3 users justify keeping a stable tree?
13:33 <@slyfox> as long as they do testing for me i'm happy to stamp their keywords
13:33 <@K_F> ulm: that should be.. "the very scientific dataset of wikipedia..."
13:33 <@slyfox> they do all heavy lifting
13:33 <@ulm> K_F: but production stopped in 2008 AFAICS
13:33 <@darth_tamiko> WilliamH: Exactly.
13:33 <@ulm> by the same scientific data set :)
13:33 <@slyfox> say, for sparc we have no hardware and my point is simple: we either go ->~sparc right away or users test a thing. and they do
13:34 <@K_F> ulm: yup
13:35 <@K_F> I'm all for dropping hppa, but should likely discuss what is the best approach in general for this, whether move to exp or drop to testing
13:35 <@darth_tamiko> Well, everyone who really insists on using Gentoo on an unknown/unsupported arch can still do that... Simply keyword **
13:36 <@mgorny> another option is to support some crazy combined ACCEPT_KEYWORDS
13:36 <@darth_dilfridge> so now that we have discussed this in detail
13:36  * darth_tamiko compiled stuff for the mmix architecture once.
13:36 <@mgorny> like have packages that are e.g. ~hppa + amd64 visible
13:36 <@WilliamH> mgorny: huh?
13:36 <@mgorny> i mean, we support only ~arch on hppa
13:36 <@darth_dilfridge> mabe we can just vote on mgorny's proposal and fill in a number when hppa should in our esteemed opinon be up to speed?
13:37 <@mgorny> but users could still restrict to packages that have been stabilized on another arches
13:37 <@WilliamH> brb
13:37 <@mgorny> how about 4 weeks? then we could confirm on the next meeting
13:37 <@darth_tamiko> Agreed.
13:37 <@K_F> mgorny: works for me
13:38 <@darth_dilfridge> wfm
13:38 <@darth_tamiko> It still stands that our current form of keywording and notion of stable arches might be a bit ambitious for the current developer size we have.
13:38 <@WilliamH> ok, back...
13:39 <@WilliamH> Now I'm composing a statement to vote on.
13:39 <@darth_dilfridge> sure, effectively that decision would be (for council) "lean back and wait for a month"
13:39 <@ulm> what about security support? hppa is in their list still
13:39 <@mgorny> that's for security team to decide, i'd say
13:39 <@K_F> ulm: that will likely be dropped anyways
13:40 <@slyfox> what is the difference between stable and sec supported arch?
13:40 <@ulm> right, we can leave it for them to decide
13:40 <@slyfox> who decides on the latter?
13:40 <@ulm> https://www.gentoo.org/support/security/vulnerability-treatment-policy.html
13:40 <@K_F> slyfox: security project determines the latter
13:40 <@slyfox> got it. thanks!
13:40 <@mgorny> slyfox: i think sec supported means they will care about vulnerable packages on the arch
13:40 <@WilliamH> For the hppa architecture, the council will wait four weeks for improvement in stabilization.
13:40 <@ulm> supported architectures must have a stable fix committed before the GLSA can be released
13:40 <@darth_dilfridge> sec team
13:40 <@mgorny> i.e. if they drop support, they will just ignore you're not cleaning up old versions and so on
13:41 <@slyfox> *nod*
13:41 <@mgorny> except you can't clean old versions up
13:41 <@K_F> for glsa-check we're looking at updating it so it provides a generic warning that the arch isn't supported
13:41 <@WilliamH> mgorny is right, you can't clean up old versions when an arch falls behind
13:41 <@K_F> but the users will still be able to use it to check if they have vulnerable versions on system based on the released GLSAs, it just isn't necessarily stable
13:41 <@mgorny> but you can unkeyword the old version for other arches
13:41 <@K_F> and we won't handle security issues specific to the arch assembly
13:42 <@K_F> not cleaning up old version isn't security relevant
13:42 <@darth_tamiko> But seriously, we start to discuss in-detail procedures again.
13:42 <@mgorny> let's vote finally: "since slyfox has joined hppa team and resumed stabilization work, we're deferring any actions against hppa for now. we will check the status at the next meeting, and decide whether any action needs to be taken"
13:42 <@WilliamH> Do we want to vote on this?
13:42 <@darth_tamiko> I am fine with the current consensus on giving hppa another 4 weeks to get up to speed again.
13:43 <@K_F> vulnerable packages with sufficient impact is masked by glsa-check / GLSA, but removal of a package doesn't result in mask on a system
13:43 <@WilliamH> The council gives the hppa team four weeks to improve stabilization.
13:43  * slyfox votes yes :)
13:43 <@K_F> if we do that, we should phrase it as a pre-warning
13:43 <@darth_tamiko> But in the long run we should really come to a conclusion wether it is feasible and worthwile to support architectures with a potential userbase of 5 people worldwide.
13:43 <@K_F> the council is worried about the state of hppa, but due to request gives it 4 weeks before a final decision is made on removal of stable support
13:43 <@WilliamH> darth_tamiko: agreed, but that's a separate topic.
13:43 <@mgorny> K_F: we'll do to hppa what we decide today for sparc
13:44 <@ulm> what wording are we voting on? mgorny's or WilliamH's?
13:44 <+kent\n> q) how is "improve" defined.
13:44 <@K_F> WilliamH: is chair, so he calls the vote
13:45 <@K_F> but I agree with kent\n , it needs to be more precise
13:45 <@WilliamH> K_F: that sounds reasonable.
13:45 <@WilliamH> mgorny: what was your wording?
13:45 <@mgorny> WilliamH:  "since slyfox has joined hppa team and resumed stabilization work, we're deferring any actions against hppa for now. we will check the status at the next meeting, and decide whether any action needs to be taken"
13:45  * slyfox votes yes
13:45  * WilliamH votes yes on mgorny's wording
13:45  * mgorny yes
13:45  * darth_tamiko votes yes
13:45  * K_F yes
13:45  * ulm votes yes
13:46 <@darth_tamiko> darth_dilfridge: *ping*
13:46  * darth_dilfridge yes
13:46 <@WilliamH> now point 3, bug 630258
13:46 <+willikins> WilliamH: https://bugs.gentoo.org/630258 "sparc stabilization issues"; Gentoo Linux, Current packages; CONF; williamh:qa
13:46 <@WilliamH> Bottom line here is we have no hardware.
13:46 <@WilliamH> imo
13:46 <@mgorny> and no arch team
13:47 <@darth_dilfridge> well
13:47 <@darth_dilfridge> we have hardware, but no arch team
13:47 <@K_F> based on robbat's email, the hardware is in place, but no AT
13:47 <@slyfox> for sparc we don't have access to hardware but Robin says HDD was replaced on bender and arch team was supposed to proceed with reinstall.
13:47 <@mgorny> the hardware has no system, and there is nobody who wants to install it
13:47 <@darth_dilfridge> but noone did anything
13:47 <+Soap__> soz guys, was away
13:47 <@darth_tamiko> How many developers on sparc do we have? How many users?
13:47 <@slyfox> i have no experience with AMILO and can give it a try but likely will fail :)
13:48 <@ulm> same as for hppa, give them 4 weeks and revisit in october?
13:48 <@WilliamH> ulm: no
13:48 <+Soap__> ulm: no
13:48 <@mgorny> nah
13:48 <@darth_dilfridge> ulm: no
13:48 <@K_F> ulm: only if someone is willing to step up and take responsibility for it
13:48 <@mgorny> there's no good will for sparc afaics
13:48 <+Soap__> this is the usual defer action
13:48 <@slyfox> Currently Dakon on #gentoo-sparc does all the testing for me
13:48 <@mgorny> slyfox: so you're doing that one too
13:48 <@darth_dilfridge> if there's no team, there's no arch
13:48 <@mgorny> ?
13:48 <@slyfox> yes
13:48 <@darth_dilfridge> seriously?
13:48 <+Soap__> and no, please no last minute "but I will run it"
13:48 <@WilliamH> darth_dilfridge: ++
13:48 <@mgorny> do you have any expectations?
13:49 <+Soap__> this is the problem with Gentoo, people randomly step up in the last second in a last-ditch attempt
13:49 <@slyfox> not much
13:49 <@mgorny> slyfox: do you expect this to take much longer than hppa, for comparison?
13:49 <@slyfox> whatever Dakon won't be able to test i'll drop to ~sparc or dekeyword completely
13:50 <@darth_dilfridge> slyfox: no offense, but this makes me want to revisit the hppa vote
13:50 <@WilliamH> it does me also
13:50 <@slyfox> should be faster. sparcs are generally faster
13:50 <+Soap__> ...
13:50 <+Soap__> is that your argument? really?
13:50 <@K_F> at leats sparc is still produced so there is still possibilities for getting hardware
13:50 <@darth_tamiko> slyfox: The problem is that we now discuss a bus factor of 0.5 for two arches... :-D
13:50 <@slyfox> you say two
13:50 <@WilliamH> slyfox: Do you honestly think you can keep up with stable requests for two arches by yourself?
13:50 <@ulm> K_F: quite expensive though
13:51 <+Soap__> WilliamH: + keywordreqs
13:51 <+Soap__> + normal AT work
13:51 <+Soap__> K_F: also silently EOL'd
13:51 <@mgorny> well, i'd say we can keep hppa because we at least have working hardware
13:51 <@K_F> ulm: I'm less worried about that, if we had some corporate users of it I'd be all for it
13:51 <@mgorny> for sparc, the system is not working
13:51 <+Soap__> its semi-evident that SPARC will likely slowly die away
13:51 <@K_F> ulm: although at some point would ask them for support in maintaining it..
13:51 <@mgorny> i would say we give a final call for sparc arch team
13:51 <+Soap__> they had 3
13:51 <@mgorny> and give them 2 weeks to get the hardware working again
13:51 <+Soap__> they replied to none of my mails
13:52 <@slyfox> sounds good
13:52 <@mgorny> if they don't, we drop it to exp
13:52 <@K_F> the primary issue with decision for sparc as I see it is the bug was only filed 3 days ago
13:52 <@ulm> we discussed sparc in 201309, 201503 and 201612 already
13:52 <@mgorny> K_F: it's not like it's something new
13:52 <+Soap__> yes, exactly
13:52 <@K_F> although the issue is discussed in previous council meetings
13:52 <@WilliamH> These arches have been discussed multiple times in previous council meetings.
13:52 <@darth_dilfridge> so what was robbat2's timeline? how long was the box already available again without a team response?
13:53 <@slyfox> since april
13:53 <@darth_tamiko> An informal question to all participants. What do you expect? sparc arch team coming back from the dead and being alive and kicking in 2-4 weeks?
13:53 <@darth_dilfridge> :(
13:53 <@slyfox> both armin and jmorgan retired
13:53 <@K_F> but there is an argument to be made for a drop to ~arch to reboot things, if they keep up with @system etc it doesn't exclude bringing it to stable again if appropriate
13:53  * WilliamH would rather remove sparc profiles and keywords at this point
13:53 <@K_F> or exp, depending on discussions
13:53 <+Soap__> K_F: I asked for droping to exp due to that not helping
13:54 <@ulm> drop to dev or exp, but don't remove profiles
13:54 <@darth_tamiko> I am strongly in favor of reducing our keywording and stabilization workload.
13:54 <+kent\n> what will happen to sparc hardware if we kill it?
13:54 <@mgorny> it's not like anything is happening to that hardware anyway
13:55 <@ulm> bender is a Sun Fire T200
13:55 <@ulm> how old is that?
13:55 <@mgorny> i'd say a generic definition would be, if we don't have a maintained working system on given arch ,it's not feasible for it to be stable
13:55 <@slyfox> ~2006
13:55 <@mgorny> (one where any dev can get access to immediately)
13:55 <@darth_tamiko> *puh*
13:55 <@K_F> ulm: T200 or T2000?
13:56 <@ulm> the infra page says T200
13:56 <@ulm> but that seems wrong indeed
13:56 <@darth_tamiko> slyfox: I would say it would definitely help to concentrate on a small set of packages for sparc (and maybe also hppa). And this might be best achieved by going to ~arch.
13:56 <@mgorny> guys, we're sidetracking with no apparent purpose
13:57 <@ulm> K_F: EOL in january 2010
13:57 <@mgorny> darth_tamiko: dropping to ~arch won't help if there's no hardware
13:57 <+Soap__> can we please drop the profiles?
13:57 <@ulm> K_F: for T2000
13:57 <+Soap__> drop to dev/exp*
13:57 <@darth_tamiko> I mean, half of our "power" users run ~amd64. I totally expect all users of esoteric platforms to run ~ia64 and ~sparc and ~hppa anyway.
13:57 <@WilliamH> For sparc, there's no hardware.
13:57 <@mgorny> let's vote before 9 PM
13:57 <@darth_tamiko> mgorny: That's true.
13:57  * WilliamH proposes a vote:
13:58 <@WilliamH> The council wants to drop the sparc profiles to dev.
13:58 <+leio> WilliamH: again, there is hardware. It just doesn't have gentoo installed and the information that it is fixed and awaiting gentoo install only seems to have went out to people who are retired now; so e.g mattst88 who was interested in working on it thought the hardware is dead.
13:58 <+leio> (don't take this as my suppor of keeping it, though)
13:59 <@WilliamH> leio: I'm not proposing removing the keywords/profiles.
13:59 <@ulm> keywords will soon be inconsistent once the profile is dropped to dev
14:00 <@mgorny> WilliamH: how about "the Council gives a finall call for arch team to reestablish the sparc system. if the system is not restored to working condition in 2 weeks from now, sparc profiles will be marked exp"
14:00 <@mgorny> s/ll/l
14:00 <@K_F> I'd say next meeting for that then
14:00 <@WilliamH> two weeks is reasonable.
14:00 <@K_F> the two weeks difference doesn't really make much difference
14:00  * darth_dilfridge thinks we're quite good at deferring
14:00 <@mgorny> K_F: it does
14:00 <+leio> it does avoid for some last minute appearances.
14:01 <@WilliamH> I don't like that we defer so much tbh
14:01 <@mgorny> let's try the vote for 2 weeks first
14:01 <@K_F> WilliamH: ditto
14:01 <@ulm> mgorny: dev or exp?
14:01 <@darth_tamiko> Experimental I'd say.
14:01 <@darth_tamiko> Because this is what it in fact is.
14:01 <@slyfox> what is the difference? :)
14:01 <@ulm> exp will practically kill it, nobody runs repoman for exp
14:02 <@WilliamH> you can run repoman -d or -e to cover those.
14:02 <@mgorny> i'd say exp, that's where other fun arches si
14:02 <@mgorny> sit*
14:02 <@slyfox> ah, fun
14:02 <@K_F> yeah, other minor arches is a good argument
14:02 <+leio> slyfox: there is no practical difference other than what repoman argument to pass between them right now. Some odd people do pass -d, no-one but the relevant arch teams themselves pass "-e y" really
14:02 <@mgorny> after all, the arch team can always restore stable if they resume operation
14:02 <@darth_tamiko> Let's vote on demoting sparc right now. No 2 weeks condition.
14:03 <@slyfox> yes, i usually run 'repoman -d' :)
14:03 <@K_F> darth_tamiko: I'm more for that myself
14:03 <@ulm> slyfox: but not -e
14:03  * WilliamH tends to agree with darth_tamiko 
14:03 <@slyfox> not -e
14:03 <@mgorny> WilliamH: so vote for marking all sparc profiles exp?
14:03 <@WilliamH> The council motions to move sparc to exp.
14:03  * slyfox votes no
14:04  * K_F yes
14:04  * darth_tamiko votes yes
14:04  * mgorny yes
14:04  * WilliamH yes
14:04  * ulm abstains
14:04 <@darth_tamiko> darth_dilfridge: *ping*
14:04 <@slyfox> darth_dilfridge: ^
14:04 <@slyfox> (not that it would matter much :)
14:05 <+Soap__> thank you
14:05 <@darth_tamiko> Let's give him a minute to come back with a coffee.
14:05 <+Soap__> ...finally
14:05 <@WilliamH> It looks like the motion to move sparc to exp passes.
14:06 <@slyfox> yep
14:06 <@WilliamH> next point:
14:06 <@darth_tamiko> slyfox: I think we can invest everyone's time more efficiently in fixing problems that affect more users. Let me take this opportunity to thank you for your invaluable work in the toolchain project with respect to foreign arches :-)
14:06 <@WilliamH> There are no other bugs with council involvement, so open floor:
14:07 <@slyfox> darth_tamiko: the other day i've found generict memory corruption on nettle affecting every arch
14:07 <@slyfox> only on sparc it failed a test
14:07 <@slyfox> basically the essence of my love for all crippled arches :)
14:07 <@darth_tamiko> :-D
14:07 <@slyfox> the bug is real and corrupted you certificates
14:07 <@darth_tamiko> slyfox: Well, we're not implying we shouldn't keep the toolchain functional for all of those small arches.
14:08 <+Soap__> slyfox: thats super, but thats not equivalent to keeping it a stable profile
14:08 <@darth_tamiko> slyfox: But concentrating on toolchain (and directly associated packages) is a good thing.
14:08 <@slyfox> Soap__: i agree
14:08  * ulm has to leave
14:08 <@mgorny> WilliamH: fin?
14:08 <@WilliamH> Anything else for open floor?
14:09  * WilliamH bangs the gavel, meeting closed