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