QA/Meetings/20130128

Attendees

• tflink (96)
• adamw (82)
• Viking-Ice (75)
• j_dulaney (43)
• nb (21)
• pwhalen (13)
• zodbot (9)
• fenrus02 (9)
• bconoboy (7)
• kparal (5)
• Cerlyn (4)
• mjg59 (2)
• satellit (2)
• masta (2)
• akshayvyas (1)
• moshe742 (1)
• nirik (1)
• drago01 (1)
• BobLfoot (1)
• mkrizek (1)
• satellit_e (1)
• pschindl (1)

Agenda

• Fedora 19 feature list review
• Blocker process revision
• Onboarding
• Criteria revision
• QA:TestCase Definitions in Sync with Features Current State
• ARM as Primary
• Open floor

Fedora 19 feature list review

• See Category:FeatureAnnounced and Releases/19/FeatureList
• Initial list of potential sources for concern for QA:
  1. Features/NewFirstboot
  2. Features/SyslinuxOption
  3. Features/SystemdPredictableNetworkInterfaceNames
  4. Features/YumGroupsAsObjects
  5. Features/FixNetworkNameResolution

Blocker process revision

• Changes to tracker aliases and whiteboard terms were made before the meeting, no concerns raised at the meeting
• tflink working on a blocker bug webapp page for proposing blockers, first cut aimed to be available for Alpha

Onboarding

• Rough plan by adamw to replace proventesters and Bugzappers onboarding with a generic QA onboarding process
• Some debate over whether to resurrect the FAS 'qa' group and put all applicants in it
  • Pros: lets us give people editbugs, FAS membership needed to vote in elections, enter some contests
  • Cons: administrative burden, little of our work really requires a FAS group, elitism?
• Everyone was generally in favour of the main idea of replacing PT/BZ onboarding processes
• adamw to draft up specific changes and provide a detailed pro/con evaluation of using a FAS group

ARM as primary arch(?)

• At FUDCon j_dulaney spoke with the ARM folks about the current QA process
• Trac ticket for ARM to mirror official QA process for F19
• Agreed that ARM should have a set of tracker bugs that mirror the official QA tracker bug layout and names, and use the official process for reviewing blocker/FE bugs (but not the same actual meetings)
• Agreed that we should try to ensure the release criteria are prepared for ARM as primary arch, as part of the revisions for F19 cycle

Criteria revision (tabled to next week due to lack of time)

• We really need to improve criteria presentation for F19

QA:TestCase (tabled to next week due to lack of time)

• Revising of QA:TestCase Definitions during the F18 Final Test Phase was less than optimal - How to avoid with F19?

Open floor

N/A

Action items

N/A

IRC Log

