15:01:41 @radhermit	time for roll call
15:01:50  *	dilfridge here
15:01:52  *	rich0 here
15:01:53  *	WilliamH here
15:01:56  *	ulm here
15:02:11 @radhermit	dberkholz, blueness?
15:02:33 @radhermit	someone might need to text blueness unless he's on other channels
15:04:34 @WilliamH	blueness is on other channels but he has been idle for a while
15:04:42 @dberkholz|mob	here, sorry. browser froze up
15:05:32 @radhermit	alright so let's start (if someone can text blueness that would be cool)
15:05:53 @radhermit	first up, EAPI 6 stuff
15:06:01 @dilfridge	https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_6_tentative_features
15:06:03 @radhermit	ulm: did you finish things up for this?
15:06:17 @radhermit	I remember you mentioning something on the list
15:06:32 @ulm	list of features is here: https://wiki.gentoo.org/index.php?title=Future_EAPI/EAPI_6_tentative_features&oldid=267018#Accepted
15:06:41 @ulm	and current spec is here: https://gitweb.gentoo.org/proj/pms.git/log/?h=eapi-6
15:07:03 @ulm	ready for review, except for one item (eapply function) still missing
15:07:40 @radhermit	alright
15:07:49 @ulm	but I'd like to get the feature list frozen, so I can finish the spec and it can be reviewed
15:07:50 @blueness	rich0, thanks man, i fell asleep!\
15:08:13 @blueness	i laid down for a sec, and was off
15:08:23 @radhermit	so let's vote to feature freeze it then and get it out the door
15:08:40 @radhermit	since I think that's all that's necessary, right?
15:08:51 @ulm	radhermit: for today, yes
15:08:52 @dilfridge	sure
15:09:28 @radhermit	motion: feature freeze EAPI 6 as per current spec
15:09:46 @dilfridge	(plus eapply?)
15:09:46 @dberkholz|mob	sure
15:09:54 @radhermit	+ eapply obv :P
15:10:10  *	dilfridge yes
15:10:13  *	radhermit yes
15:10:17  *	ulm yes
15:10:21  *	blueness yes
15:10:24  *	rich0 yes
15:10:28  *	WilliamH yes
15:10:44 @radhermit	passes unanimously
15:11:00 @radhermit	next up, lagging arches discussion part 2
15:11:02 @ulm	actually eapply is there as a placeholder :)
15:11:59 @WilliamH	ulm: I'm fine with that.
15:12:14 @radhermit	there was a bunch of discussion on the list around the topic for lagging arches
15:12:26 @dberkholz|mob	brb
15:12:31 @radhermit	I'm not sure if people got any great finalized ideas from that yet
15:12:45 @blueness	that was my sense too
15:12:49 @dilfridge	blackbird told me to ping him later this week
15:13:03 @dilfridge	which (as I replied) was obviously non-ideal timing
15:13:36 @WilliamH	I think it is going to be up to us to do something about the lagging arch's situation ultimately though.
15:14:00 mgorny	could you at least confirm that developers can't leave broken dep tree, though?
15:14:10 @dberkholz|mob	back
15:14:35 @WilliamH	mgorny: If that means we are going to force devs to keep old packages in the tree forever, that isn't good.
15:14:40 @ulm	mgorny: my understanding was that dropping keywords implies that the depgraph can be left in a broken state
15:14:41 @dilfridge	ok one thing that we should clarify is how the originial "minor arches proposal" was meant
15:14:46 @WilliamH	s/packages/versions of packages/
15:14:47 @radhermit	I'm all for not breaking the tree
15:15:18 @radhermit	for stable arches, for exp ones... many are in a permanent state of breakage
15:15:19 @blueness	it should be possible to drop keywords to ~arch systematically and leave the tree intact
15:15:21 @dilfridge	that was my understanding at the time too, but since we're now more and more going towards "keeping repoman green" automatically, I'm not sure if it is a good idea
15:15:37 mgorny	i'm considering stable arches only
15:15:50 mgorny	i'm fine with either developers dropping keywords from rev-deps, or making arches exp as necessary
15:15:55  *	WilliamH agrees with mgorny about stable arches...
15:16:01 mgorny	but not having permanent repoman failure on stable arches
15:16:07 @WilliamH	But, if a stable arch is lagging, that's the question.
15:16:33 creffett|irssi	mind if I throw an opinion in here?
15:16:38 @dilfridge	sure
15:17:12 creffett|irssi	this comes up about once a year and always seems to end up with arch team members coming in at the last minute and complaining
15:17:25 creffett|irssi	at this point, it's a consistent pattern
15:18:04 creffett|irssi	so it's probably best to just throw all of the lagging arches into exp and let the arch teams sort them out if/when they get their act togethr
15:18:09 @radhermit	personally I'm of the opinion that relatively "rarer" arches shouldn't have stuff like gnome/kde/etc stabilized, I'm not sure how prevalent that kind of keywording is nowadays though
15:18:18 @radhermit	have stable system sets
15:18:35 @dilfridge	ok
15:18:46 @rich0	For the minor archs, I think making them exp in repoman is a likely solution
15:18:57 @WilliamH	creffett|irssi: I tend to agree.
15:19:02 @rich0	If they want to be stable, they need to stay on top of their keywords.  It isn't a punishment, it is just reality.
15:19:03 @blueness	if i may add to what radhermit said, and speak to ppc/ppc64
15:19:21 @ulm	why exp? there is dev too
15:19:29 @blueness	i don't want to see ppc/ppc64 dropped to exp or to ~arch like mips, it causes lots of problems with catalyst runs
15:19:30 @rich0	I'd still like to see a better solution for the major archs (mostly amd64 at this point I guess).
15:19:36 @radhermit	anyone know what the these arches have stabilized beyond @system?
15:19:42 @blueness	but i would like to see things like gnome/kde etc dropped
15:19:52 @radhermit	some have massive stuff that probably only a few people use that we've been dragging around for ... years
15:20:05 @rich0	blueness: if they don't want to be dropped to exp, they have to get their keywords together
15:20:13 @WilliamH	blueness: exp/dev  doesn't mean ~arch, it just means that repoman doesn't complain about them unless you use -d or -e
15:20:17 @rich0	It isn't practical for anybody else to clean up after them on that.
15:20:35 @blueness	rich0, it should be that difficult to drop large blocks at once
15:20:45 @dilfridge	should we place on the agenda for **NEXT** meeting, votes for more arches "keep stable or move profiles to dev/exp" ?
15:21:09 @WilliamH	dilfridge: Why do we have to wait until next meeting?
15:21:10 @dilfridge	then there's one more month of reaction time and a timely announcement of our intentions
15:21:14 @rich0	dilfridge: if it goes to next meeting, then I'd expect archs to demonstrate that they're already up-to-date.
15:21:23 @dilfridge	exactly
15:21:31 @rich0	They have a month to clean up, if they can't fix their keywords in a month, they won't fix them in a year.
15:21:48 @WilliamH	We have given them a long time to cleanup and they haven't done it.
15:21:55 @rich0	And what if in a month we find that amd64 isn't current within 90 days on STABLEREQs?
15:21:59 @radhermit	who's cleaning this stuff up? it's not going to happen in a month
15:22:29 @WilliamH	rich0: my understanding is that devs with amd64 hardware can stable their own stuff.
15:22:30 @blueness	i would start a cleanup on ppc/ppc64 but i don't even know what "cleanup" means
15:23:09 @radhermit	my problem with dropping arches fully to exp/dev is that then people often start totally ignoring them while pkgcheck and other things explode
15:23:11 jmorgan1	yes, please define what you mean by cleaned up? can you add that criteria for all arches
15:23:23 @dilfridge	blueness: works best with logical blocks like libreoffice & friends
15:23:29 @rich0	radhermit: that is pretty-much the point
15:23:33 @radhermit	example: multilib on mips
15:23:40 @WilliamH	It means catch up your stable reqs and keep up .
15:23:59 @rich0	I'm fine with them staying stable, but they have to start dropping keywords to something they can actually manage
15:24:01 @blueness	jmorgan1, glad to see you here we should get together and talk about how to proceed forward with ppc/ppc64
15:24:05 @radhermit	or scratch that... it was multilib on... musl or something
15:24:07 @WilliamH	you shouldn't have any stable reqs with your arches in the cc that are older than 90 days
15:24:32 @dilfridge	(unless blocked for a reason)
15:24:56 jmorgan1	WilliamH: please collect that data (> 90 days in stablereq) for all arch and send it out
15:25:03 @rich0	dilfridge: a reason being a blocker on a package that upstream supports on the arch
15:25:28 @rich0	WilliamH: I'd suggest sending that out now, so we can assess the current state
15:25:31 @WilliamH	jmorgan1: I"m probably not the best person to do that... I don't have access to an interface on bugzilla where I can do it easily.
15:25:38 jmorgan1	also, i don't see any dev asking alacking arch team to clean up anyting
15:25:43 @radhermit	also, would it help if we had a tool that did depgraph (de)keywording? I don't think ekeyword supports such things
15:25:44 jmorgan1	asking
15:26:22 jmorgan1	if you are a maintainer and an arch is slacking on your packages, why not go ask them yourself instead of coming to the council
15:26:33 jmorgan1	mr_bones has been doing that recently
15:26:45 jmorgan1	and I closed out those BZ
15:26:54 @dilfridge	talking to people in person helps... leaving messages on bz tends to be futile
15:27:04 @dilfridge	drowned in bugmail
15:27:09 @rich0	who put this on the agenda?
15:27:38 @rich0	Of course maintainers should ask the arch team first, but if they get impatient, complaining to council is fair game imho
15:28:02 @radhermit	rich0: looks like kensington requested it be revisited
15:28:24 @blueness	rich0, although more cooperation might be helpful because if we're lagging somehwere, we could coopearate on large drops to ~arch
15:28:33 mgorny	gentoo isn't really going to work efficiently if people constantly have to bother other people to do their job
15:28:43 @WilliamH	Right now, we have a policy that allows dropping of stable keywords for certain arches after 90 days...
15:29:06 jmorgan1	WilliamH: i don't hink its certin arch but all arch IIRC
15:29:18 @WilliamH	jmorgan1: no, it isn't all arches.
15:29:19 @dilfridge	yeah, but it also will never work if "talking to others" is replaced by "complaining to someone else" (council isnt the only example)
15:29:34 @ulm	jmorgan: it's definitely a subset of archs only
15:29:48 @dilfridge	it's NOT amd64, hppa, arm
15:30:24 @WilliamH	The arches I'm not really concerned about are amd64, hppa, arm, x86
15:30:26 @ulm	list is here: https://projects.gentoo.org/council/meeting-logs/20130917-summary.txt
15:30:59 floppym	Any chance for an official ruling on breaking the depgraph for current stable archs? This conversation sort of wandered away from that. Or does that need to be added to an agenda first?
15:31:07 @dilfridge	x86 currently has way more open bugs than ppc btw
15:31:13 @WilliamH	arm64 actually now I wouldn't say anything about either, but that isn't a stable arch.
15:31:20 @WilliamH	it is a new arch.
15:31:44 @radhermit	floppym: do we need an official ruling on breaking stable depgraphs?
15:32:04 floppym	radhermit: To prevent weird reverts, yes.
15:32:08 @WilliamH	imo what we need is to extend the policy to cover all arches
15:32:10 @radhermit	fair enough
15:33:26 @blueness	dilfridge, actually that's true, ppc and ppc64 don't have over 100 bugs for stablereq, they just have some old ones
15:33:34 jmorgan1	can the council define what an arch needs to do in order to not move to ~arch
15:33:57 @rich0	jmorgan1: we're not talking about moving to ~arch.  we're talking about making profiles experimental
15:34:05 @rich0	They can keep stable tags, but maintainers don't have to respect them
15:34:24 jmorgan1	same difference imo
15:34:39 @WilliamH	jmorgan1: not really.
15:34:45 @rich0	not really - they can still use stable keywords to keep track of core package versions that are dependable
15:34:59 @WilliamH	jmorgan1: repoman -d or repoman -e will check experimental or dev profiles
15:35:11 @dilfridge	just that noone bothers to tell them when an old version is dropped f.ex.
15:35:12 @blueness	rich0, i don't like dropping to exp either because that's just permission to break dep graph
15:35:17 @radhermit	how many people run repoman with the deep option by default?
15:35:22 @dilfridge	and that noone bothers to file stable requests
15:35:27 @blueness	i'd rather stay stable and remove blocks of stable keywords
15:35:44 @radhermit	I mean, I usually do... but also my cvs tree isn't always up to date ;)
15:36:19 @rich0	blueness: I'd rather that too, but that is on the arch team to make it happen
15:36:22 @dilfridge	ok about that "lagging definition"
15:36:24 @radhermit	and it misses breaking other pkgs that would require full tree checks anyway
15:36:28 @rich0	if they don't do it themselves, NOBODY is going to do it for them
15:36:32 @blueness	mgorny, can we write a simple script that say "if you drop stable keywording from this package, you must also drop it form packages X Y and Z?"
15:36:37 @rich0	after all, the people MOST interested in the arch are already on the arch team
15:36:53 @blueness	rich0, okay so let ppc/ppc64 work towards that
15:37:00 @radhermit	blueness: that's what I was saying previously about an extended ekeyword script that checks depgraphs...
15:37:01 @dilfridge	how about "should not have a significant number of stabilization requests open for >90 days without significant reasons"?
15:37:10 jmorgan1	i suggest that the council move to define what criteria would cause an arch to go to exp/devand/or ~arch.
15:37:12 @radhermit	i.e. I'd write a pkgcore equiv that would do that
15:37:26 @rich0	blueness: like I said - if they can make serious progress in a month I'm happy to give them a month
15:37:50 jmorgan1	create a policy instead of just vote to move to exp/dev profiles
15:37:51 @radhermit	"significant" defined as?
15:37:55 @blueness	radhermit, that would help me immensely because I would just go through and start closing ppc/ppc64 stablereqs systematically
15:38:01 @WilliamH	dilfridge: The problem is what is "significant"? imo a base-system package like  openrc or util-linux is significant on its own.
15:38:04 @rich0	jmorgan1: IMHO, stablereq open longer than 90 days without a documented blocker (with upstream supporting the arch)
15:38:18 @blueness	rich0, i don't know how long it would take but we can work in that direction
15:38:32 jmorgan1	rich0: only 1?
15:38:55 @rich0	jmorgan1: sure, why not?
15:39:05 @rich0	But, the council can use discretion
15:39:08 @WilliamH	jmorgan1: absolutely.
15:39:38 jmorgan1	i also like the idea of a probation period instead of just drop to dev/exp profile - 30 day warning
15:39:39 @rich0	But, that brings me back to my earlier question.  What happens when amd64 or x86 has an old stablereq?
15:39:43 @blueness	that's excessive, we can work towardsit
15:39:46 @WilliamH	jmorgan1: If there is no reason to block the stablereq, and the maintainer as filed the stable req, it is up to the arch team to stabilize it in a reasonable amount of time.
15:40:01 jmorgan1	WilliamH: no disagreement there
15:40:15 @rich0	The arch team could also just remove the stable keywords themselves.
15:40:27 @dilfridge	this is starting to sound like an "arch retirement autoping"
15:40:31 @WilliamH	jmorgan1: especially if the arch team has stabilized an older version of the package.
15:40:32 @rich0	They don't HAVE to stabilize packages, they have to get the bug closed.
15:40:43 creffett|irssi	rich0: how does that work when the arch team is too busy to stable?
15:40:50 @radhermit	one thing I've been wondering about under the current system is how much arch testers actually run/check pkgs on the arches beyond "hey it compiled and perhaps passed its unit tests"
15:41:05 @dilfridge	radhermit: you dared to ask the question
15:41:05 @rich0	creffett|irssi: they need to spend less time stabilizing packages, and more time removing stable packages.
15:41:06 mgorny	well, there's one more option: developers marking stuff stable themselves after the timeout
15:41:11 @radhermit	some that handle 1 or 2 arches probably do fine, some that handle 5-6 arches ...
15:41:13 @radhermit	hahaha
15:41:26 @radhermit	dilfridge: someone had to ;)
15:41:29 @rich0	creffett|irssi: they could also go exp for a few months, until they catch up, then ask to be stable again
15:41:58 @rich0	mgorny: what is the point of having a stable tag if we apply it purely based on time?
15:42:02 @blueness	rich0, jmorgan1 i have another idea
15:42:09 @radhermit	I mean, if we've just been stabilizing large portions of the tree based on compile "testing" that could be automated a whole lot more
15:42:25 mgorny	rich0: well, we can assume developers will still need to have some competence
15:42:27 @blueness	what if we give maintainers the permisison to automatically stabilize after 90 days?
15:42:36  *	dilfridge remembers about "silence will fall when the question is asked"
15:42:42 @WilliamH	dilfridge: lol
15:42:43 @radhermit	;)
15:42:58 jmorgan1	radhermit: i agree that a more automate approach would help
15:42:59 @rich0	I have a sparc package.  How can I "competently" stabilize it without having a sparc in my basement?
15:43:24 @blueness	rich0, then the sparc team can live with the mess
15:43:25 jmorgan1	rich0: we have dev boxes
15:43:56 mgorny	well, you can: a) repoman it for depgraph, b) assume someone with ~sparc has tested it, c) assume that it was tested on stable amd64
15:43:58 @blueness	rich0, so can't an arch team simple decide that is sufficient criterion?
15:44:24 @dilfridge	is testing in qemu-user enough?
15:44:34 @radhermit	depends on the program
15:44:40 @blueness	eg if the package has been stabilized on other arches, and sparc is still left over after 90 days, autostabilize
15:44:46 @rich0	I don't want to run kde on qemu-user for a sparc...
15:44:51 @radhermit	;)
15:44:52 @dilfridge	heh
15:44:57 jmorgan1	rich0: no kde support in sparc
15:45:02 jmorgan1	so don't worry
15:45:20  *	WilliamH is tending to agree with blueness
15:45:25 @blueness	i'd like to propse that as a policy
15:45:43 @WilliamH	blueness: something like this?
15:46:54 @blueness	(i assume WilliamH is composing something)
15:47:00 @radhermit	... I was wondering...
15:47:06 @WilliamH	"If a maintainer has waited 90 days for arch teams to complete a stable request  [more detail here maybe] the maintainer can stabilize the package on all remaining arches unless there is a blocker."
15:47:39 @blueness	WilliamH, yes, but for more detail let's just say that it has been stabilized on at least one other arch
15:47:43 @rich0	WilliamH: ... a blocker and the package is considered supported on the arch by upstream.
15:47:47 jmorgan1	WilliamH: only addition is a ping first, just as a helpful notice
15:48:19 @rich0	But, here is a question.  Do the arch teams actually WANT a policy like this?
15:48:21 @blueness	90 percent of stabilization failures woudl fail on all arches, but not all
15:48:25 @rich0	Would they rather have stable break instead?
15:48:26 @WilliamH	rich0: How do we know if a package is considered supported on the arch by upstream?
15:48:41 @blueness	rich0, ppc and ppc64 can entertain that, so propose it to the entire community
15:48:41 @rich0	You're the maintainer - you should be easily able to find what upstream considers supported.
15:48:42 @WilliamH	rich0: I don't see a lot of packages that list arches they support.
15:49:02 @dilfridge	usually that means they dont care, as long as it builds
15:49:06 @rich0	In any case, it was in our policy last time.
15:49:21 @rich0	Otherwise blockers hold things open forever, for issues upstream never intends to fix.
15:49:21 @WilliamH	rich0: Some do, but that doesn't seem the most common thing.
15:49:25 @dilfridge	I mean, why should, say, a text editor like nano be arch-specific?
15:49:46 @rich0	How about ...unless there is a blocker with a bug that the upstream package has accepted.
15:50:01 jmbsvicetto	blueness: from my experience with arch teams, I consider this proposal as "naive". It ignores all the errors that show up on big endian arches, it ignores all the testing that needs to be done for distinct mips processors and other hardware specific issues
15:50:03 @blueness	dilfridge, because sizeof might vary from arch to arch and cause breakage in one but not the other
15:50:16 @blueness	jmbsvicetto, i am aware
15:50:31 @ulm	dilfridge: I don't know about nano, but emacs comes with a list of supported arches
15:50:34 @dilfridge	yes, and we should probably leave that condition in, otherwise we get stabilizations that will never work (imagine opencv drops support for an arch)
15:50:36 @blueness	it changes the meaning of what we mean by stable
15:51:00 @rich0	blueness: that is why I think we should talk to the arch teams
15:51:10 @rich0	they might prefer to have stable dropped, vs random packages stabilized
15:51:18 @dilfridge	maybe it would be a good idea to give arch teams time to react to this idea
15:51:25 @blueness	rich0, you are talking to at least one, ppc+ppc64 which is me and jmorgan1
15:51:50 @WilliamH	I think ago does most of the other minor arches ;-)
15:52:04 @blueness	rich0, we would prepfer to have systematic stablereq blocks dropped, but not under the pressure of get it done in one month or go exp
15:52:17 @blueness	rich0, instead i prefer changing the meaing of stablereq
15:53:07 @dilfridge	this would improve reaction time of "minor arches", at the cost of stability
15:53:17 @blueness	dilfridge, correct
15:53:38 @blueness	but at least we would get to choose the high priority packages and get on them rgith away
15:53:42 @dilfridge	with the bonus that the dependency tree stays unbroken
15:53:52 @blueness	and still not drop to dev/exp
15:53:54 @blueness	dilfridge, correct
15:53:56 @rich0	I'm fine with an interim policy for one month telling everybody not to break depgraphs, but I think we really need to get back on the lists and discuss some concrete proposals.  Arch teams really need to get involved in this.  It is going to affect them.
15:54:13 @rich0	I want a solution that works for them, but we can't just tread water.
15:54:22 @WilliamH	How would I know if I was going to break a depgraph --- repoman?
15:54:35 @rich0	WilliamH: yup - it is pretty obvious
15:54:38 @blueness	rich0, suppose in one month ppc/ppc64 comes back with my proposal as okay for that arch?
15:54:39 @WilliamH	ok.
15:54:46 @radhermit	repoman run tree wide really
15:54:49 @radhermit	which few people do
15:55:04 @rich0	blueness: I'd prefer something that works for all archs, but if we need per-arch policy I'm fine with anything that seems sustainable.
15:55:06 @blueness	radhermit, that's intenstive, can we get ekeyword expanded
15:55:08 @WilliamH	because it takes four hourse ;-)
15:55:12 @WilliamH	hours *
15:55:20 @radhermit	hey, pkgcheck on travis-ci takes like ~15 mins :P
15:55:25 @rich0	It just can't require maintainers to be building on minor archs themselves.
15:56:03 @blueness	radhermit, i'd like something liek this .... stabledeps <cat/pkg> ... which returns the list of all packages which must be stable along with <cat/pkg>
15:56:20 @blueness	then i can drop them all to ~arch without dep graph breakage
15:56:30 @blueness	and run pkgcheck just to be sure
15:56:45 @radhermit	blueness: I'll try to hack something up, but it'll be pkgcore-based
15:57:06 @blueness	radhermit, yeah i was going to start hacking ekeyword
15:57:11 @radhermit	so I was afk for a bit, did we get any final takeaways from this discussion at all?
15:57:12 @blueness	but i can live with anything
15:57:18 @blueness	well anything that works
15:57:43 @blueness	radhermit, two things
15:57:48 @WilliamH	Good question, where are we with this...
15:57:51 @rich0	(FYI - I'm going to be a lot more afk in a few mins.)
15:57:55 @blueness	1) the weak definition of stablereq above
15:57:58 jmorgan1	rich0: why doesn't a council member go ping each arch team
15:58:10 jmorgan1	see if there are still active
15:58:14 @rich0	jmorgan1: already done.
15:58:14 @blueness	2) the possibility of dropping large blocks of stabilized packages without brekaing depgraph
15:58:16 jmorgan1	get more input
15:58:28 @rich0	somebody sent an email to all of them, and there is -project and -dev
15:58:41 @rich0	But, I can send another email.  I'm just not going to hunt them down at home...  :)
15:58:48 @WilliamH	jmorgan1: we've been trying for years :p
15:58:49  *	blueness ping blueness
15:58:50 @dilfridge	jmorgan1: if noone replies...
15:58:53 @radhermit	I'll probably talk to the guy behind 4-5 minor arches tonight ;)
15:58:54 jmorgan1	rich0: do how many arch leads responded?
15:59:03 @radhermit	but most of those are exp these days afaik
15:59:10 @rich0	I'd have to look.  You're here, but there was very little response
15:59:12 @blueness	radhermit, those don't count because they're exp
15:59:43 @rich0	But, I don't want to rush into this.  I'm fine with giving it another month.  We really need engagement though.  If an arch team just can't keep up at all, I really question them not being marked exp
15:59:58 jmorgan1	again, back to ploicy. if an arch team is not active. then it makes sense to drop their profiles
16:00:00 @rich0	If they're just going to have a bazillion auto-stable packages that might not even build, why bother?
16:00:02 jmorgan1	policy
16:00:13 @radhermit	the problem is, major arches like amd64 can suddenly not keep up if one or two people take a break
16:00:21 @WilliamH	Ok, which arch teams can we consider inactive at this point.
16:00:28 @radhermit	(at least it was like that only a year or so ago)
16:00:30 @blueness	rich0, if its a lot then its bad
16:00:36 @rich0	Also, this is just a point in time.  They can be inactive today, and active tomorrow.  They can be active today and inactive tomorrow.  We need to adjust over time.  This isn't some once-and-for-all decision.
16:00:43 @blueness	but as i said above 90% either fail on all arches or pass on all arches
16:00:47 @blueness	so we adopt a risk
16:01:02 @radhermit	ok so anyway... I'll try to summarize this all
16:01:06 @WilliamH	radhermit: amd64 shouldn't have issues because most devs are on amd64 and we can stabilize there.
16:01:08 @blueness	the gamble breaks when bigendianness or sizeof(foo) aren't the same
16:01:15 @rich0	ok, I will be fairly afk.  I'll try to watch out for votes or anything major
16:01:25 @radhermit	moving sort of on... did we want to even vote on ffmeg/libav stuff?
16:01:27 @dilfridge	QFloat on arm. Nuff said.
16:01:38 @radhermit	doesn't seem council is necesary imo
16:01:56 @radhermit	unless people start flip/flopping the setting
16:02:01 @blueness	radhermit, i didn't even understand that issue really
16:02:42 @WilliamH	radhermit: I would agree, we aren't needed unless people start flip-flopping the default.
16:03:15 @WilliamH	blueness: the issue was just that mgorny wanted us to pick the default for it, but I don't think that's necessary unless there is conflict.
16:03:24 @dilfridge	fine with me, given that this is actually a "first changing of the default", more or less
16:03:34 @radhermit	alright then that'll be our response unless others have issues
16:03:42 @radhermit	so we're basically out of time now
16:03:56 @radhermit	we've got bug #503382
16:03:56 @WilliamH	So where are we on the arches?
16:03:58 willikins	radhermit: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
16:04:11 @radhermit	WilliamH: hardly anywhere new, afaics
16:05:10 @WilliamH	radhermit: so can we do anything with old stable reqs?
16:05:35 @dilfridge	we should probably table to next week if we want to talk more about the arches
16:05:45 @WilliamH	like bug 530424
16:05:47 willikins	WilliamH: https://bugs.gentoo.org/530424 "sys-apps/kmod-19 stable request"; Gentoo Linux, Keywording and Stabilization; CONF; williamh:udev-bugs
16:05:56 @ulm	sorry, I was afk for a few mins. I'm o.k. with no council action for ffmpeg/libav. it's a use flag default only and should be handled by maintainers
16:05:56 @radhermit	I think we'd need to actually vote on stuff and the discussion ran too long and varied unfortunately
16:06:25 @WilliamH	bug 530418
16:06:30 willikins	WilliamH: https://bugs.gentoo.org/530418 "net-fs/nfs-utils-1.3.1-r4 stable request"; Gentoo Linux, Keywording and Stabilization; CONF; williamh:net-fs
16:07:35 @radhermit	so yes, tabling the discussion about arches for another month then
16:07:41 @blueness	okay
16:07:42 @radhermit	is probably best at this point
16:08:32 @radhermit	open floor now if anyone else wants to discuss things
16:08:41 @WilliamH	sorry folks, I was looking up bugs and didn't see the last messages
16:09:34 @radhermit	otherwise the official portion of the meeting is closed