path: root/meeting-logs/20140326.txt

2014-03-26 19:49:57	 *	zlogene is here, already 
2014-03-26 19:53:11	 *	zlogene take chocolate ice cream with cherry and waiting for meeting start
2014-03-26 19:53:29	 *	TomWij just ate chocolate and goes for a drink.
2014-03-26 19:59:40	 *	Zero_Chaos is here
2014-03-26 20:00:27	@creffett|irssi	k, showtime.
2014-03-26 20:00:38	 *	ulm here
2014-03-26 20:00:40	@WilliamH	ok you should get the email
2014-03-26 20:00:45	@WilliamH	qa team...
2014-03-26 20:00:57	 *	WilliamH is here
2014-03-26 20:00:59	 *	TomWij is here
2014-03-26 20:01:22	 *	Tommy[D] didnt miss his own reminder
2014-03-26 20:01:32	@creffett|irssi	wired, Pinkbyte, bonsaikitten: you all here?
2014-03-26 20:01:45	 *	Pinkbyte here
2014-03-26 20:02:18	@creffett|irssi	close enough.
2014-03-26 20:02:36	@creffett|irssi	first question: do we want to do rotating meeting times? I know this time doesn't work for everyone
2014-03-26 20:02:36	@TomWij	(Agenda @ https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda)
2014-03-26 20:03:11	@Zero_Chaos	creffett|irssi: wednesday are almost always bad for me, especially in the middle of the work day. so I have to vote for rotating meetings.
2014-03-26 20:03:33	@creffett|irssi	Zero_Chaos: I agree, especially when this summer comes and I actually have a job to keep
2014-03-26 20:04:14	@creffett|irssi	so how will we want to handle that is the real question--do we want to go for discussion-only during meetings and voting some other way? vote during meetings and if you can't make it too bad? what?
2014-03-26 20:04:27	@creffett|irssi	(also, I will fire up a whenisgood so we can find another good time)
2014-03-26 20:04:41	@Pinkbyte	creffett, what about shifting meeting time to saturday or sunday?
2014-03-26 20:04:41	@Tommy[D]	i disagree, we already checked, when most people have time and even then, see last week, we have problems get enough people together
2014-03-26 20:04:45	@TomWij	I wouldn't mind if they were rotating, giving everyone a fair chance to attend; though, the only concern I have here is when times get picked where not a sufficient quorum can attend.
2014-03-26 20:04:54	@Tommy[D]	other times will make it even harder to even get half of qa together
2014-03-26 20:05:19	@creffett|irssi	Tommy[D]: then what would you prefer we do with the handful of people who can't/rarely can make the current time
2014-03-26 20:05:27	 *	WilliamH agrees with Tommy[D] 
2014-03-26 20:05:32	@zlogene	what about make meeting on Saturday/Sunday
2014-03-26 20:05:35	@zlogene	?
2014-03-26 20:06:02	@Tommy[D]	creffett|irssi: pretty simple: normal meetings/votes like now and we dont get a majority, let the rest vote via mail within e.g. 48 hours after announcing open vote on the alias
2014-03-26 20:06:06	 *	WilliamH isn't opposed to a weekend meeting...
2014-03-26 20:06:17	@ulm	I'm against meeting on weekends too
2014-03-26 20:06:27	 *	TomWij isn't opposed to a weekend meeting either.
2014-03-26 20:06:35	@Tommy[D]	weenends is pretty bad, i often cant say when/if i have time then
2014-03-26 20:07:27	@Zero_Chaos	honestly I have more freetime if we shift this +5-6 hours
2014-03-26 20:07:28	@creffett|irssi	the issue here is that we pretty effectively span the globe
2014-03-26 20:07:32	@Tommy[D]	in addition i like it to have sometimes a day for myself without any meetings/work ;)
2014-03-26 20:07:34	@creffett|irssi	no matter when we pick, someone suffers
2014-03-26 20:07:34	@Zero_Chaos	but then everyone else is alseep
2014-03-26 20:08:14	@zlogene	so, i agree with pinkbyte about weekend 
2014-03-26 20:08:18	@Tommy[D]	creffett|irssi: so the best we can get is like we do now: get the majority together, let the rest vote in addition, if needed for a majority vote
2014-03-26 20:08:44	@Tommy[D]	we cannot make it right for everyone and shifting times make it very likely we would not even get half of qa team together
2014-03-26 20:09:27	@creffett|irssi	yeah.
2014-03-26 20:09:28	@TomWij	creffett|irssi: We could 1) vote right now on making it rotating or not, 2) do a doodle to pick the preferred day of the week and 3) do another whenisgood to see if there is perhaps a better hour than 1900 UTC due to changed schedules.
2014-03-26 20:09:42	@Tommy[D]	Zero_Chaos: nothing against you personally, but seems like you got the worst timezone together with Patrick 
2014-03-26 20:09:56	@Pinkbyte	Tommy[D], yep, seems the better decision. And 48h timeframe for voting can be extended a bit. Let's see, we have meeting at wednesday. Let's say, that majority should be there and other should vote till next Monday
2014-03-26 20:09:57	@creffett|irssi	Tommy[D]: I'm in Zero_Chaos's timezone :P
2014-03-26 20:10:05	@Zero_Chaos	Tommy[D]: I'm actually the same timezone as creffett|irssi, just I have a job :-P
2014-03-26 20:10:11	@creffett|irssi	^^
2014-03-26 20:10:45	@zlogene	!time zlogene
2014-03-26 20:10:45	willikins	zlogene: Europe - Moscow - Wed Mar 26 23:11 MSK
2014-03-26 20:11:09	@creffett|irssi	I would like to try another whenisgood just to check if the DST shift (for those affected by it) has opened up a better time
2014-03-26 20:11:38	@Tommy[D]	Zero_Chaos: even then, if we take you 2 out, we still have 6 out of 10, who can make it, any other time will have even lower numbers and we need 6 to get a majority vote....
2014-03-26 20:12:04	@creffett|irssi	and for the future, I think our best bet will unfortunately be to have people send in their opinions beforehand if they can't make it, and conduct email votes if we don't have a majority
2014-03-26 20:12:12	@Zero_Chaos	Tommy[D]: I agree, but it is kinda shitty to plan every meeting to miss 40% of the team.
2014-03-26 20:12:26	@Zero_Chaos	creffett|irssi: I think possibly voting by list is a good idea.
2014-03-26 20:12:38	@Tommy[D]	Zero_Chaos: its not good, but still better to plan with 60% missing
2014-03-26 20:12:59	@Tommy[D]	*still better then to plan with 60% missing
2014-03-26 20:13:05	@Zero_Chaos	Tommy[D]: rotating meeting times to always catch at least 6 but miss different people wouldn't hurt.
2014-03-26 20:13:09	@Zero_Chaos	if possible anyway
2014-03-26 20:13:39	@creffett|irssi	I'll look into that too, if there's a different time which has >=6 on whenisgood then we can consider rotating to that occasionally
2014-03-26 20:13:48	@Tommy[D]	Zero_Chaos: thats the point: if possible, keep in mind that current schedule was the best matching time for all and we have problems getting a majority at the best time....
2014-03-26 20:14:28	@creffett|irssi	Tommy[D]: let's see how the whenisgood turns out
2014-03-26 20:14:35	@Zero_Chaos	accepted
2014-03-26 20:14:42	@creffett|irssi	next topic.
2014-03-26 20:14:46	@WilliamH	creffett|irssi: sounds reasonable to me.
2014-03-26 20:14:57	@creffett|irssi	vapier stabilizing on experimentals: do we care? what do we want to do, if we do care?
2014-03-26 20:15:04	@Tommy[D]	creffett|irssi: i suggest you create it, send a mail after meeting and we can discuss via mail once its done
2014-03-26 20:15:15	@Zero_Chaos	creffett|irssi: please provide background
2014-03-26 20:15:15	@creffett|irssi	Tommy[D]: I was planning on that
2014-03-26 20:15:23	@creffett|irssi	WilliamH: I think this was yours
2014-03-26 20:15:26	@creffett|irssi	(the vapier thing)
2014-03-26 20:15:29	@TomWij	+1 on whenisgood
2014-03-26 20:15:29	@Tommy[D]	any update from council wrt those arches?
2014-03-26 20:15:37	@WilliamH	creffett|irssi: Well, if the archs have exp in their profiles we don't have to care.
2014-03-26 20:15:56	@Zero_Chaos	oh experimental arches?
2014-03-26 20:15:59	@Zero_Chaos	+1 for don't care
2014-03-26 20:16:28	@WilliamH	That's the point of the status in profiles.desc
2014-03-26 20:16:34	@Zero_Chaos	very much so
2014-03-26 20:16:41	 *	WilliamH isn't sure about dev status
2014-03-26 20:16:47	@Zero_Chaos	if you are using an experimental profile you get to keep the pieces.
2014-03-26 20:17:01	@zlogene	what should we do if vapier still stabilize for this? 
2014-03-26 20:17:09	@Zero_Chaos	and if it ever moves up to a stable profile, less work if they were already following a stabilization policy (of some kind)
2014-03-26 20:17:11	@zlogene	revert, or no?
2014-03-26 20:17:17	@WilliamH	zlogene: nothing if the profiles are in the right status
2014-03-26 20:17:20	@creffett|irssi	zlogene: I'm still unclear if it even matters to us
2014-03-26 20:17:26	@Pinkbyte	zlogene, as said - if the whole arch profiles are 'exp' - just do not care
2014-03-26 20:17:34	@zlogene	okay 
2014-03-26 20:17:39	@Pinkbyte	if repoman -d does not throw warnings - forget about this
2014-03-26 20:17:48	@TomWij	+1 for don't care; I think I've said earlier that the lack of stage3 makes it experimental to users anyway, and when it gets out of experimental we expect the arch team to properly make sure it is stable.
2014-03-26 20:18:12	@Pinkbyte	TomWij, the culprit is that some of those arches are not exp, they are dev
2014-03-26 20:18:13	@Zero_Chaos	sounds like TomWij summed up the majority favor
2014-03-26 20:18:16	@zlogene	+1 for don't care then 
2014-03-26 20:18:22	@Zero_Chaos	Pinkbyte: dev we care.
2014-03-26 20:18:26	@Pinkbyte	i mean arch profiles of course
2014-03-26 20:18:29	@Zero_Chaos	I think we have to care on dev
2014-03-26 20:18:33	@creffett|irssi	then what do we do about dev?
2014-03-26 20:18:44	@Zero_Chaos	creffett|irssi: what specifically was done?
2014-03-26 20:18:52	@TomWij	Pinkbyte: Some of which arches, did vapier stabilize something like that on dev?
2014-03-26 20:18:54	@creffett|irssi	Zero_Chaos: ask WilliamH, this was his issue
2014-03-26 20:19:09	@Zero_Chaos	WilliamH: can you please provide some background on this? I am unfamiliar.
2014-03-26 20:19:14	@Pinkbyte	TomWij, sh is still in dev, right?
2014-03-26 20:19:21	@Pinkbyte	and s390
2014-03-26 20:19:26	@WilliamH	Zero_Chaos: council declared some archis to be unstable then vapier continued stabilizing packages..
2014-03-26 20:19:34	@zlogene	Pinkbyte: yes 
2014-03-26 20:20:14	@WilliamH	s390, sh and  (I can't find the other one right now)...
2014-03-26 20:20:16	@Pinkbyte	to be 'unstable only' if i understand right
2014-03-26 20:20:21	@Pinkbyte	WilliamH, m68k
2014-03-26 20:20:22	@Zero_Chaos	WilliamH: the profiles have ACCEPT_KEYWORDS="~arch" right?
2014-03-26 20:20:29	@Pinkbyte	Zero_Chaos, yep
2014-03-26 20:20:42	@TomWij	Pinkbyte: Right, I perceived this issue to be about exp only; and the other part, as said above, handled by Council.
2014-03-26 20:20:54	@ulm	Zero_Chaos: is it enough to have ~arch?
2014-03-26 20:20:55	@WilliamH	Zero_Chaos: vapier's point was we shouldn't do that but bump the profiles to exp status in profiles.desc
2014-03-26 20:21:03	@zlogene	Zero_Chaos: ACCEPT_KEYWIRDS="arch ~arch"
2014-03-26 20:21:06	@ulm	Zero_Chaos: for repoman -d not to complain?
2014-03-26 20:21:08	@zlogene	*KEYWORDS
2014-03-26 20:21:10	@Zero_Chaos	then in my head it's masturbation. If you are stabilizing on an arch which lists ACCEPT_KEYWORDS="~arch" then the users will always get ~arch anyway so who cares?
2014-03-26 20:21:41	@Pinkbyte	Zero_Chaos, well, vapier keeps some machines with overrided ACCEPT_KEYWORDS
2014-03-26 20:21:56	@Zero_Chaos	ulm: the council said those arches were not stable, so in my head, it's enough that the profiles list ~arch and that we don't wait on them to stabilize.
2014-03-26 20:22:01	@Pinkbyte	Zero_Chaos, ACCEPT_KEYWORDS="-~s390 s390"
2014-03-26 20:22:14	@Pinkbyte	that's how he do things :-)
2014-03-26 20:22:15	@WilliamH	I tend to agree that the status of theprofile should be switched instead of fooling with accept_keywords.
2014-03-26 20:22:15	@Zero_Chaos	Pinkbyte: that is his choice, and it doesn't affect anyone else in any way.
2014-03-26 20:22:41	@TomWij	Pinkbyte: If he's still doing it on dev profiles after 20130917 council decision (per https://bugs.gentoo.org/show_bug.cgi?id=304133#c21) then I think we can enforce the policy here; but, I'm in doubt whether this is to be considered part of this agenda item.
2014-03-26 20:22:50	@Pinkbyte	WilliamH, then - let's do this
2014-03-26 20:22:52	@Zero_Chaos	WilliamH: making the profile exp instead of dev or stable means that there will be much more inadvertant breakage which we can avoid.
2014-03-26 20:23:21	@Tommy[D]	Who about moving those testing-only arches per council decision to exp profile status or, if preferred, ask council for such decision?
2014-03-26 20:23:25	@Tommy[D]	*how about
2014-03-26 20:23:27	@Pinkbyte	Zero_Chaos, we are talking about arches, that basically have only vapier in arch team
2014-03-26 20:23:32	@Pinkbyte	so, it depends...
2014-03-26 20:23:45	@Zero_Chaos	Pinkbyte: we are here to fight for the users, not to battle vapier for fun.
2014-03-26 20:23:55	@Zero_Chaos	Pinkbyte: I don't care what vapier does if it doesn't affect the users.
2014-03-26 20:23:59	@creffett|irssi	so the choices as I see them are "do nothing" "mark exp ourselves" "punt to council"
2014-03-26 20:24:01	@WilliamH	Zero_Chaos: it also ties in with being able to remove old versions.
2014-03-26 20:24:03	@creffett|irssi	did I miss anything?
2014-03-26 20:24:30	dilfridge	about the arches
2014-03-26 20:24:33	@Zero_Chaos	WilliamH: we don't have to respect his stable keywords since council said those arches do not have stable keywords. so again, who cares.
2014-03-26 20:24:36	 *	WilliamH votes punt to council
2014-03-26 20:24:36	@zlogene	i'm interested why vapier still stabilize it
2014-03-26 20:24:47	@creffett|irssi	dilfridge: go ahead
2014-03-26 20:24:49	dilfridge	we had a council decision that all these arches should go exp (suggested by vapier)
2014-03-26 20:24:56	@Zero_Chaos	punting to council is worthless, they haven't enforced anything for years and won't
2014-03-26 20:24:58	@zlogene	make it sense ? If profile have arch ~arch? 
2014-03-26 20:24:58	@Pinkbyte	Zero_Chaos, it's a question of support. If only vapier cares about them, then we can not enforce decision that he does not like
2014-03-26 20:24:59	@Tommy[D]	creffett|irssi: additionally would be "force testing keywords, drop stable keywords again"
2014-03-26 20:25:06	@Zero_Chaos	we either make a choice ourselves or stop pretending we care.
2014-03-26 20:25:06	dilfridge	nah, 
2014-03-26 20:25:26	dilfridge	the agreement was "all these arches become exp profiles, and noone cares about the stable or not keywords"
2014-03-26 20:25:27	@TomWij	creffett|irssi: It depends on what we consider to be the agenda item: If it's just 'experimental' as listed on the wiki, the choices are limited; if we include 'dev' in that, additional choices come in.
2014-03-26 20:25:33	@Pinkbyte	zlogene, as i said - he maintains his own machines with some like of 'stable' branch
2014-03-26 20:25:34	@WilliamH	wait hold on a second all
2014-03-26 20:25:38	@ulm	dilfridge: right
2014-03-26 20:25:43	@creffett|irssi	Zero_Chaos: what, and you think they'll listen to us? out of the existing decisions we've made, which have actually been listened to?
2014-03-26 20:25:49	@ulm	so we should simply mark them as exp
2014-03-26 20:26:00	@Zero_Chaos	creffett|irssi: nut up man. they can't throw us all out ;-)
2014-03-26 20:26:18	@WilliamH	dilfridge: ok, we had a council decision that the arch's should go exp... we just flip that switch and don't care otherwise...
2014-03-26 20:26:27	@Tommy[D]	dilfridge: have a summay link containing that agreement?
2014-03-26 20:26:45	@Zero_Chaos	again, things are black and white to me. If the profiles are correct and he isn't affecting the users he can stabilize whatever he wants. I'm here to protect users not battle for good form.
2014-03-26 20:26:47	dilfridge	vapier uses the stable keywords for e.g. stage building, and imho as long as they are not annoucned anywhere and the profiles default to ACCEPT_KEYWORDS="arch ~arch", who cares
2014-03-26 20:27:02	@Zero_Chaos	dilfridge: ++
2014-03-26 20:27:11	@WilliamH	bump the profiles to exp and we're done with this item. ;-)
2014-03-26 20:27:14	@Zero_Chaos	this doesn't affect us. this doesn't affect users. I say vote.
2014-03-26 20:27:25	dilfridge	Tommy[D]: I think that's one of the summaries that donnie still has to make
2014-03-26 20:27:26	@Pinkbyte	Zero_Chaos, the key point ' if the profiles are correct'. They are marked 'dev' right now, but it does not reflect the reality.
2014-03-26 20:27:33	@Pinkbyte	let's vote
2014-03-26 20:27:37	@Zero_Chaos	Pinkbyte: dev is fine with me.
2014-03-26 20:27:38	@creffett|irssi	dilfridge: to clarify, the profiles _should_ be marked exp?
2014-03-26 20:27:45	dilfridge	will be marked exp
2014-03-26 20:27:47	@WilliamH	There's nothing to vote on since council made the decision.
2014-03-26 20:27:54	@Zero_Chaos	creffett|irssi: let's try a vote and see where it lands....
2014-03-26 20:27:55	dilfridge	exactly.
2014-03-26 20:27:56	@Tommy[D]	i vote for setting those profiles to exp, allowing everyone to drop stable keywords, let vapier do his keywording and noone gets repoman warnings
2014-03-26 20:28:19	@Zero_Chaos	Tommy[D]: are there repoman warnings now?
2014-03-26 20:28:33	dilfridge	I'm still busy with bumping the whole profile tree to eapi=5, otherwise I'd possbly have done it in the meantime
2014-03-26 20:28:34	@Tommy[D]	Zero_Chaos: should be for dev profiles with repoman -d
2014-03-26 20:28:49	@Zero_Chaos	Tommy[D]: I know how to scan thanks, I said, "Are there warnings now"?
2014-03-26 20:28:49	@zlogene	Tommy[D]: heh, even we'll drop stable keywords vapier will revert us 
2014-03-26 20:28:53	@WilliamH	all the council already made the decision on this ;-)
2014-03-26 20:29:05	@creffett|irssi	I vote EDONTCARE, the profiles are set to be marked exp so nothing to do.
2014-03-26 20:29:15	@Zero_Chaos	creffett|irssi: who is marking them exp?
2014-03-26 20:29:22	@Zero_Chaos	creffett|irssi: and on what authority?
2014-03-26 20:29:24	dilfridge	in case of doubt me 
2014-03-26 20:29:34	dilfridge	on council decision authority
2014-03-26 20:29:35	@creffett|irssi	Zero_Chaos: sounded like dilfridge either is planninng on it or knows who will be, and on council authority
2014-03-26 20:29:38	@WilliamH	Zero_Chaos: the authority of council
2014-03-26 20:29:40	@TomWij	creffett|irssi: +1 For the original 'experimental' agenda item, my vote is "don't care"; for the 'dev' discussion as above, my vote is "enforce what council decided or let council enforce it if they wish to do so" (which boils down to "don't care" unless council wants us to enforce).
2014-03-26 20:29:48	@WilliamH	Zero_Chaos: as already said
2014-03-26 20:29:48	@ulm	dilfridge: please do
2014-03-26 20:29:53	@Tommy[D]	zlogene: i mean, if we remove an old version (last stable version on that arch), we dont have to wait for that arch and he is free to stable a newer version
2014-03-26 20:29:57	@Pinkbyte	TomWij, +1
2014-03-26 20:30:03	dilfridge	soon... (we have dpg meeting next week... argh...)
2014-03-26 20:30:09	@Zero_Chaos	if the council already said that is what's happening then I'd like to raise creffett|irssi's EDONTCARE with a EWHYAREWEEVENTALKINGABOUTTHIS
2014-03-26 20:30:22	dilfridge	hehe
2014-03-26 20:30:26	@ulm	dilfridge: it's just profiles.desc?
2014-03-26 20:30:29	dilfridge	yes
2014-03-26 20:30:41	@Pinkbyte	Zero_Chaos, as Tommy[D] said - those 'stable' things on sh/s390/m68k slows closing bugs dramatically
2014-03-26 20:30:44	@Pinkbyte	even security ones
2014-03-26 20:30:53	@Zero_Chaos	dilfridge: is there a way to make repoman scan experimental profiles?
2014-03-26 20:30:56	dilfridge	yes
2014-03-26 20:30:57	@ulm	dilfridge: m68k s390 sh?
2014-03-26 20:31:00	@creffett|irssi	Zero_Chaos: repoman -e iirc
2014-03-26 20:31:05	@Zero_Chaos	then yeah, this is super closed for me.
2014-03-26 20:31:07	dilfridge	ulm: yes but better check
2014-03-26 20:31:13	@creffett|irssi	okay, glad we all agree.
2014-03-26 20:31:15	@creffett|irssi	next topic.
2014-03-26 20:31:40	@Zero_Chaos	dilfridge: thanks for the input.
2014-03-26 20:31:41	@creffett|irssi	Zero_Chaos: you're on, issues with dropping-last-stable policy and what you want us to do
2014-03-26 20:32:03	 *	ulm reading council log
2014-03-26 20:32:06	@Zero_Chaos	I sent a short mail in response to TommyD, but I can summarize here
2014-03-26 20:32:23	@zlogene	Zero_Chaos: please do it 
2014-03-26 20:32:36	@Zero_Chaos	Dropping a keyword from a package, stable or otherwise, will NOT prevent any issues since the user will still have the package installed.
2014-03-26 20:32:38	@Tommy[D]	based on the input from the mail, i suggest the following addition: "if there is no urgency (like security bugs), the developer should follow the policy for removing a package when removing the last stable version or stable keyword from a package"
2014-03-26 20:32:52	@Zero_Chaos	Moreover, the user gets no warning of the issue and still reports bugs, etc.
2014-03-26 20:32:56	@TomWij	(For reference, https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Dropping_Stable_KEYWORDs)
2014-03-26 20:33:24	@Zero_Chaos	So I say, follow the package removal policies (since we are removing the package for a given arch) and use the normal masking practice.
2014-03-26 20:33:43	@Zero_Chaos	simply removing keywords *will* cause more issues, not make them go away
2014-03-26 20:34:04	@creffett|irssi	concern: masking drops visibility even lower than dropping to ~
2014-03-26 20:34:16	@Zero_Chaos	masking properly, listing a bug, it might get fixed, or it might get keyword removed, either way, it will stop us from getting bug reports, etc, and the users won't be caught be surprise.
2014-03-26 20:34:59	@Tommy[D]	creffett|irssi: masking will show a warning to users including the mask message, so he has additional 30 days to react / adjust himself to the situation, so that sounds fine with me
2014-03-26 20:35:03	@ulm	m68k/s390/sh dropped to exp
2014-03-26 20:35:12	@Zero_Chaos	creffett|irssi: if a user of a stable system has foobar-1.2 installed and we remove stable keywords from it, the result is invisible if we do not mask it.
2014-03-26 20:36:00	@Zero_Chaos	creffett|irssi: and since this would only happen in the case of extreme situations like security bugs etc, I think the mask will be needed either way.
2014-03-26 20:36:02	@ulm	dilfridge: we really should have timely council summaries
2014-03-26 20:36:04	@TomWij	creffett|irssi: Maybe we need package.stable.mask; though, I think the goal was removal of the ebuild, so package.mask may just work as well and therefore the increased drop in visibility a mask brings is not of concern.
2014-03-26 20:36:05	@WilliamH	If we are going to mask, I would say s/0/60/ for when the policy can start happening.
2014-03-26 20:36:14	@creffett|irssi	Zero_Chaos: good enough for me
2014-03-26 20:36:16	@WilliamH	s/90/60/
2014-03-26 20:36:47	@WilliamH	hrm maybe package.stable.mask...
2014-03-26 20:36:53	@Tommy[D]	WilliamH: i see no point for that, but no real feelings against it either
2014-03-26 20:36:54	@Zero_Chaos	TomWij: I believe package.mask is better, since some users run mixed systems
2014-03-26 20:37:05	@creffett|irssi	Zero_Chaos: did you like Tommy[D]'s suggested wording, or do you have a different preferred way to amend the policy
2014-03-26 20:37:07	@Pinkbyte	WilliamH, no-no-no, please do not
2014-03-26 20:37:11	@Pinkbyte	package.mask
2014-03-26 20:37:52	 *	WilliamH reads again
2014-03-26 20:37:59	@Zero_Chaos	creffett|irssi: I don't like his wording, even if there is urgency an entry in package.mask doesn't take much time.
2014-03-26 20:38:02	@Pinkbyte	not package.stable.mask
2014-03-26 20:38:49	@creffett|irssi	Zero_Chaos: then please suggest a wording to vote on
2014-03-26 20:38:53	@TomWij	Zero_Chaos: So, if I understand it right, your suggestion is like replacing "The maintainer may drop ..." by something (we can decide on exact wording) like "The maintainer may mask (to inform the user) and then after 30 days drop ..."?
2014-03-26 20:38:54	@Zero_Chaos	Tommy[D]: can you give an example for something so critical you must remove keywords now instead of adding a package.mask? the effect is the same imho.
2014-03-26 20:38:59	@Tommy[D]	Zero_Chaos: i dont mind a package.mask entry, but for security reasons i would prefer removing that version as fast as possible, especially since it has been around for at least 90 days
2014-03-26 20:39:31	@Zero_Chaos	Tommy[D]: masked is masked though, and you can already remove all other keywords once those arches have newer versions stabilized.
2014-03-26 20:39:46	@Tommy[D]	Zero_Chaos: i dont talk about removing stable keyword in this context, but removing an outdated version, which is last stable version for an unresponsive arch
2014-03-26 20:39:48	@TomWij	Pinkbyte: Yeah, no need for package.stable.mask until there is a real need for that; package.mask suffices after thinking it through.
2014-03-26 20:39:51	@Zero_Chaos	creffett|irssi: one more min to discuss with Tommy[D] 
2014-03-26 20:39:53	@creffett|irssi	Tommy[D]: security team has no issue with masking before removal when absolutely necessary
2014-03-26 20:39:56	@creffett|irssi	Zero_Chaos: certainly
2014-03-26 20:40:04	@Pinkbyte	Tommy[D], some core packages i(and base-system) prefer to see masked, rather then removed immediately
2014-03-26 20:40:22	@Zero_Chaos	Tommy[D]: certainly if the vulnerable version only has keywords for one arch, and it's masked on that arch, the user is protected enough?
2014-03-26 20:40:33	@Pinkbyte	Zero_Chaos, definitely
2014-03-26 20:40:36	@Zero_Chaos	Tommy[D]: removing the ebuild won't help the user any further, will it?
2014-03-26 20:40:45	@Pinkbyte	if user unmasks package, than - he knows what he is doing
2014-03-26 20:40:59	@Pinkbyte	and he reads mask message
2014-03-26 20:41:01	@Zero_Chaos	"the developer should follow the policy for removing a package  when removing the last stable version or stable keyword from a package"
2014-03-26 20:41:09	@Zero_Chaos	creffett|irssi: ^^
2014-03-26 20:41:11	@Tommy[D]	What is the point in keeping a vulnerable package around? Removal wont affect those, that have it installed and for those installing newly, they should not even think about installing a vulnerable version
2014-03-26 20:41:12	@TomWij	Tommy[D]: I think security migration is faster dealt with by the user if they get a mask message explaining the reason (or pointing to a GLSA) than when it is masked by missing keyword.
2014-03-26 20:41:40	@Zero_Chaos	Tommy[D]: removing a package affects dep calculation with things like dynamic deps, it's a critical issue honestly.
2014-03-26 20:41:42	@WilliamH	Hmm,
2014-03-26 20:42:00	@Tommy[D]	TomWij: as i said: i dont mind an additional mask entry, but see no reason to keep an outdated and vulnerable version around
2014-03-26 20:42:01	@TomWij	Zero_Chaos: That's vague to me, if that's taken literal it would mean a lastrite message; can we avoid like-the-package-removal constructs?
2014-03-26 20:42:01	@Pinkbyte	Tommy[D], look at glibc. Old versions are preserved for some exotic software that breaks with newer glibc(yeah, that shit happens, blame code monkeys that wrote proprietary software)
2014-03-26 20:42:10	@WilliamH	Wouldn't developers be touching profiles/<arch>/package.mask in this case though?
2014-03-26 20:42:16	@Zero_Chaos	WilliamH: yes
2014-03-26 20:42:21	@Zero_Chaos	WilliamH: and I see no issue with that.
2014-03-26 20:42:24	@Pinkbyte	Tommy[D], and base-system guys are strongly against removing glibc ebuilds
2014-03-26 20:42:37	@WilliamH	current policy doesn't allow that; you have to get an arch team member to do it iirc.
2014-03-26 20:42:40	@Zero_Chaos	TomWij: agreed, I think we can safely drop that part...
2014-03-26 20:42:59	@creffett|irssi	WilliamH: but at this point the arch team has been unresponsive
2014-03-26 20:43:04	@Zero_Chaos	WilliamH: our policy is above arch team policy, they will like our improvements.
2014-03-26 20:43:08	@Tommy[D]	Pinkbyte: any existing glibc ebuild has a security issue?
2014-03-26 20:43:08	@zlogene	Pinkbyte: and against bash removing too
2014-03-26 20:43:09	@creffett|irssi	which is why we're dropping last stable in the first place.
2014-03-26 20:43:15	@creffett|irssi	Tommy[D]: several, actually
2014-03-26 20:43:26	@Pinkbyte	Tommy[D], all <2.17 - yes
2014-03-26 20:44:00	@Zero_Chaos	"The developer should follow the policy for removing a package, except for last rites emails,  when removing the last stable version or stable keyword from a package."
2014-03-26 20:44:01	@Tommy[D]	for masking: masking in base profile(s) should be enough, any need to do it in specific arch profiles?
2014-03-26 20:44:07	@TomWij	Zero_Chaos: Think you missed it, but I asked earlier whether you meant something like "The maintainer may mask (to inform the user) and then after 30 days drop ..." (instead of "The maintainer may drop ..."), does that miss anything?
2014-03-26 20:44:55	@Zero_Chaos	TomWij: I was trying to not be so wordy, the official removal policy includes a bit more like closing bugzie entries, etc.
2014-03-26 20:45:29	@Zero_Chaos	Tommy[D]: depends if we determine multiple arches slacker at different times. I see no reason why we would so profiles/package.mask should be enough.
2014-03-26 20:45:40	@TomWij	Zero_Chaos: Hmm, okay, without last rites that seems to make sense; I think the reader is smart enough to s/package/ebuild/ for the rest of it.
2014-03-26 20:45:52	@WilliamH	Tommy[D]: let me think about that...
2014-03-26 20:45:54	@Zero_Chaos	TomWij: I sure hope so :-)
2014-03-26 20:45:57	@TomWij	Zero_Chaos: So, if I understand correctly; to fit it in with the current policy, that would be added as a sentence to the end?
2014-03-26 20:46:04	@Zero_Chaos	TomWij: yes
2014-03-26 20:46:17	@Zero_Chaos	creffett|irssi: "The developer should follow the policy for removing a package, except for last rites emails,  when removing the last stable version or stable keyword from a package."
2014-03-26 20:46:26	@creffett|irssi	all right.
2014-03-26 20:46:32	@Zero_Chaos	creffett|irssi: I believe we can vote on adding this wording to the end and removing the contest on the page.
2014-03-26 20:46:36	@creffett|irssi	yes
2014-03-26 20:46:39	@Tommy[D]	looks ok to me as an addition
2014-03-26 20:46:44	@Zero_Chaos	Tommy[D]: yessir.
2014-03-26 20:46:48	@creffett|irssi	@all: please vote on Zero_Chaos's amendment
2014-03-26 20:46:49	 *	creffett|irssi yes
2014-03-26 20:46:52	@TomWij	(That goes behind the original "The maintainer may drop stable keyword or last stable version, if arch team does not respond within 90 days; if it breaks the dependency tree, then the maintainer has to work with maintainers of depending packages before dropping keyword/last stable version.")
2014-03-26 20:46:52	 *	Zero_Chaos is obviously in favor
2014-03-26 20:47:14	@TomWij	+1 on Zero_Chaos amendment.
2014-03-26 20:47:17	 *	Pinkbyte votes 'yes'
2014-03-26 20:47:17	 *	ulm yes
2014-03-26 20:47:23	 *	zlogene yes 
2014-03-26 20:47:23	 *	WilliamH yes
2014-03-26 20:47:47	@Zero_Chaos	woohoo. thanks for the patience guys, I've been very underwater.
2014-03-26 20:48:02	@creffett|irssi	Zero_Chaos: amend the page at your convenience
2014-03-26 20:48:09	@Zero_Chaos	creffett|irssi: immediately your highness
2014-03-26 20:48:23	@creffett|irssi	next item on the agenda is the gtk email; WilliamH just sent out a draft email, any feedback on that?
2014-03-26 20:48:49	@Tommy[D]	didnt read it yet, i suggest we discuss that mail via mail
2014-03-26 20:48:59	@Tommy[D]	(if there is discussion needed)
2014-03-26 20:49:10	 *	creffett|irssi shrugs
2014-03-26 20:49:15	@creffett|irssi	any objections to mail discussion?
2014-03-26 20:49:35	@WilliamH	creffett|irssi: I was a little confused on your last point, I think I got it right though.
2014-03-26 20:49:37	@Zero_Chaos	not I
2014-03-26 20:49:41	@zlogene	no
2014-03-26 20:49:57	@WilliamH	no objections here either.
2014-03-26 20:50:17	@creffett|irssi	good enough for me
2014-03-26 20:50:20	@TomWij	No objections to do discussion on mail, too long to stall meeting.
2014-03-26 20:50:34	@Pinkbyte	creffett|irssi, fine by me. I have read email and see no problems with it. It describes the whole problem and our actions pretty well
2014-03-26 20:50:56	@ulm	e-mail draft looks good to me
2014-03-26 20:50:58	@creffett|irssi	next up: getting other people to help out
2014-03-26 20:51:01	 *	zlogene reads now 
2014-03-26 20:51:17	@creffett|irssi	the general idea here is a) we're not doing so well in the PR department and b) there are a lot of small issues that could be tackled
2014-03-26 20:51:43	@Zero_Chaos	creffett|irssi: page updated.
2014-03-26 20:51:57	@creffett|irssi	(fixing maintainer-needed bugs, fixing bitrotting bugs that never got a patch applied, hunting some of the existing QA issues like ignored CFLAGS, etc.)
2014-03-26 20:52:17	@Tommy[D]	for a): unless you want to pay some PR agency, probably not much we can do about it :)
2014-03-26 20:52:46	@creffett|irssi	Tommy[D]: well, we could try to stop making decisions that piss off a quarter of the dev community each
2014-03-26 20:52:50	@TomWij	creffett|irssi: Well, I think that overall this boils down to needing more manpower in Gentoo.
2014-03-26 20:52:59	@creffett|irssi	but then we're doing less useful stuff
2014-03-26 20:53:03	@Pinkbyte	and about maintainer-needed... well, they are 'maintainer needed' - everybody can touch them. If nobody did - what we can do? :-)
2014-03-26 20:53:19	@Tommy[D]	the only idea for the small things: a page within QA wiki listing the things any dev could do and maybe seperated, what a user could do to help
2014-03-26 20:53:35	@Pinkbyte	creffett|irssi, the problem is that we do not have easy problems
2014-03-26 20:53:38	@creffett|irssi	Pinkbyte: yes, but nobody does.
2014-03-26 20:53:39	@TomWij	So, (b) is non-QA, unless we, as QA team, want to work on getting more contributors, perhaps QA contributors.
2014-03-26 20:53:42	@creffett|irssi	Pinkbyte: indeed.
2014-03-26 20:53:47	@WilliamH	creffett|irssi: about pissing people off, I don't think we are going to win that battle...
2014-03-26 20:53:52	@Pinkbyte	and serious problems when solved usually hurt somebody
2014-03-26 20:53:54	@creffett|irssi	TomWij: QA contributors would be nice
2014-03-26 20:53:57	@Tommy[D]	creffett|irssi: well, still better then to piss 3 quarter of the dev community :D
2014-03-26 20:54:07	@TomWij	But given a lot of developers are overworked, I don't see us convincing them; it's already a surprise we have ~10 people in the QA team.
2014-03-26 20:54:09	@WilliamH	creffett|irssi: no matter what we do someone is going to be upset.
2014-03-26 20:54:15	@creffett|irssi	WilliamH: correct!
2014-03-26 20:54:39	@TomWij	Hmm ... is it possible to crowd source QA efforts?
2014-03-26 20:54:56	@TomWij	Like not to Gentoo Developers, but extend it to users.
2014-03-26 20:54:58	@creffett|irssi	TomWij: entirely possible, get a few trusted users to bug hunt
2014-03-26 20:55:36	@creffett|irssi	anyway, not expecting results this meeting, just want to get people thinking
2014-03-26 20:55:38	@Tommy[D]	as i said: only option i see is some page listing the simple and open work seperated for devs and users and announcing that page, so that anyone with some free time and willing can open that page and fix some of those things
2014-03-26 20:55:49	@TomWij	The last few bug days (and to small extent bug cleaners project) don't reveal much interest; outside of that, we've got some regulars doing things here and there.
2014-03-26 20:56:11	@Zero_Chaos	I apologize, I have a flight to catch. I also have no ideas how to get us better PR or more help, so see you all later ;-)
2014-03-26 20:56:18	@creffett|irssi	Zero_Chaos: see ya
2014-03-26 20:56:25	@Tommy[D]	see you zero
2014-03-26 20:57:08	@creffett|irssi	actually, I have to run in a few too, so one thing I had to bring up: Pinkbyte, since you were running the multislot issue, would you mind filing bugs against toolchain to give them a friendly reminder?
2014-03-26 20:57:08	@Pinkbyte	Zero_Chaos, ciao
2014-03-26 20:57:10	 *	antarus mutters something abuot more automation
2014-03-26 20:57:10	antarus	;p
2014-03-26 20:57:33	@WilliamH	antarus: heh
2014-03-26 20:57:43	ssuominen	TomWij: system wide use of lto is not supported yet in sense that the toolchain maintainers know it to be broken and not ready for gentoo-x86
2014-03-26 20:57:53	@Tommy[D]	antarus: do it :p
2014-03-26 20:58:05	@Pinkbyte	creffett|irssi, sure. There quite a few of them, i will dig the entire tree, maybe i missed some of them and file apropriate bugs
2014-03-26 20:58:26	@TomWij	creffett|irssi: ^ Tinderbox was also on the agenda; not sure how, but it was skipped; unless we decided out of the meeting to not meet about that, I think it boils down to needing the hardware to do it (and someone to get it automated)?
2014-03-26 20:58:33	ssuominen	TomWij: lto in compiler is just fine but the rest of portage (ie. packages) are not :/
2014-03-26 20:58:37	@creffett|irssi	Pinkbyte: just need three--glibc, gcc, and binutils(?) iirc
2014-03-26 20:58:40	@creffett|irssi	TomWij: whoops
2014-03-26 20:58:54	@creffett|irssi	that one boils down to "no hardware"
2014-03-26 20:59:00	antarus	Tommy[D]: less is more!
2014-03-26 20:59:11	@creffett|irssi	so unless someone plans to give us hardware in the near future, CANTFIX
2014-03-26 20:59:26	@Pinkbyte	creffett|irssi, well, maybe i can
2014-03-26 20:59:27	@Pinkbyte	)))
2014-03-26 20:59:32	ssuominen	TomWij: plus the user has other flags that simply generate invalid code (like -ftree-vectorize for sys-libs/zlib, just to name one example)
2014-03-26 20:59:33	antarus	I have 12 cores and 32GB of ram
2014-03-26 20:59:36	antarus	thats about it
2014-03-26 20:59:45	ssuominen	TomWij: -fweb breaks x264, at least
2014-03-26 20:59:59	ssuominen	TomWij: just treat him as -O3 user :PP
2014-03-26 21:00:00	@TomWij	Better PR can boils down to 1) make sure we take everyone into consideration and 2) making clear we revisit our choices if needed.
2014-03-26 21:00:16	@TomWij	It's not like if we say "tomorrow the tree is pink" that it'll be pink tomorrow. :D
2014-03-26 21:00:17	@Pinkbyte	but it would be VM, 4 cores, 16Gb of RAM
2014-03-26 21:00:31	@creffett|irssi	Pinkbyte: if you want to look into it, feel free :P
2014-03-26 21:01:01	@Pinkbyte	creffett|irssi, well, i can donate resources(that's not the problem). Setting up tinderbox is a different issue
2014-03-26 21:01:04	antarus	if you can design your workloads for the cloud
2014-03-26 21:01:10	@Pinkbyte	even with flameeyes scripts...
2014-03-26 21:01:10	antarus	we have space at rackspace
2014-03-26 21:01:19	antarus	but we pay by the hour
2014-03-26 21:01:26	antarus	and running a big vm 24/7 will eat the budget
2014-03-26 21:01:39	 *	creffett|irssi out
2014-03-26 21:01:44	antarus	so you have to do stuff like 'turn vm on, start job, write output to storage, turn vm off'
2014-03-26 21:01:47	antarus	so you are not paying for idle hours
2014-03-26 21:01:52	@wired	hey :p
2014-03-26 21:02:14	@Tommy[D]	wired: that was the last word of the meeting :p
2014-03-26 21:02:29	@wired	heheh
2014-03-26 21:02:35	@wired	meh, sorry
2014-03-26 21:02:55	@WilliamH	wired: lol
2014-03-26 21:03:09	@zlogene	wired, too late:p but hi there :p
2014-03-26 21:03:24	@TomWij	Did someone want to open floor something?
2014-03-26 21:03:26	@Tommy[D]	so summary for the "get more people to work": no fixed content to decide on, feel free to add content via mail on the alias
2014-03-26 21:04:11	@Tommy[D]	summary for the "QA tinderbox": we need the hardware, a concept to use it and someone doing the work for it, so until we got those donated, nothing to vote/discuss on
2014-03-26 21:04:27	antarus	I think you have a fairly annoying catch-22 there
2014-03-26 21:05:06	@Tommy[D]	no openfloor content from me
2014-03-26 21:05:07	@TomWij	Tommy[D]: "get more people to work" I think making things more accessible (a list of all QA work users can help with, and not just autorepoman) is one way to do it; the other I agree.
2014-03-26 21:05:36	@Pinkbyte	Tommy[D], as i said - i can give resources
2014-03-26 21:05:54	@Pinkbyte	but about other things - no idea
2014-03-26 21:06:16	@Tommy[D]	TomWij: as i said: we could look into creating a page listing possible work specific groups (devs/users) can do, beside that we currently dont have anything specific
2014-03-26 21:07:09	@TomWij	Tommy[D]: Yeah, even for ourselves I think it can help; for example, I have a search that does something like:
2014-03-26 21:07:12	@TomWij	Resolution: --- Keywords: (contains none of the words) Tracker Assignee: qa@gentoo.org Severity: QA CC: qa@gentoo.org
2014-03-26 21:07:39	@TomWij	(The Keywords is wrong, it checks for QA.)
2014-03-26 21:08:22	@Tommy[D]	Pinkbyte: i suggest you write that via mail to the alias, so we have a starting point for our further discussion/planning
2014-03-26 21:08:31	@TomWij	The idea being that {assignee,cc}:qa@gentoo.org alone doesn't suffice; there's like a lot where severities get said to QA or something QA is put in another field or so (eg. QAcanfix).
2014-03-26 21:09:23	 *	TomWij gets scared thinking about the amount of QA bugs that have none of these bug parameters indicate that it is a QA bug.
2014-03-26 21:10:41	@Tommy[D]	dont think too much about it, just gets you less/grey hair quicker :)
2014-03-26 21:10:58	@TomWij	Does someone know when the first QA team was formed?
2014-03-26 21:10:59	@Tommy[D]	as there is no new input, i suggest, we close the meeting for today
2014-03-26 21:11:33	@TomWij	Tommy[D]: +1
2014-03-26 21:11:47	@TomWij	Just for fun, I'm even thinking there might even still be QA bugs lingering around from before that time.
2014-03-26 21:12:13	@Pinkbyte	TomWij, try not to thing about unreported QA bugs too ;-)
2014-03-26 21:13:00	@Tommy[D]	so i assume meeting closed, have a good evening everyone
2014-03-26 21:13:15	 *	TomWij feels that his hair changes color.
2014-03-26 21:13:32	@TomWij	good evening
2014-03-26 21:22:34	@creffett|irssi	TomWij: at the rate we're going, I will be gray-haired by the time my term is up