16:00:14 <adamw> #startmeeting Fedora QA meeting
16:00:14 <zodbot> Meeting started Mon Nov 25 16:00:14 2013 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:44 * adamw thwaps meetbot with a wrench
16:01:01 <adamw> #meetingname fedora-qa
16:01:01 <zodbot> The meeting name has been set to 'fedora-qa'
16:01:01 <cmurf> seriously
16:01:06 <adamw> #topic Roll call
16:01:12 <adamw> cmurf: seriously. i have the golden touch
16:01:29 <adamw> OK, who's about for some loosely-labelled 'fun'?
16:01:44 <cmurf> no i figured meetbot has needed backside of the head treatment for months
16:01:49 * jreznik will be ready soon, a dog needs to go out for a sec
16:01:49 * Viking-Ice fetches coffee
16:01:52 * roshi is here
16:02:05 * mkrizek is here
16:02:22 * tflink is here
16:02:33 <adamw> Viking-Ice: mine's a double double
16:02:40 <cmurf> oh yeah coffee, brb
16:05:28 * adamw leaves two minutes for everyone to get coffee
16:05:32 <adamw> i'm a goddamn humanitarian
16:05:54 <cmurf> or a realist
16:06:19 <adamw> heh
16:06:50 <adamw> #topic Previous meeting follow-up
16:07:04 <adamw> "jreznik to move forward with proposing switch to 'feature preview mode' for thinp"
16:07:09 <adamw> well, i know about that one
16:07:35 <Viking-Ice> the not so ready thinp ;)
16:07:42 * pschindl is late but here
16:07:58 <adamw> #info "jreznik to move forward with proposing switch to 'feature preview mode' for thinp" - this was proposed to fesco but rejected on basis thinp isn't actually the area giving us many problems right now, though everyone recognizes the issue of overwork for anaconda storage devs
16:07:59 <jreznik> yeah, kparal sent a mockup to anaconda devel list
16:08:06 <cmurf> i think thinp is more of an unknown, the issue is that it's caused other LVM problems that are still getting flushed out
16:08:16 <adamw> hmm, that was a bit off
16:08:20 <adamw> #undo
16:08:20 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xa328dd0>
16:08:36 <adamw> #info "jreznik to move forward with proposing switch to 'feature preview mode' for thinp" - this was proposed to fesco but deferred to anaconda team on basis thinp isn't actually the area giving us many problems right now, though everyone recognizes the issue of overwork for anaconda storage devs
16:09:20 <jreznik> seem reasonable and in case of big issues we will follow up with anaconda guys
16:09:20 <adamw> cmurf: sorry i couldn't do a better job representing your view at the meeting, didn't have any references to hand
16:09:37 <cmurf> ?
16:09:41 <Viking-Ice> what was anaconda's dev take on it
16:10:12 <adamw> #info kparal posted mockups of how it could be done to anaconda-devel-list: https://www.redhat.com/archives/anaconda-devel-list/2013-November/msg00049.html
16:10:31 <cmurf> which view?
16:10:36 * kparal arrives late
16:10:44 <Viking-Ice> looks noticeable
16:10:45 <adamw> Viking-Ice: dlehman doesn't think it's necessary to put thinp in feature preview mode
16:11:00 <Viking-Ice> and btrfs ?
16:11:11 <adamw> but he understands where we're coming from in general, that there's just too much storage stuff
16:11:27 <adamw> i'm not sure if anyone made a definite decision about btrfs, have to look back in the logs
16:11:30 <adamw> anyone else remember?
16:11:35 * cmurf got sick, kparal did all the work
16:11:48 <cmurf> (mockup, etc)
16:11:51 <kparal> I didn't see any decision about btrfs
16:12:06 <kparal> and no reply to my mockup either :)
16:12:15 <cmurf> so we haven't had a btrfs throwdown and i think we just try to skate through to final
16:12:44 <cmurf> mkfs.btrfs flags a big all caps EXPERIENTAL banner at the user
16:12:48 <Viking-Ice> well then we add all the thinp issues to the blocker list
16:12:58 <adamw> Viking-Ice: like what? i couldn't actually find any when fesco asked
16:13:01 <Viking-Ice> regardless if they are some corner cases
16:13:03 <cmurf> it's completely reasonable that the installer notify users
16:13:10 <adamw> but yeah, if you're aware of any that look blocker-y, they get to be blockers
16:13:18 <cmurf> even if it's a belated addition
16:13:31 <Viking-Ice> yes I would think so
16:14:06 <cmurf> most of the LVM, conventional or thinp, problems aren't data risking things, they're boot problems
16:14:13 <cmurf> and mounting problems
16:14:25 <cmurf> so you get cases where an LV just can't be found or activated
16:14:26 <Viking-Ice> right
16:14:39 <Viking-Ice> and those should be blockers
16:14:54 * pwhalen is here
16:15:21 <Viking-Ice> if it prevents boots or causes issues at bootup they are clear blockers
16:15:37 <adamw> so for the record: http://ur1.ca/g3h88 is the conversation we had in #anaconda shortly after the fesco discussion
16:15:51 <cmurf> Viking-Ice: agreed, although then to be consistent the same applies to btrfs
16:16:23 <adamw> it kinda spun off in a different direction quite quickly, but on the topic, dlehman said "it might be nice to make both thinp and btrfs tech previews...of course it'd mostly have been nice if I'd done it for alpha"
16:16:29 <adamw> so i think he's of the opinion that it's too late at this point
16:16:44 <adamw> but we didn't make an absolutely definite decision
16:16:50 <Viking-Ice> the only point it's to late is when we have already released ;)
16:16:55 <kparal> Viking-Ice: +1
16:16:59 <adamw> heh
16:17:00 <roshi> +1
16:17:05 <adamw> so in the agenda, we have this: "cmurf and kparal to discuss status of btrfs with anaconda team"
16:17:18 <adamw> did you guys have any discussions i haven't covered yet, or shall i #info the informal one from above?
16:17:21 <cmurf> well i was delerious on illness so that didn't happen
16:17:27 <adamw> owch :( hope you're better!
16:17:41 <kparal> I had no separate discussion on btrfs
16:17:44 <cmurf> i'm fine
16:17:44 <adamw> ok
16:17:47 <Viking-Ice> that would have been intersting discussion had it taken place high on pain meds lol
16:17:57 <cmurf> no pain meds
16:18:01 <cmurf> no sick meds
16:18:18 <cmurf> coffee, tea, water, and candy
16:18:19 <jreznik_> and as I said, kparal sent a proposal how to deal with experimental stuff :) gimp monkey!
16:18:19 <cmurf> LOL
16:18:26 * satellit_f20 here late listening
16:18:28 <kparal> I think the important fesco messages is that they can do whatever they see fit, even with btrfs
16:18:45 <Viking-Ice> so what they overule us ?
16:18:55 <adamw> #info "cmurf and kparal to discuss status of btrfs with anaconda team" - aside from kparal's mockup, not done yet (cmurf was ill). adamw had an informal discussion with anaconda devs where the idea of btrfs as a tech preview was not ruled in or out, but it may be quite late to try and change it for F20.
16:18:58 <jreznik_> kparal: yep and that we don't have anything like official tech preview but if anyone wants to say this is experimental, it's still ok
16:19:06 <adamw> Viking-Ice: the 'they' in that sentence was 'anaconda team', i believe
16:19:11 <kparal> yes
16:19:21 <adamw> basically, fesco left it up to the anaconda devs what to do
16:19:35 <cmurf> they are excellent delegators
16:19:41 <adamw> so shall i set an action on cmurf/kparal again for this week, or what?
16:19:41 <Viking-Ice> adamw, does not change matter there is no point in release criteria if it can be overruled
16:19:46 <sgallagh> adamw: We left it up to the anaconda devs to decide if the bugs can be fixed for final or not.
16:19:56 <adamw> Viking-Ice: there's nothing in any discussion about overriding release criteria
16:19:59 <adamw> sgallagh: thanks
16:20:02 <sgallagh> If not, I'm still of the opinion that  sticking (experimental) next to the drop down is ok
16:20:05 <kparal> I think it's anaconda's decision right now
16:20:33 <Viking-Ice> sgallagh, there is also the bootup ( lvm/dracut/systemd ) so this is not limited to anaconda only
16:20:37 <adamw> well i'm kinda of the opinion that the anaconda team's a bit like a log on a river
16:20:47 <adamw> unless it gets some fairly serious poking from the outside they just keep rolling along
16:20:56 <kparal> :)
16:21:13 <adamw> if everyone just says 'eh, leave it to anaconda' and waits on anaconda team to make decisions, what will happen is forward momentum - we'll just keep going with what we've got
16:21:28 <cmurf> true
16:21:38 <adamw> i don't mind that, so long as (as viking points out) no-one else minds release slips...
16:22:09 <Viking-Ice> we seem to be dealing with a serious lvm issue in 1026860 ( which has not yet been proposed as a blocker )
16:22:25 <kparal> poking volunteers welcome, I don't feel like doing that this week
16:22:30 <Viking-Ice> throw that in misture with lvm thinp ;)
16:22:34 <cmurf> .bug 1026860
16:22:36 <Viking-Ice> mean mixture
16:22:40 <zodbot> cmurf: Bug 1026860 Instantiated service is not run, it stays in inactive state (and systemd debug log does not state why) - https://bugzilla.redhat.com/show_bug.cgi?id=1026860
16:22:46 <cmurf> it may have been caused by the lvm thinp changes
16:22:56 <adamw> that one is proposed as a blocker, isn't it?
16:23:00 <jreznik_> it's proposed
16:23:03 <adamw> it's in the 'needs more info to vote on' pile
16:23:05 <jreznik_> I talked to Peter today
16:23:26 <cmurf> long hang for bugzilla...
16:23:27 <Viking-Ice> oh right missed comment 18
16:23:40 <jreznik_> I have an answer for your question how severe it is, he promised me to put it into bz, not sure it's there
16:23:57 <adamw> that'd help
16:23:59 <jreznik_> also he's now in touch with systemd guys as he needs help
16:24:16 <Viking-Ice> Well Václav has pinged Kay about it
16:24:35 <jreznik_> adamw: what he says - in short - mostly hw raid should be impacted
16:24:37 <Viking-Ice> being a race condition in udev so for some it will work others it fails
16:25:02 <Viking-Ice> if the moon correctly aligns with the sun boom you cannot boot
16:25:32 <adamw> okay, we've taken a long time on this...so for now, the ball is in anaconda team's court, and if no-one does anything definite we'll carry on with the current state where we have to consider bugs in all anaconda storage mechanisms, inc thinp and btrfs, as potentially release blocking. if anyone is very unhappy about that or the consequences of it, please raise it on list or with anaconda team.
16:25:49 <cmurf> ack
16:25:49 <adamw> jreznik_: hwraid? interesting.
16:26:07 <adamw> #topic Matrix revisions
16:26:11 <adamw> so, this one comes from robatino
16:26:17 <adamw> robatino: are you around?
16:26:26 <robatino> yes, but not qualified to make the changes
16:26:26 <jreznik_> adamw: sorry, BIOS RAID to be correct...
16:26:35 <adamw> jreznik_: ah, that makes more sense.
16:26:48 <jreznik_> I'll ask him to put it into bz, or I can try to translate it
16:26:57 <cmurf> imsm raid
16:27:07 <cmurf> what's the problem?
16:27:44 <jreznik_> but let's move on - adamw is right - if anyone is not happy with the latest decision, should poke on the anaconda list
16:28:09 <Viking-Ice> I thought we had move to the matrix ;)
16:28:14 <cmurf> yes
16:28:31 <jreznik_> Viking-Ice: ah, missed that, sorry :D
16:28:42 <cmurf> bios raid matrix....
16:28:46 <cmurf> what's the problem?
16:28:51 * jreznik_ read it as Martix revisions :)
16:28:55 <adamw> i was hoping robatino would be around
16:28:57 <adamw> hehe
16:29:00 <adamw> yes, we need to revise martix!
16:29:05 <cmurf> he just replied
16:29:11 <adamw> oh yes, there he is
16:29:14 <adamw> lost in the flood
16:29:24 <adamw> hi robatino! so the idea is https://lists.fedoraproject.org/pipermail/test/2013-November/118791.html , yes?
16:29:46 <robatino> i just pointed out the problem. i don't know how to fix it
16:30:23 <Viking-Ice> hmm sounds like something that should be automated
16:30:27 <kparal> we should put it into " Cloud images" section
16:30:37 <kparal> Viking-Ice: no doubt about that. but it is not
16:30:37 <adamw> i guess we'd just write a test case that looks like the ARM one and put it in the matrix
16:30:38 <Viking-Ice> kparal, what why
16:30:49 <Viking-Ice> ( the cloud section )
16:30:49 <robatino> technically, you could say that verifying checksum files shouldn't be in the matrix at all, since ot
16:30:59 <robatino> it's not a problem with the images themselves
16:31:04 <kparal> we can add a test case for Images/ checksums into Cloud section in the matrix
16:31:11 <Viking-Ice> yes it should not be in the matrix
16:31:13 <adamw> robatino: nah, i wouldn't buy that: the checksums are part of the compose process
16:31:37 <robatino> but they can be fixed if they're broken, unlike the other tests
16:31:41 <Viking-Ice> adamw, images and their checksums should be validated at compose time
16:31:45 <adamw> the compose process doesn't just produce images, it produces the package trees and metadata bits, seems to make sense to consider checking all of those part of 'release validation'
16:31:49 <Viking-Ice> this does not belong in our matrix
16:32:05 <adamw> Viking-Ice: everything _should_ be checked before it gets to QA
16:32:11 <cmurf> roshi: your dual boot windows test has been in progress for at least 18 hours, want me to fill it in? I've already done it, it works.
16:32:13 <adamw> happily it isn't and I can feed my cat :P
16:32:20 <roshi> haha
16:32:26 <roshi> sorry - thought I updated that
16:32:31 <roshi> but yeah, it works
16:32:41 <Viking-Ice> adamw, in perfect pony world yeah *everything*
16:33:13 <robatino> i should point out that the checksum tests in general have 2 parts: verifying a checksum file, and verifying an embedded checksum. for the Images/ dir tests, only the first applies
16:33:36 <robatino> only the second part is a problem with the images themselves
16:33:50 <adamw> Viking-Ice: anyway, we already check the checksums for everything else, so it's clearly inconsistent that we don't do it for the cloud images
16:34:00 <Viking-Ice> adamw, yup
16:34:05 <adamw> robatino: why do you say you're not qualified to fix this, btw? it's pretty straightforward
16:34:24 <robatino> i don't know anything about cloud images. anyway, i'm sleep deprived now
16:34:33 <adamw> robatino: just write a test case that's a copy of the ARM one with the appropriate changes, and draft a change to the template page that adds a row for that test case to the 'cloud images' table
16:34:50 <adamw> robatino: hell, i didn't know anything about cloud images when i put them in the matrix for alpha either. :P
16:35:14 <adamw> but i can take the #action if you like.
16:35:25 <Viking-Ice> speaking of cloud hows testing from that community going?
16:35:27 <robatino> please do
16:35:47 <adamw> Viking-Ice: they've tested things when we've pinged them that they need testing, at least. ARM seems a little more proactive
16:36:06 * satellit yum update does work in non-blocking soas via terminal no need to grey out box
16:36:12 <pwhalen> adamw, seems!? :)
16:36:20 <adamw> no cloud image test results filed for Final TC1 or TC2
16:36:31 <adamw> pwhalen: i'm being diplomatic :)
16:37:21 <Viking-Ice> adamw, not worried about arm, how the cloud community proceeds dealing with their stuff is an indicator how well the output from WG's will be handled
16:37:28 <adamw> #action adamw to draft a new test case and matrix row for validating cloud image checksums - https://lists.fedoraproject.org/pipermail/test/2013-November/118791.html
16:37:49 <adamw> Viking-Ice: welp...there's the answer
16:37:51 <jreznik_> for cloud, especially to related to first class cloud images change...
16:38:20 <adamw> moving on to try and keep under time...
16:38:22 <adamw> #topic Fedora 20 Final status
16:38:22 <Viking-Ice> adamw, welp they did not do so well with the alpha phaze
16:38:37 <tflink> IIRC, most of the f20 cloud test results have been submitted by nirik, red_alert or me
16:38:45 <tflink> but I could easily be wrong there
16:38:50 <adamw> sounds about right to me
16:39:13 <adamw> #info TC2 is currently undergoing testing. latest anaconda is one build newer than TC2, TC3 will probably come soon
16:39:34 <cmurf> freeze is this week?
16:39:43 <adamw> #undo
16:39:43 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x86e9850>
16:39:53 <tflink> cmurf: tomorrow
16:39:54 <adamw> #info TC2 is currently undergoing testing. latest anaconda is two builds newer than TC2, TC3 will probably come soon
16:40:20 <adamw> #info Final freeze is tomorrow
16:40:56 <cmurf> oh goody
16:40:57 <jreznik_> cmurf: yes
16:41:00 <adamw> #info blocker list is still pretty full, and there is missing test coverage on TC2 still
16:41:22 <adamw> it'd be good if we can get ARM and cloud testing done for TC2, and the Final desktop tests - i wish we'd got those done earlier, it's getting late
16:41:35 <adamw> #action adamw to make sure the desktop tests are completed for TC2
16:42:14 <adamw> anything on f20 status that i've not covered?
16:42:29 <adamw> anything anyone sees as a potential big problem on the horizon or anything?
16:42:33 <pwhalen> adamw, is there an area in particular for arm? believe I only need some more desktops, but not release blocking
16:42:38 <cmurf> geoip might not be working
16:42:46 <adamw> pwhalen: oh, sorry, i may have been looking at out-of-date pages
16:43:01 <adamw> cmurf: i believe it's supposed to be fixed for live in tc2. does seem better here.
16:43:02 <pwhalen> base and install are complete
16:43:05 <cmurf> https://geoip.fedoraproject.org/city
16:43:11 <cmurf> i get bogus values
16:43:13 <adamw> oh, upstream geoip
16:43:16 <cmurf> null for everything
16:43:19 <jreznik_> there are a few potential bombs in proposed blockers...
16:43:20 <cmurf> wrong lat long
16:43:22 <adamw> cmurf: works fine here...
16:43:28 <cmurf> *shrug*
16:43:31 <adamw> jreznik_: which ones worry you particularly?
16:43:32 <cmurf> worked fine for beta
16:44:07 <jreznik_> adamw: that plasma related one seems like upstream is fighting without any success
16:44:10 * satellit I see honolulu sometimes in California locations esp if wireless AP used
16:44:32 <kparal> satellit: that should be fixed in newest anaconda build
16:44:36 <satellit> k
16:44:36 <cmurf> there is a langtable update that fixes the default if geoip isn't working
16:45:03 <adamw> jreznik_: the KDE-on-ARM one? yeah, that worries me a little
16:45:16 <jreznik_> yep
16:45:18 <pwhalen> me too
16:45:29 <adamw> that and https://bugzilla.redhat.com/show_bug.cgi?id=1004621 are potential major KDE issues
16:45:30 <jreznik_> and then the systemd long boot one
16:45:51 * adamw throws 1004621 on the proposed blocker list
16:46:17 <adamw> jreznik_: do you want an action item to check with KDE folks if they think they're well positioned to cope with those two bugs, or if there's something we (fedora) can do to help?
16:46:20 <jreznik_> ltinkl and guys are on the arm related one, in touch with upstream
16:46:36 <jreznik_> adamw: sure
16:47:15 <adamw> #action jreznik_ to check in with KDE team if they're on top of the two proposed KDE blockers or if help would be appreciated
16:48:23 <adamw> cmurf: that would be https://admin.fedoraproject.org/updates/FEDORA-2013-21912/langtable-0.0.21-1.fc20 ?
16:49:04 <cmurf> correct
16:49:10 * satellit other languages in anaconda banners?
16:49:31 <adamw> that went into tc2, i believe.
16:49:46 <adamw> it's why the tc2 images got a bit bigger - but desktop still juuuuust comes out undersize.
16:50:11 * satellit no browser in LXDE?
16:50:18 <adamw> there's a bug report for that, right?
16:50:21 <cmurf> langtable-0.0.19-1.fc20.src.rpm  is in TC2
16:50:48 <adamw> cmurf: yes, tcs get what's stable except for FE/blocker fixes that are requested
16:50:59 <adamw> cmurf: 0.0.21 won't make final unless it gets lots of karma today, or an FE bug
16:51:06 <cmurf> oic
16:51:10 <adamw> cmurf: so...you know what to do :)
16:51:16 <cmurf> alright well i'll give it karma even though it doesn't fix my bug
16:51:17 <cmurf> haha
16:51:20 <adamw> =)
16:51:23 <adamw> as long as it works, +1 is okay
16:51:45 * adamw can't find the bug for LXDE comps issues, anyone?
16:51:55 <adamw> oh, got it
16:52:09 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=1033746 , it's proposed as an FE. so looks like we're on top of it, satellit
16:52:15 <satellit> k
16:53:18 * adamw CCs cwickert
16:54:44 <adamw> OK...anything else for f20 status?
16:54:53 <cmurf> should an email requesting critpath bug fix testing and karma go out?
16:55:02 <cmurf> better to have more of those rolled into TC3?
16:55:15 <adamw> cmurf: sure, wouldn't hurt - you want to send one?
16:55:19 <cmurf> no
16:55:21 <cmurf> haha
16:55:24 <kparal> :))
16:55:25 <cmurf> but ok
16:55:33 <adamw> wrong answer, try again
16:55:46 <cmurf> I have no idea how to send that big blast variety wth the long list of things to test
16:55:49 <adamw> #action cmurf to send a quick email to test-announce asking folks to test and karma critpath updates ahead of freeze tomorrow
16:55:56 <adamw> #undo
16:55:57 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x9cb6d90>
16:56:04 <adamw> wait - are we talking about the blocker status email?
16:56:08 <adamw> i was gonna do one of those
16:56:23 <adamw> i thought you rather meant a general 'freeze is tomorrow, let's get as many updates karma'ed and pushed stable as we can' mail
16:56:33 <cmurf> i meant the later
16:56:35 <cmurf> latter
16:57:02 <Viking-Ice> so regarding lxde is someone ( beside cwickert1 ) maintaining that
16:57:47 <adamw> Viking-Ice: cwickert is the main lxde guy. i can commit fixes for something trivial like this, though, if necessary.
16:57:54 <adamw> #action cmurf to send a quick email to test-announce asking folks to test and karma critpath updates ahead of freeze tomorrow
16:57:58 <adamw> cmurf: you might want this link: https://admin.fedoraproject.org/updates/critpath?unapproved=True&release=F20&_csrf_token=01503b08d8edf246fad28011d6f319301dde86dd
16:58:00 <adamw> grr
16:58:01 <Viking-Ice> if I'm not mistaken that compose issue has been with us in this develoeprs cycle from day one which is a strong cwickert does not have the time to maintain it anymore
16:58:03 <adamw> https://admin.fedoraproject.org/updates/critpath?unapproved=True&release=F20
16:58:14 <Viking-Ice> strong indicator
16:58:18 <adamw> Viking-Ice: he wasn't CCed on the bug till now, and the bug was only filed a couple of days ago
16:59:07 * cwickert1 still has one update pending for LXDE
16:59:19 <adamw> so yeah, folks - even ahead of cmurf's mail, take a look at https://admin.fedoraproject.org/updates/critpath?unapproved=True&release=F20 and karma karma karma
16:59:28 <cwickert1> it's critical path, so feedback is welcome
16:59:35 <cwickert1> s/feedback/karma
16:59:41 <adamw> #info critpath update for f20 that are pending karma are https://admin.fedoraproject.org/updates/critpath?unapproved=True , please test and karma them
17:00:01 <adamw> cwickert1: that would be https://admin.fedoraproject.org/updates/FEDORA-2013-21536/lxpanel-0.6.1-1.fc20,lxlauncher-0.2.2-4.fc20,pcmanfm-1.1.2-3.D20130830gitfc8adaab77.fc20,libfm-1.1.2.2-3.fc20,menu-cache-0.5.1-1.fc20 , right?
17:00:22 <adamw> cwickert: and i take it you'll take a look at the 'missing browser' bug now I cc'ed you?
17:00:34 <cwickert> adamw: yes and yes
17:00:38 <adamw> roger
17:00:45 <adamw> i'll try and build an LXDE live with that update today and get you some karma then
17:00:49 <cwickert> I think I already filed that myself
17:01:19 <adamw> OK
17:01:22 <adamw> #topic open floor
17:01:26 <adamw> anything for open floor, quickly?
17:02:17 * satellit_f20 add test for Soas like the ones on sugarlabs.wiki?
17:02:47 <Viking-Ice> well the fact is that there will be no cleanup taking place in this WG nonsense which means we will remain equally fucked as we are now
17:02:54 <Viking-Ice> ( and have been  )
17:03:35 * adamw having trouble keeping up with the WG stuff as they all seem to be scheduling their meetings in the middle of the goddamn night for him
17:03:44 <Viking-Ice> so reporters have to know what they will be signing themselves up for
17:03:53 <adamw> but i saw that apparently there just isn't enough change so now they want to do variant release cycles as well
17:03:53 * satellit_f20 http://wiki.sugarlabs.org/go/Fedora/Sugar_test_cases
17:04:06 <adamw> satellit: the weekly reminder :( sorry i still didn't do that yet, i suck
17:04:53 * satellit thanks for looking at it
17:04:53 <Viking-Ice> adamw, variant release cycle is inevitable it's just taking longer for some people to realize it + from the looks of it dennis is pulling an Jesse keating so that wont happen anyway
17:05:24 <adamw> Viking-Ice: anything *specific* on the WG stuff that we can constructively discuss/take action on?
17:06:16 <Viking-Ice> adamw, we wont have to things will stay the same from the looks of it which is the reason I walked out of the serverWG since the process is not about any actual change
17:06:37 <Viking-Ice> at least no change that matters to us
17:06:46 <Viking-Ice> and will improve things for us here in QA
17:06:52 <adamw> :/
17:07:03 <adamw> i keep resolving to try and stay more plugged into that process but it's not working out. ah, well.
17:07:17 <adamw> anyone who does want to make an effort to show up to some of the WG meetings and keep tabs on the process, it'd be useful
17:07:37 <tflink> I've been trying to show up for some of the meetings
17:07:38 <Viking-Ice> well I'm keeping taps on it's proceeding
17:07:54 <Viking-Ice> in the server/base stuff
17:08:02 <adamw> yeah, thanks guys
17:08:22 <roshi> I can take notes in a WG
17:09:03 <Viking-Ice> there are no notes to take for us as things stand now and wont be heck we dont even know what they expect from us but I guess our answer will be no anyway
17:09:11 <Viking-Ice> :=
17:09:13 <Viking-Ice> ;)
17:09:18 <roshi> looks like we need someone to watch the workstation WG and cloud?
17:09:28 <adamw> roshi: seems like it
17:09:34 <adamw> i should really be going to workstation
17:09:40 <roshi> I can watch workstation
17:09:44 <Viking-Ice> the cloud WG arguable should not exist the workstation WG is just the usual gnome
17:09:46 * roshi has only a little experience with cloud
17:10:19 * satellit I could not test as requires $ to get account
17:10:45 <adamw> ah, i see the workstation WG has set its very first goal as something that's basically impossible to achieve, whee.
17:10:54 <Viking-Ice> ;)
17:10:59 <drago01_> adamw: which is?
17:11:04 <adamw> oh well, don't think there's any more specific action needed here
17:11:10 <adamw> "Upgrading the system multiple times through the upgrade process should give a result that is the same as an original install of Fedora Workstation."
17:11:13 <adamw> that's never going to happen.
17:11:25 <tflink> wow
17:11:59 <roshi> o.O
17:11:59 * satellit offline installs are very intrusive
17:12:01 <cmurf> more like in the F21 time frame i think the WG's need to be given periodic "recruit for QA" assignment
17:12:16 <roshi> +1 cmurf
17:12:25 <adamw> sorry, how do you mean?
17:12:26 <drago01_> adamw: not with the current way we do upgrades
17:12:31 <Viking-Ice> They are aiming for longer support life cycle as well in the serverWG without any buy from devs ( I received few emails where devs contacted me and ask me if the serverWG would sign them up for something they where not willing to do )
17:12:36 <drago01_> adamw: but it isn't impossible to do
17:12:40 <adamw> drago01_: or any way anyone's done upgrades ever, so far as I'm aware.
17:13:18 <adamw> that 'how do you mean' was aimed at cmurf
17:13:21 <drago01_> adamw: yeah my point is "just upgrade every installed package" is not good enough ... we need some kind of thing that defines what is supposed to be there
17:13:25 <jreznik_> Viking-Ice: that concerns me too...
17:13:28 <Viking-Ice> in anycase things are nowhere near ready for *any* involvement of the support community in the distribution
17:13:43 <Viking-Ice> QA/Releng/Marketing/Design
17:14:05 <cmurf> adamw: as in the WG's need to help us recruit some of their own people for testing the things they're asking everyone to build, and that will then need testing
17:14:48 <Viking-Ice> jreznik_, yeah that was one of the reason I proposed different repos per server roles and walked away as well. I dont want to have that on my consciousness signing people up for something that they are not willing to do.
17:14:57 <cmurf> in the F21 cycle, our test matrix is going to positively explode
17:15:11 <Viking-Ice> cmurf, no not for us
17:15:17 <Viking-Ice> we only care about baseWG
17:15:24 <Viking-Ice> stuff and the installer
17:15:50 <cmurf> hence why i'm saying in the f21 time frame because we don't even know such things about installer derivatives
17:15:58 <adamw> cmurf: could you explain "more like in the F21 time frame i think the WG's need to be given periodic "recruit for QA" assignment" a bit mroe? i didn't quiter grok it
17:16:16 <Viking-Ice> what ever the layers maybe on top of that from the WG's  have to be covered by those WG's
17:16:58 <cmurf> adamw: I mean for the WG to be assigned, periodically, a recruitment drive for WG participants to participate in QA.
17:17:08 <adamw> ah, i see
17:17:18 <Viking-Ice> cmurf, not how the process works
17:17:22 <adamw> the way we try and get desktop SIGs and cloud/arm to help with testing those areas currently
17:17:37 <adamw> that certainly sounds like something that should happen, but as viking says, i'm not sure how we 'assign' things to WGs.
17:18:01 <cmurf> propose that they assign the task to themselves then
17:18:04 <cmurf> they can say no
17:18:16 <Viking-Ice> we just write release criteria and ensure they follow it, it's up to them if they meet those release criteria or not ( if not no release )
17:18:27 <adamw> sounds reasonable, though we're still a long way ahead of any actual products to test
17:18:40 <Viking-Ice> very long way ahead
17:18:43 <adamw> ok, we're 20 mins over time...anything else?
17:18:51 <Viking-Ice> not from me
17:19:47 * cmurf is going to murder more coffee bean deities to create the divine elixir.
17:20:36 * roshi is going to do the same
17:21:05 <adamw> you heartless people
17:21:12 * adamw goes to play with his new tablet some more I MEAN TEST TC@
17:21:22 <adamw> thanks for coming, folks
17:21:34 <adamw> #endmeeting