tflink	#startmeeting Fedora QA Meeting	16:01
zodbot	Meeting started Mon Jan 28 16:01:32 2013 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.	16:01
zodbot	Useful Commands: #action #agreed #halp #info #idea #link #topic.	16:01
tflink	#meetingname fedora-qa	16:01
zodbot	The meeting name has been set to 'fedora-qa'	16:01
tflink	#topic Roll Call	16:01
tflink	#chair adamw	16:01
zodbot	Current chairs: adamw tflink	16:01
* Viking-Ice here		16:01
* mkrizek is here		16:01
* satellit listening		16:01
nb	hi	16:01
* Cerlyn is here		16:02
* kparal is out there		16:02
* j_dulaney smash		16:02
tflink	hopefully we'll see an adamw soon :)	16:02
* j_dulaney bets adamw had too much to drink last night		16:02
j_dulaney	Or, is snowed in	16:02
* BobLfoot is logging from dentist chair		16:03
* kparal pokes pschindl		16:03
tflink	BobLfoot: that's impressive	16:03
* pwhalen lurks		16:03
j_dulaney	.moar drills BobLfoot	16:03
zodbot	here BobLfoot, have some more drills	16:03
* tflink waits a few more minutes for people to show up		16:04
* pschindl is here		16:04
Viking-Ice	hmm we seem to have a lot of new people here so who is who?	16:05
* j_dulaney is John Dulaney		16:05
j_dulaney	And I don't think I'm new	16:06
tflink	we do?	16:06
* satellit Tom Gilliard		16:06
moshe742	i am moshe nahmias, one of the new guys	16:06
Viking-Ice	Cerlyn, nb, pwhalen etc..	16:06
* pwhalen is Paul Whalen, from the ARM team		16:06
* nb is Nick Bebout from infra/docs/ambassadors		16:07
Cerlyn	Samuel Greenfeld - OLPC QA (including ARM), SoaS QA, some fedora-easy-karma QA,...	16:07
satellit_e	me My trimslice h250	16:08
* Viking-Ice points out if people where not hiding their real name in their irc client this would not be necessary		16:09
Viking-Ice	let's carry on	16:09
tflink	hiding their real name?	16:11
tflink	either way, agreed. carrying on	16:11
Viking-Ice	tflink, "name unknown" you have not set your name in the irc client you are using	16:11
tflink	Viking-Ice: honestly, I didn't know that was possible	16:12
* tflink will look into that		16:12
Viking-Ice	tflink, yup I actually think that's even an ambassador requirement	16:12
tflink	Anyhow, moving on to the agenda listed at:	16:13
tflink	#link https://fedoraproject.org/wiki/QA/Meetings/20130128	16:13
tflink	#topic Fedora 19 Feature List Review	16:13
tflink	Are there any worry-worthy features currently proposed or accepted for F19?	16:14
tflink	#link https://fedoraproject.org/wiki/Releases/19/FeatureList	16:14
kparal	I don't see anything really worrisome	16:15
tflink	is there a good link for the proposed features?	16:15
tflink	yeah, I don't see anything worry-worthy in the accepted features	16:15
nirik	https://fedoraproject.org/wiki/Category:FeatureAnnounced	16:15
kparal	oh, I'm looking only at accepted ones	16:15
Viking-Ice	Fix Network NameResolution might cause trouble	16:15
tflink	but I don't see a bunch of the ones that are currently being discussed on devel@	16:15
tflink	firstboot is noteworthy	16:16
Viking-Ice	yeah	16:16
tflink	systemd's calendar is another one	16:16
j_dulaney	The only one that could theoretically hit us that I see other than firstboot is Cinnamon, but I don't see that feature getting approved	16:16
tflink	yeah, I doubt that one will get accepted	16:17
j_dulaney	RPM update shouldn't cause any worries	16:17
* tflink hates the 's' word but agrees		16:17
tflink	using syslinux for some of the images might also be something to worry about slightly	16:17
tflink	I doubt that it would cause problems but I don't think that we have any test cases or criteria to cover it	16:18
Viking-Ice	all issues that might fall out from SystemdPredictableNetworkInterfaceNames should have been caught in #682334	16:18
j_dulaney	Might be something to poke at	16:18
Viking-Ice	oh and this "YumGroupsAsObjects"	16:18
Viking-Ice	might break stuff	16:18
j_dulaney	The Fedora Formulas thing will need poking	16:19
Viking-Ice	?	16:19
* j_dulaney was at that talk at FUDCon		16:19
tflink	j_dulaney: true but I'd rather wait until a proposal is made (I don't think that has been done yet)	16:19
j_dulaney	Viking-Ice: The idea is to replace most (all?) spins with Ansible storybooks	16:20
Viking-Ice	yeah well I have yet to see that approved	16:20
Viking-Ice	maybe 20+ feature	16:20
tflink	was it proposed on a more formal level?	16:20
* j_dulaney doesn't know		16:20
tflink	ok, so the list of things that could be a source for concern are:	16:21
tflink	#info an initial list of potential sources for concern for QA are:	16:21
tflink	#link https://fedoraproject.org/wiki/Features/NewFirstboot	16:22
tflink	#link https://fedoraproject.org/wiki/Features/SyslinuxOption	16:22
tflink	#link https://fedoraproject.org/wiki/Features/SystemdCalendarTimers	16:22
tflink	#link https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames	16:22
tflink	#link https://fedoraproject.org/wiki/Features/YumGroupsAsObjects	16:23
tflink	did I miss anything?	16:23
Viking-Ice	where did calendertimers come from ?	16:23
nb	https://fedoraproject.org/wiki/Features/FreeBSD_kernel_integration would cause issues	16:23
nb	(lol jk, i know it was just a joke)	16:24
Viking-Ice	nb it was a poor attempt at humour	16:24
tflink	Viking-Ice: not sure I understand your question	16:24
tflink	are you asking why it might be a source of concern?	16:24
Viking-Ice	tflink, why are you linking to calendertimers	16:24
Viking-Ice	and skipping name resolution	16:25
tflink	Viking-Ice: it seems to me like a feature that could cause problems	16:25
Viking-Ice	calender timers does not cause any breakage	16:25
tflink	isn't it going to replace cron?	16:25
Viking-Ice	tflink, no	16:25
Viking-Ice	maybe 38 scripts will be migrated ( out of 99 ) but thats it	16:25
Viking-Ice	afaik cron will still be shipped	16:26
Cerlyn	https://fedoraproject.org/wiki/Features/SharedSystemCertificates - potentially could cause subtle issues as it consolidates a few CA databases and appears to add something new to manage it	16:26
Viking-Ice	and there is no feature about that migration I'm still looking into the benefit of doing that	16:26
tflink	ok, I misunderstood then	16:27
* tflink hasn't spent a whole lot of time looking at the proposed F19 features yet		16:27
tflink	#undo	16:27
zodbot	Removing item from minutes: <MeetBot.items.Link object at 0x552ff910>	16:27
tflink	#undo	16:27
zodbot	Removing item from minutes: <MeetBot.items.Link object at 0x5115e450>	16:27
tflink	#undo	16:27
zodbot	Removing item from minutes: <MeetBot.items.Link object at 0x55145950>	16:27
tflink	#link https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames	16:27
fenrus02	systemd already has timers feature	16:28
tflink	or is that one something more benign than I'm thinking as well	16:28
Viking-Ice	it kinda does not make sense migrating anything but those cron job that get shipped with daemon/services which are 38	16:28
Viking-Ice	fenrus02, yup had to for quite sometime it just gained calendar times	16:29
tflink	eh, I'll leave it on there - it's probably not a source of concern, though	16:30
tflink	#link https://fedoraproject.org/wiki/Features/YumGroupsAsObjects	16:30
tflink	#link https://fedoraproject.org/wiki/Features/FixNetworkNameResolution	16:30
tflink	anything I'm missing for the notes?	16:30
fenrus02	biosdevname is different than systemdpredictablenetworkinterfacenames .. disconcerting considering how recent biosdevname was.	16:30
Viking-Ice	tflink, I think you have covered them all now ( added those missing and removed the one that does not belong there )	16:31
tflink	I think that only one of those is currently accepted but I expect that to change in the near future	16:32
Viking-Ice	fenrus02, we should not hit anything but its better to keep SystemdPredictableNetworkInterfaceNames on the list since it might cause breakage even thou it's unlikely	16:32
fenrus02	fair	16:32
tflink	I'm not sure that there is much we can do about those for the moment other than to keep an eye on the features and make sure we are prepared	16:33
tflink	any objections to moving on (as we're already 30 minutes in)	16:33
j_dulaney	+1	16:33
Viking-Ice	nope let's move on	16:34
tflink	#topic Blocker Process Revision	16:34
tflink	A lot of these changes have already happened for F19	16:34
tflink	ie, NTH -> FreezeException, changing of tracker bug aliases	16:34
tflink	are there any concerns about the changes that have already been made?	16:35
tflink	IIRC, there was pretty broad support for the idea	16:35
kparal	the aliases are much better now	16:35
Viking-Ice	yeah we finessed it on the -test list	16:36
tflink	#info most of the changes that have already been done are discussed in:	16:37
tflink	#link http://lists.fedoraproject.org/pipermail/test/2013-January/113363.html	16:37
tflink	The other change which should land for F19 is the blocker proposal page	16:37
tflink	#info Another F19 proposed change to the blocker process is the ability to propose blocker/FE bugs through the blocker tracking app	16:38
tflink	#link http://lists.fedoraproject.org/pipermail/test/2013-January/113427.html	16:38
tflink	Are there any concerns about what has been discussed thus far?	16:38
tflink	work is progressing, there have been a few bumps in the road with pending FAS changes and bugzilla API modifications	16:39
tflink	I'm not currently aware of anything which would prevent the feature from being completed in time for F19	16:40
adamw	sorry guys	16:40
adamw	phone crashed overnight. thanks cm9!	16:40
Viking-Ice	yeah I guess now is just to have a working sample and see how it turns out for alpha	16:40
tflink	yeah, I'm planning to get a stg instance set up which points to partner-bugzilla and stg FAS when the code is ready to be poked at	16:41
tflink	AFAIK, the bugzilla and FAS changes should be in production by the time F19 testing starts up	16:41
Viking-Ice	this probably will be a work in progress throughout F19 development cycle and ready for F20 with all the issues we found on the way fixed	16:42
tflink	as far as the longer term changes that are on the agenda and I've alluded to in the past, any objections to skipping that for today? we're already 45 minutes into the meeting and this is something that wouldn't happen until F20 at the earliest	16:42
adamw	no objections	16:43
tflink	Viking-Ice: agreed. I'll be very surprised if we get it perfect the first time around :)	16:43
tflink	adamw: anything else you wanted to cover here?	16:43
adamw	no, it was just a checkin to make sure everyone's happy with the new process	16:43
tflink	any last objections to the proposed/done changes before we move on?	16:44
Viking-Ice	that group stuff is not in those changes right	16:44
tflink	adamw: feel free to take over, I assume you have a better idea of what you wanted to cover during the meeting than I do :)	16:44
tflink	Viking-Ice: correct	16:44
tflink	I associate that with the next topic	16:45
Viking-Ice	yeah well that group stuff is a nono	16:45
adamw	that is indeed the next topic	16:45
adamw	#topic Onboarding	16:45
adamw	so i left this general on purpose as my proposal is pretty vague - just wanted to kick it around a bit	16:45
adamw	the problem is that we have onboarding processes for proventesters and bugzappers, but neither group is really at all active: so we should get rid of those	16:46
adamw	i had the idea of replacing it with a general self-introduction for QA	16:46
Viking-Ice	bringing back groups is a no no it was an administrative hell in the pass, it hindered participation and caused the feel of an elite group within QA	16:46
adamw	also adding new applicants to the 'qa' FAS group, but that part is a tack-on - we could do all the rest without doing that	16:46
Viking-Ice	s/pass/past	16:46
adamw	the admin bureaucracy is a bit of a pain i agree, but the elitism part should be solved if we just put everyone in, right?	16:47
tflink	Viking-Ice: depending on what exactly you're concerned about, I would argue that a QA group is a good thing - testers should be able to qualify for FCL+1	16:47
Viking-Ice	adamw, why have the group if everyone is going to be in it	16:47
Viking-Ice	what are we trying to solve with that group	16:48
tflink	s/FCL/FCA	16:48
adamw	Viking-Ice: there's some stuff you need to be a member of at least one FAS group for	16:48
Viking-Ice	which is	16:48
adamw	voting in elections is one; i think there's others, i'm drawing a blank atm	16:48
nb	adamw, @fp.o email alias	16:48
nb	fedorapeople account	16:48
Viking-Ice	yes and that does not have to be this group	16:49
adamw	oh, right, you get fp.o space and account	16:49
Cerlyn	http://fedoraproject.org/openhw2012/details/ - contents (rule #3)	16:49
tflink	Viking-Ice: the first thing that comes to mind is getting past the cla_done +1 requirement	16:49
adamw	Viking-Ice: well sure, but if all you do in Fedora is QA, what other group are you going to join?	16:49
tflink	now that I've called it a third name :)	16:49
adamw	=)	16:49
nb	Viking-Ice, adamw well, plus how will people get fedorabugs?	16:49
adamw	Cerlyn: hey, good one	16:49
Viking-Ice	for what exactly does our group need cla_done +1 requirement	16:49
Viking-Ice	for?	16:49
nb	although it is possible to sponsor someone into fedorabugs by itself	16:49
tflink	voting requires cla_done +1	16:50
adamw	tflink: i wonder why that is, though	16:50
Viking-Ice	tflink, voting for what in our group	16:50
tflink	er, voting for fedora elections (fesco, board etc.)	16:50
adamw	Viking-Ice: not voting within qa, voting in project-wide elections	16:50
adamw	tflink: seems odd that requires cla_done though	16:50
adamw	we could ask why that is	16:50
nb	afaik board is cla_done, fesco and famsco are cla+1	16:51
nb	although i'm not sure	16:51
adamw	well how about this as a proposal: we can table the group membership part for now and I can come back in a few days with more details on the pros/cons of group membership	16:51
Viking-Ice	adamw, our reporters have not found the need to for that in what 2 - 3 years now or whenever we decided to put that group to rest	16:51
adamw	check in on all the stuff discussed here and see if we can come up with any more	16:51
tflink	nb: you're correct: https://fedoraproject.org/wiki/Elections#Eligible_Voters	16:51
adamw	Viking-Ice: well, because a lot of them are in pt/bugzappers, for one thing :)	16:52
adamw	but anyway, like i said, that part of the proposal snaps right off	16:52
tflink	personally, I would argue that fesco elections, fp.o space and fedorabugs are enough to justify the group membership	16:52
fenrus02	the docs group needs fedorabugs too	16:52
tflink	but we don't have to discuss that today if we're running out of time	16:52
nb	tflink, although FWIW we can give people fedorabugs by itself if we want	16:52
adamw	so can we table it for now and discuss the rest of the proposal? is everyone OK in general with retiring the pt/bz onboarding and having a general qa self-intro thing instead?	16:52
nb	fenrus02, docs-writers grants fedorabugs	16:52
fenrus02	nb, ok	16:52
tflink	nb: in my mind, qa membership might be easier and cleaner	16:53
nb	tflink, i agree	16:53
Viking-Ice	we killed the qa group for a purpose in the apst	16:53
Viking-Ice	past	16:53
adamw	brb, nature calls	16:53
adamw	Viking-Ice: it's not so much that we 'killed it for a purpose', it's that we 'stopped using it because we didn't really see a point'	16:54
adamw	it's not like it was causing major strife	16:54
adamw	if we can see a point to using it again, why not do it?	16:54
Viking-Ice	adamw, did you actually make it in the group or when we had more or less stopped using it	16:54
Viking-Ice	when you got hired	16:54
tflink	Viking-Ice: why is it that testers shouldn't be eligible to vote for fesco or have fp.o space?	16:54
Viking-Ice	tflink, that's a mute point we have not had that group for 2 - 3 years now and somehow they managed	16:55
tflink	I'm not saying that we should have a QA fas group because "only qualified testers should test", just that having it enables onboarding to the project as a whole through QA	16:55
nb	Viking-Ice, by getting triagers or proventesters membership instead	16:55
nb	Viking-Ice, how do you propose new people would get fedorabugs membership in the future?	16:56
tflink	it makes no sense to me to say that "people who want to test have to join other parts of fedora in order to vote for fesco or get fp.o space"	16:56
fenrus02	it would simplify matters to move users from bz + pt over to qa, and have qa grant fedorabugs. wiki pages would be able to cleanup considerably and much less confusion for new folks	16:57
Viking-Ice	and fedorabugs is RH bugzilla limitation right	16:57
Viking-Ice	we need it because of that	16:57
adamw	no, not really	16:57
adamw	editbugs is a standard bugzilla thing	16:57
* tflink has no objection to the general idea, though. would be good to have a clearer onboarding process		16:57
nb	Viking-Ice, well, its what the sync script looks at to decide who to give editbugs on bugzilla	16:57
adamw	individual bugzillas tweak the lines of what's inside editbugs and what's outside it, but there's usually a line there	16:57
Viking-Ice	nb does that sync script grant/reduce privileges from RH employees that are not in that group or do they just get superior privileges by default	16:59
adamw	well i think we pretty much talked that one out...	16:59
nb	Viking-Ice, they get whatever privileges red hat gives them	16:59
nb	the sync script will not reduce those	16:59
Viking-Ice	figures	16:59
nb	the sync script also gives them privileges to set priority and stuff on fedora bugs AFAIK	16:59
nb	which red hat employees don't have by default	16:59
adamw	so do we want to cut this off at an hour and continue with other topics next week?	17:00
Viking-Ice	there is a general agreement I think about killing pt and bugzappers	17:00
Viking-Ice	and what you propose should suffice until something better comes along	17:01
fenrus02	provided folks have somewere to go, sure	17:01
tflink	ARM might be worth discussing briefly	17:01
Viking-Ice	I thought we covered that last release cycle	17:01
adamw	#agreed everyone agrees in principle to retiring BZ and PT onboarding processes for now; adamw to come back with a more detailed proposal including +/- of group membership later	17:02
Viking-Ice	they just follow the same rules as primary arch does now no more no less	17:02
adamw	the ARM thing was added by jdulaney	17:02
adamw	is he here? if not, probably not worth doing it	17:02
* j_dulaney is here		17:02
adamw	hi!	17:02
fenrus02	adamw, you want to change those fas groups to invite-only so folks stop applying?	17:02
adamw	let's hit it then	17:03
akshayvyas	are we going to come up with something else if we retire BZ and PT	17:03
Viking-Ice	those that have arm hw can follow the test cases	17:03
tflink	Viking-Ice: PA stuff, as currently written, would prevent ARM from being PA	17:03
pwhalen	Viking-Ice, some of the release criteria do not make sense on arm, desktops etc. Will the criteria be reviewed again?	17:03
adamw	fenrus02: mainly we should adjust the wiki. but see above discussion and the list :)	17:03
Viking-Ice	yay more criteria revision ;)	17:03
* fenrus02 nods		17:03
adamw	#topic ARM as primary arch(?)	17:03
* j_dulaney has opened a ticket: https://fedorahosted.org/fedora-qa/ticket/336		17:03
adamw	#chair j_dulaney	17:03
zodbot	Current chairs: adamw j_dulaney tflink	17:03
tflink	#link https://fedorahosted.org/fedora-qa/ticket/336	17:03
j_dulaney	#info j_dulaney spoke with pwhalen at FUDCon about the current QA process	17:04
Viking-Ice	pwhalen, which criteria worries you	17:04
adamw	so this is a 'what do we need to do before ARM can be handled as part of our regular release validation?' topic?	17:04
j_dulaney	Indeed	17:04
pwhalen	I'll be going over the release criteria again, as it has been sometime.. we follow a release criteria loosely based on PA	17:04
j_dulaney	I have some concerns over how the arm group currently does things	17:05
adamw	i would especially like this discussion to be in the context of, say, the ARM chromebook	17:05
j_dulaney	But, the way I figure it, starting with F19 arm should follow PA's QA process as closely as possible	17:05
adamw	which seems to raise some issues with the idea that anaconda/desktop criteria might not be applicable to ARM	17:05
pwhalen	the chromebook will be a remix, not all of the kernel bits are upstream	17:06
j_dulaney	The current way to install Fedora on a chromebook is rather convuluted, as I can attest to	17:06
pwhalen	there are a few desktops, but many are headless, server hardware	17:06
Viking-Ice	hmm I thought people where running desktop on arm	17:06
j_dulaney	Not often	17:06
tflink	Viking-Ice: you can but not all the arm systems support DEs	17:07
Viking-Ice	but the installer criteria is out for arm	17:07
bconoboy	chromebook won't receive official support until its kernel bits are upstream	17:07
j_dulaney	Much of the time, the gfx drivers are not in place	17:07
pwhalen	on a select few devices, like the Pandaboard	17:07
* masta looks in		17:07
bconoboy	*Some* of the installer criteria are applicable on ARM: We use anaconda to pxe boot and provision highbank systems. Others are not applicable: There's just an SD card.	17:07
Viking-Ice	mean the anaconda related installer criteria is out for arm and needs to be replaced with that traditional method arm uses for installs	17:07
adamw	so anyhoo...what does "F19 arm should follow PA's QA process as closely as possible" look like in your mind, j_dulaney?	17:07
bconoboy	*Some* of the desktop criteria are applicable on ARM: Panda boards have XFCE/Mate desktops working just fine today, but highbank doesn't even have a video card.	17:08
adamw	it's still a secondary arch, so we can't really share blocker trackers and meetings	17:08
j_dulaney	Well, as was said, some of the criteria are not apllicable	17:08
Viking-Ice	pwhalen, is arm going for PA this release cycle or the next ?	17:08
bconoboy	viking-ice: F20 at the earliest	17:08
* j_dulaney created tracker bugs for F19, althoug they need to be adusted to include the new aliases		17:08
bconoboy	viking-ice: The idea is to do it right during F19 though.	17:08
Viking-Ice	ah then I think we can just skip this until then	17:08
adamw	bconoboy: well, i mean, you can build a headless x86 system too. just because there are _some_ target uses which don't use the desktop, doesn't mean we dump those criteria for x86 :) so if there are some ARM target uses that use the interactive installer and the desktop, maybe we need to keep the criteria.	17:09
adamw	Viking-Ice: well i think the idea is about preparing for f20.	17:09
bconoboy	viking-ice: We can't skip it- ARM needs to start acting like PA before it can *be* a PA	17:09
j_dulaney	I would recomend that Arm folks observe blocker meetings and attend QA meetings	17:09
mjg59	bconoboy: The assumption was that unless there's an absolute reason why the platform can't support Anaconda (eg, it only supports one piece of media) the platform would have to support Anaconda	17:09
pwhalen	j_dulaney, I intend to that for the arm team	17:10
mjg59	bconoboy: But for platforms where Anaconda is entirely inappropriate, there'd be no requirement for it to satisfy any Anaconda-related criteria	17:10
bconoboy	mjg59: Right. Our goal is to start converging on PA's procedures and to redefine PA's procedures when they aren't applicable.	17:10
j_dulaney	For f19, arm ought to follow their agreed upon criteria, and propose blockers and freaze exceptions in the same way we do with the trackers I created	17:11
j_dulaney	Then, when arm hits primary, the difference becomes that they propose against the PA trackers and don't have their own	17:11
adamw	j_dulaney: seems sensible.	17:11
j_dulaney	pwhalen: Could you link to the criteria you've come up with on the Trac ticket?	17:12
j_dulaney	We (as the QA team) can discuss them on their	17:12
j_dulaney	I would also like the ARM folks to also add their discussion on release criteria there	17:12
adamw	worth bearing in mind i'm planning to propose a major overhaul of the criteria presentation, though i haven't got much done on it yet	17:12
j_dulaney	Indeed	17:13
adamw	i'll try and bear in mind flexibility for multiple arches there	17:13
Viking-Ice	I'm not foreseeing that we can start blocking the release on arm devices until there is a consistent installation method and use cases.	17:13
pwhalen	j_dulaney, adding it now	17:13
adamw	Viking-Ice: we're not going to block f19 on arm	17:13
pwhalen	adamw, appreciated	17:13
Viking-Ice	adamw, yes I know	17:13
j_dulaney	Which is why I haven't started drafting up emails for mailing lists just yet; I'm waiting on tracker aliases and criteria to settle, first	17:13
adamw	Viking-Ice: ok	17:13
adamw	so, i think it makes sense for arm to use a parallel blocker process indeed; what else? should we try and have arm review meetings in sync with the primary meetings somehow - shortly after, say?	17:14
adamw	well, that runs into 'epic blocker meeting' syndrome, i guess.	17:14
Viking-Ice	yup	17:14
j_dulaney	adamw: Maybe at weekly qa meetings/	17:14
j_dulaney	Instead of blocker meetings	17:14
adamw	j_dulaney: what at weekly qa meetings?	17:14
Viking-Ice	j_dulaney, qa meetings more often than not turns into blocker bug meeting	17:15
j_dulaney	adamw: Sync up blocker reviews	17:15
tflink	that doesn't sound like a great idea to me, these meetings are long enough as it is, especially when we do mini-reviews	17:15
j_dulaney	True	17:15
j_dulaney	Mailing list, then	17:15
adamw	yeah, i'm negatory on that one too :)	17:15
adamw	so i guess right now we have - use parallel trackers and blocker review process, and try to get the criteria ready for ARM-as-primary	17:16
adamw	is there anything else?	17:16
* j_dulaney can't really think of anything		17:16
j_dulaney	Blocking on process change atm	17:16
adamw	okay	17:16
pwhalen	that sounds like a good start, will likely have questions along the way	17:17
* j_dulaney just wanted to get the ball rolling on discussion		17:17
masta	=)	17:17
adamw	#agreed we should ensure ARM group is using a blocker/FE tracking process exactly in parallel to the official one, and using the same review process (but not the same meetings). we should also keep ARM requirements in minds while revising the criteria and presentation this cycle	17:17
Viking-Ice	with the expection of the installer the criteria should not needed to be changed afaik	17:17
adamw	Viking-Ice: there may be other stuff in there, it's gotten pretty big now.	17:18
Viking-Ice	adamw, we just need to identify what is applicable from the criteria to arm	17:18
pwhalen	there is, it is rather large, but I'll speak more directly to them as I go through it	17:18
adamw	Viking-Ice: to put it very very briefly, one of my ideas for revising the criteria presentation is to make 'constraints' more systematic - separate the actual criterion text from constraints on its application	17:19
adamw	so we'd have standard ones, like 'when doing a graphical install' and 'when installing to storage type XXX' or whatever	17:19
adamw	one of those could be 'when installing to platform foo'	17:19
adamw	still being refined in my head, but you get the idea.	17:20
Viking-Ice	adamw, yeah dont tie it to spesific application thou	17:20
Viking-Ice	as in Anaconda or NetworkManager etc it should be based on function from application ( since thous application might be replaced with something else )	17:20
adamw	sure	17:20
adamw	anyhow, we're pretty over time for today	17:21
adamw	i think we can bench the other topics for next week?	17:21
Viking-Ice	yeah sure	17:21
j_dulaney	+1	17:21
tflink	works for me	17:21
adamw	ok	17:21
adamw	thanks for coming arm folks!	17:21
adamw	let's do a quick:	17:21
adamw	#topic open floor	17:21
adamw	but please just bring anything up if it's urgent and can't wait for next week	17:21
pwhalen	adamw, thanks for having us :)	17:22
adamw	if it can wait, we'll do it then	17:22
nb	I would like to thank tflink and adamw for chairing the meeting	17:22
* adamw really needs to put 'buy a non-android based alarm clock' on his todo list		17:23
drago01	adamw: use gnome-clocks ;)	17:23
Viking-Ice	or simply go earlier to bed...	17:23
* j_dulaney thought adamw was snowed in and now thinks adamw should be fired		17:23
adamw	j_dulaney: it'd have to be some really bad snow to snow me in between the bedroom and my desk :)	17:24
adamw	Viking-Ice: crazy talk!	17:24
adamw	alright, thanks for coming everyone...same time same place next week	17:24
adamw	#endmeeting	17:24

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!