QA/Meetings/20130128

From FedoraProject

Jump to: navigation, search

Contents

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

Blocker process revision

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!