15:02:01 <adamw> #startmeeting Fedora QA meeting
15:02:01 <zodbot> Meeting started Mon Oct 14 15:02:01 2013 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:03 <adamw> #meetingname fedora-qa
15:02:03 <zodbot> The meeting name has been set to 'fedora-qa'
15:02:09 <adamw> #topic Roll call
15:02:35 * roshi is here
15:02:43 * mkrizek is here
15:03:16 * tflink is present
15:03:30 * brunowolff is lurking
15:03:35 <adamw> #chair tflink brunowolff
15:03:35 <zodbot> Current chairs: adamw brunowolff tflink
15:03:47 * jskladan lurks
15:04:03 <adamw> dgilmore: you about? we might need to check in on tc status
15:04:18 <dgilmore> adamw: i am
15:04:25 <adamw> thanks
15:05:49 <adamw> alrighty, let's get going
15:05:53 <adamw> #topic Previous meeting follow-up
15:06:44 <adamw> #info "adamw to co-ordinate with anaconda team to get a new anaconda build done and roll TC2" - did that, TC2 got built with the stuff we wanted, and we're now onto TC3ish
15:07:04 <adamw> " tflink and handsome_pirate to write up detailed proposals for projects to be worked on in a possible longer f21 schedule and post / link to them in the trac ticket " - i believe this got done, but do you want to provide more details, tflink?
15:07:40 * jreznik is here, bit late, phone call
15:08:43 <tflink> a proposal was submitted to fesco on wednesday to delay f21 for work on tooling and infrastructure
15:09:16 <tflink> the proposal they reviewed from QA is: https://fedoraproject.org/wiki/User:Tflink/f21_delay_taskbot_development_proposal
15:09:43 <tflink> The current state is that f21 has been delayed 1 month with branch being no earlier than 2014-03-01
15:10:24 <tflink> this will be re-visited in January once the WGs for fedora.next have met and produced some output on how they would like to proceed
15:10:44 <adamw> coolbeans
15:10:58 <tflink> so the current plan is to have autoqa replaced by 2013-03-01
15:11:15 <jreznik> tflink: I still don't see where you get that month and time for branching
15:11:28 <jreznik> see my comment in the ticket
15:11:42 <tflink> jreznik: do you want to discuss here or in the ticket?
15:12:10 <jreznik> tflink: ticket, so it's not lost in the internet
15:12:34 <tflink> k
15:13:08 <tflink> for coherance, jreznik thinks that branch would be later and doesn't understand where I'm getting 2013-03-01 from
15:13:36 <tflink> discussion on that point will continue in the fesco ticket https://fedorahosted.org/fesco/ticket/1178
15:14:21 * satellit joining late
15:14:28 <adamw> #info "tflink and handsome_pirate to write up detailed proposals for projects to be worked on in a possible longer f21 schedule and post / link to them in the trac ticket" - this was done: https://fedoraproject.org/wiki/User:Tflink/f21_delay_taskbot_development_proposal was reviewed by FESCo among other submissions, and F21 will be delayed a minimum of one month. current plan is to have autoqa replacement in place by 2013-03-01
15:14:31 * jreznik can share full TaskJuggler schedule to the usual place
15:14:41 <adamw> sorry, it's too long to detail the controversy :)
15:15:07 <adamw> #topic Fedora 20 Beta status
15:15:21 <adamw> so, let's see
15:15:31 <adamw> TC2 got built and tested pretty well, coverage looks a lot better than TC1
15:15:53 <adamw> i filed a TC3 request over the weekend and it seems like there were some complications with building, dgilmore, can you summarize?
15:16:24 <brunowolff> Dropping gimp-help broke composes. This is been fixed in git.
15:18:13 <jreznik> brunowolff: fixed? do you have reference?
15:18:36 <adamw> do you mean 'is being' or 'has been'?
15:18:39 <brunowolff> I just saw the log of dgilmore's commits to spin-kickstarts.
15:19:09 <jreznik> brunowolff: it's not fix, it's workaround to make tc4 happen
15:19:26 <brunowolff> The fixes were commited. Composes pull directly from git. I don't know whether or not new composes were started after the fix was commited (to rawhide and f20).
15:19:55 <adamw> right, so it's not exactly that the bug's been fixed, but dgilmore has put gimp-help back in for the purpose of doing the compose
15:20:00 <jreznik> brunowolff: it fixed compose but it means we still have gimp-help-*
15:20:12 <adamw> we still kinda need to gank it, to hit the size target
15:20:24 <jreznik> adamw: he's looking on the pungi issue
15:20:42 <brunowolff> Well, the oversize issue is probably still there, but things should be composing again.
15:21:02 <adamw> yes.
15:21:04 * satellit TC4 is up
15:21:13 <adamw> so, let me summarize
15:21:28 <adamw> #info TC3 compose was done, but the attempt to remove gimp-help from the DVD to save space caused major problems
15:21:50 <adamw> #info TC4 was then composed with gimp-help-* restored to the DVD image to ensure a successful (but over-size) compose
15:22:07 <brunowolff> Well, if one wanted to do that, presumably gimp would need to be changed not to require gimp-help. I don't know if that is happening as I don't following dimp packaging. I do notice stuff with spin-kickstarts ocassionally, as I follow that.
15:22:07 <adamw> #info TC3 is a dead letter, TC4 has oversize DVD image but should be fully testable
15:22:27 <adamw> brunowolff: we wanted to yank the localized gimp-help *subpackages*, not gimp-help *itself*
15:22:40 <adamw> aiui, anyway
15:24:06 <dgilmore> adamw: so the issues is that when we remove gimp-help* pungi pukes
15:24:41 <dgilmore> adamw: TC3 i pulled in the wrong anaconda
15:24:56 <dgilmore> so i redid the compose will all the correct builds
15:25:31 * handsome_pirate rolls in late
15:26:22 <adamw> dgilmore: right, but it seems to be a pungi issue of some kind not just a straight forward dependency fail, right?
15:26:25 <adamw> ahoy, pirate
15:26:51 <jreznik> maybe one question is why we have gimp-help-* now being pulled into compose, I don't see any change in packages compared to f19
15:27:00 <dgilmore> adamw: unknown
15:27:19 <dgilmore> jreznik: pungi changes from dmach
15:27:26 <adamw> still, we can work on that outside of the meeting
15:27:30 <adamw> just wanted to nail down the status
15:27:35 <dgilmore> jreznik: he gave me some patches to pull in langpacks
15:27:44 <dgilmore> and that is where pungi is puking
15:28:11 <adamw> so we want to be testing tc4 now, and really making sure we get full coverage and catch as many blockers as possible
15:28:19 <adamw> freeze is this wednesday
15:28:28 <jreznik> dgilmore: ok, I can ask him
15:28:41 <jreznik> (to take a quick look if it helps)
15:29:08 <dgilmore> jreznik: not really but thanks
15:29:20 <adamw> anyone have any notes on test coverage? anything we're worried about not being able to cover?
15:29:40 <jreznik> dgilmore: at least he will be aware of it...
15:29:46 <adamw> one important note is that tc4 ought to work on the beaglebone black: some of us have those boards, so we should definitely check that
15:30:09 <adamw> #info TC4 should be tested on the beaglebone black
15:32:20 * handsome_pirate will hit that
15:32:25 <adamw> thanks pirate
15:32:35 * handsome_pirate gave a scratch build a go this weekend on BBB and it worked
15:32:36 <adamw> i'm not in the same continent as my BBB so it'll have to wait for me to test it :/
15:32:41 <adamw> well, pbrobinson probably has one here.
15:32:45 <adamw> handsome_pirate: nice
15:32:48 <roshi> I'll test that too
15:32:52 <adamw> thanks folks
15:33:03 <handsome_pirate> It was basically TC2 with the new kernel
15:33:07 <adamw> so the other note I have is to consider doing a freeze exception for GNOME 3.10.1
15:33:27 <adamw> it seems like we always wind up with a sucky schedule conflict with GNOME's schedule - they'll be doing 3.10.1 right around the freeze date
15:33:32 <handsome_pirate> Could we do a scratch build to test before that?
15:33:37 <adamw> of course
15:33:39 <adamw> i usually do one
15:33:44 <adamw> easy enough to spin up a live image
15:33:49 <handsome_pirate> Okay, so, we're all going to lunch
15:33:58 <pbrobinson> adamw: I do
15:34:00 <handsome_pirate> adamw:  I'd like to talk about OPW at some point, but we're off
15:34:00 <adamw> it'll include fixes for lots of stuff including blockers in gnome-software
15:34:06 <adamw> handsome_pirate: who's 'we'?
15:34:27 <handsome_pirate> adamw:  The folks I work with
15:34:34 <adamw> okay
15:34:41 <adamw> thanks for dropping by
15:35:10 <adamw> so it's probably just sensible to pull 3.10.1 in wholesale, we have the whole of freeze period to stabilize it and it's a bugfix release anyway, so shouldn't be a problem
15:35:22 <adamw> would anyone be particularly opposed to doing that?
15:35:29 <tflink> yeah, I don't think it's been a huge problem in the past
15:35:52 <adamw> obviously for the future we really ought to look at making sure we don't have this silly schedule overlap, but for f20 we're stuck with it
15:35:59 <jreznik> we did it several times, worked pretty well... so it s*word be ok
15:36:03 <adamw> :)
15:36:22 <tflink> :)
15:37:02 <jreznik> adamw: how? ;-) not sure we are able to schedule in week detail to make it happen... at least I'm trying for bigger picture overlap of schedules that it makes sense but even that is lottery :)
15:37:56 <brunowolff> I think pulling in the whole thing makes more sense than pulling in just parts. That seems like it might introduce more problems.
15:38:20 <adamw> jreznik: i dunno precisely, but it seems like something we should fix. the 'we' that isn't me. :P
15:38:43 <adamw> brunowolff: right, we'd have to pull in at least gnome-software changes to fix blockers, and probably wind up with something else too. this seems simpler
15:38:58 * Viking-Ice joins in late and points out that the QA proposal did not included Anaconda or other QA way's to handle multiple products
15:39:28 <adamw> #agreed in principle we'll support a freeze exception proposal for GNOME 3.10.1 to land just after beta freeze
15:39:47 <adamw> Viking-Ice: well, we said right in the last meeting, if you have ideas for stuff to do during a longer F21 schedule, write them up for FESCo
15:39:54 <adamw> iirc that was your idea...did you write it up for fesco?
15:40:24 <Viking-Ice> adamw, to few responses from Anaconda team to write anything up really
15:40:42 <adamw> tflink's proposal wasn't labelled Official QA Team Proposal List, it was just his own proposal for an idea to work on
15:41:06 <adamw> Viking-Ice: yeah, i saw you didn't really get much traction :/
15:41:12 <Viking-Ice> it's not like we can "force" them to alter their development cycle nor were any alternatives proposed
15:41:14 <Viking-Ice> "the proposal they reviewed from QA is"
15:41:46 <adamw> yeah. if you had made a proposal, tim would've included it in that list.
15:41:49 <adamw> you didn't, so he didn't...
15:41:53 <jreznik> if fedora changes, anaconda would have to follow it up...
15:42:11 <Viking-Ice> adamw, no traction just means no go from QA on multiproduct proposal
15:42:12 <adamw> he listed all the proposal that, in the end, QA folks sent to fesco and fesco looked at.
15:42:13 <tflink> Viking-Ice: which is factually correct - they didn't review any other proposals from QA
15:43:11 <Viking-Ice> I dont know if anaconda has discussed the move to their own development cycle internally
15:43:20 <adamw> i don't know either
15:43:22 <adamw> does anyone?
15:44:25 <jreznik> as I stated above - they will have to follow new model, if Fedora would have new model and we don't know anything about it yet, nothing was decided/agreed on yet
15:44:32 <Viking-Ice> in anycase anything on our side ( dedicated tester/reporter/triager etc team from QA is on hold until )
15:45:12 <Viking-Ice> as in coming up with ( or try to ) dedictated QA anaconda team
15:45:34 <adamw> jreznik: this is more about a specific proposal viking suggested to change the anaconda development schedule
15:45:52 <adamw> jreznik: if you check anaconda-devel-list he proposed it there but didn't get much response from actual anaconda team
15:46:00 <adamw> as he says, the proposal is a bit stuck if anaconda team doesn't buy in
15:46:14 <jreznik> I saw it, of course
15:46:44 <Viking-Ice> one ( Chris ) or two ( if Jens is part of it )
15:47:21 <Viking-Ice> we are stuck until Anaconda team responds so we can try to provide resources or try find alternative methods to solve the dilemma
15:47:24 <adamw> Viking-Ice: so, i don't think the 21 schedule question is settled yet, as per above
15:47:38 <adamw> just that so far they've already definitely decided on _at least_ a one month push bacl
15:47:52 <adamw> so you still have time to try and get buy-in on the idea and send it up to fesco if that happens
15:49:03 <Viking-Ice> I dont run after people and get buy ( I had my fill with that with the systemd migration in F16 ) in the developers can simply respond to that topic if it's in or out
15:49:11 <adamw> Viking-Ice: fair enough
15:49:34 <adamw> jreznik: can we ask anaconda folks to give some feedback on the idea so we know whether it's viable or not?
15:49:45 <Viking-Ice> if they dont respond to that after this week it's off the table and I proposed that QA votes against multiproduct proposal
15:50:14 <Viking-Ice> because there is no way we can handle anaconda + multi products
15:50:27 <Viking-Ice> on the same release cycle
15:50:37 <adamw> welp, we can burn that bridge when we get to it
15:50:59 <jreznik> adamw: yep but again - if we change to multiple products, they have to follow it because otherwise not only qa guys would get mad from testing...
15:51:25 <adamw> well, aiui this is a specific idea of viking's as to what they could change to make things easier with the multi-product proposal
15:51:40 <adamw> if multi-product is actually going to go ahead obviously anaconda's going to have to respect it in SOME way
15:52:01 <adamw> like viking, i don't know if they've actually looked at that whole thing yet at all
15:52:48 <Viking-Ice> afaik anaconda needs to be on own release cycle or anaconda + base coreOS on it's own release cycle or every product on it's own release cycle
15:52:54 <jreznik> ok, in this words, it makes sense
15:53:02 <pjones> that hasn't ever worked before.
15:53:31 <adamw> it sounds like there's quite a lot of uncertainty going around and we've got 7 minutes left
15:53:35 <jreznik> I try to use some of my own ways (no conspiracy) how to get to the answer
15:53:52 <Viking-Ice> jreznik, use what every means you can
15:54:01 <Viking-Ice> ship them whiskey if you have too ;)
15:54:13 <adamw> so maybe for now we can just at least check if anaconda team is aware of this multi-product proposal thing and whether they already have some plan to work with it or are planning to object to it or whatever...and then we might be on slightly more clear ground
15:54:14 <Viking-Ice> ( surely they must be tired of wwoods monshine by now )
15:54:17 <adamw> heh
15:54:35 <jreznik> adamw: yep
15:54:58 <Viking-Ice> regardless of whatever comes out of wg we in QA need to find a way to handle multiple products as effective as possible
15:55:00 <adamw> viking's mail did mention the multi-product stuff, but sort of in a way that assumes the reader already knows what's going on there - it's easy to miss it if you aren't actually aware of that
15:55:08 <adamw> Viking-Ice: if it's going to happen, we certainly do
15:55:24 <adamw> Viking-Ice: proposals welcome for sure...
15:55:32 <adamw> for next week's agenda or the list or anything
15:55:52 <adamw> as a Public Service Announcement: remember you can stick topics into the meeting agenda in the wiki ahead of the meeting if you want to
15:56:01 <adamw> or send 'em to the list in reply to a meeting thread
15:56:11 <Viking-Ice> yeah
15:56:16 <Viking-Ice> let's move to Josef
15:56:22 <Viking-Ice> and new test day
15:56:23 <Viking-Ice> stuff
15:56:26 <adamw> yup
15:56:31 <adamw> #topic Test Day result tracking
15:56:42 <adamw> I actually put this one in, just as it seemed sensible to discuss it after the list thread
15:56:56 <Viking-Ice> for the first is it ready ( enough )
15:57:18 <tflink> Viking-Ice: define ready
15:57:21 <Viking-Ice> of so let's move all activity to it, if not let's stick with the wiki until it's  ready
15:57:27 <adamw> so it was suggested on the list - https://lists.fedoraproject.org/pipermail/test/2013-October/118284.html - that we 'stop using the wiki' for tracking test day results
15:57:41 <Viking-Ice> tflink, on par with wiki usage or better
15:58:01 <adamw> atodorov had used the little tool jskladan wrote to track results for a test day, and liked it much more than the wiki, so he suggested we push it more heavily as the default for test days in future
15:58:02 <tflink> Viking-Ice: I meant ready for what - do all result tracking or just test days
15:58:06 <adamw> as of right now it kinda exists and has been used
15:58:11 <adamw> tflink: for now i was figuring just test days
15:58:17 <adamw> tracking validation test results is a bit different
15:58:23 <adamw> it seems to be a nice fit for test days, though
15:58:32 <tflink> IIRC, the original idea was to ease transition into something different
15:58:43 * adamw doesn't remember for sure
15:58:46 <tflink> so the test day app could record results in a better way and dump everything to wiki format
15:58:48 <adamw> jskladan: still there?
15:58:56 <Viking-Ice> well I dont think we should disrupt that release workflow in the midst of the cycle
15:59:13 <adamw> still, if it's better than the wiki right now, we can certainly consider it, and using it might encourage work on something even better
15:59:15 <tflink> that way we could have a better way to record results while maintaining the same method for historical results
15:59:17 <roshi> use of that app for the GNOME test day was smooth
15:59:30 <tflink> Viking-Ice: it's not a new tool, it's been around for a while just not discussed all that much
15:59:59 <tflink> IIRC, it came out of some issues in the F18 power management test day during devconf that year
16:00:05 <adamw> well, there's various ways we could do it
16:00:14 <adamw> we could simply update the test day SOP to encourage using the app for tracking results
16:00:38 <jskladan> adamw: sorry, I got distracted by dinner (bad me)
16:00:39 <adamw> and then whoever's looking after test days for F21 could make sure the person running each test day is aware of it
16:00:45 <adamw> you're not allowed to eat!
16:00:45 <tflink> I'm not a huge fan of supporting it in any official capacity in it's current state, though; it's a TG2 app
16:00:59 <tflink> s/any/much of any/
16:01:12 <adamw> what's the implication of that, for us monkeys? :)
16:01:17 <adamw> TG2 = TurboGears 2, right?
16:01:27 <tflink> it's a web framework that we don't have much experience with
16:01:38 <Viking-Ice> let´ s swap it out for test days, see how it turns out and shapes then consider it swapping it out tracking validation test results next cycle
16:02:15 <jskladan> tflink: adamw: Viking-Ice: it's in no shape to track validation - it was not designed to do that, and validation IMHO needs a bit different approach
16:02:32 <adamw> right, for now i was only thinking about test days
16:02:44 <tflink> jskladan: yeah, sorry if it sounds like I was implying anything outside that
16:02:46 <adamw> it seems to be written specifically to the test day workflow, right? it seems like a nice fit for that
16:02:48 <jskladan> I've put together some short wiki page: https://fedoraproject.org/wiki/User:Jskladan/Sandbox:TestdayApp
16:02:58 <Viking-Ice> anyone against swapping this out for testday raise your hand ?
16:02:58 <roshi> it's an easy enough thing to add to the test day SOP - and it works
16:02:58 <jskladan> on how things work
16:03:07 <jskladan> adamw: yup
16:03:10 <roshi> +1 for test day usage
16:03:12 <adamw> #info jskladan wrote a webapp for tracking test day results that is documented at https://fedoraproject.org/wiki/User:Jskladan/Sandbox:TestdayApp
16:03:32 * adamw is +1 in principle, but at least it should probably live on a Real System in a recognized fedora domain rather than an IP address, if that's not too difficult
16:03:37 <adamw> and only for test days
16:03:55 <tflink> it should be available at testdays.cloud.fedoraproject.org
16:03:57 <jskladan> adamw: it lives on http://testdays.qa.fedoraproject.org/testdays/all_events
16:04:13 <adamw> OK cool - when i looked the test day page was using an IP address link, iirc
16:04:16 <adamw> awesome, that seems fine
16:04:18 <Viking-Ice> +1 test day usage ( and placed somewhere under qa.fedoraproject.org/<test_day or similar )
16:04:21 <jskladan> the ip is a residue from the old times
16:04:25 <adamw> roger
16:04:35 <tflink> but I do have some concerns about it being in the cloud, not being backed up and being managed by hand
16:04:48 <adamw> tflink: well, in the end the idea is that the results are copied back into the test day page, right?
16:04:53 <adamw> that's why it spits them out in wiki format
16:05:00 <tflink> if the lifetime of the data is only a couple of days, I'm much less concerned
16:05:02 <adamw> if we do that, then the risk of breakage doesn't seem too terrible
16:05:19 <adamw> it doesn't matter if it breaks outside of a test day being 'active' and we don't lose the data from previous test days if it does
16:05:29 <Viking-Ice> let's keep it under qa.fedoraproject.org as opposed to it's own domain we want the same landing page for all qa community members ( I would think )
16:05:40 <adamw> Viking-Ice: sure, that domain is fine, i was just worried about it being an ip address
16:05:40 <tflink> Viking-Ice: that's not possible for the short term
16:06:01 <adamw> oh, i thought  by 'under' viking meant a subdomain, i.e. the way it is
16:06:01 <Viking-Ice> tflink, ?
16:06:04 <tflink> I can go through infra policy and details for why that can't happen if you'd like but I think that's out of scope for this meeting
16:06:21 <adamw> testdays.qa.fp.o is 'under' qa.fp.o as I see it
16:06:35 <tflink> adamw: it's testdays.cloud.fedoraproject.org
16:06:47 <adamw> <jskladan> adamw: it lives on http://testdays.qa.fedoraproject.org/testdays/all_events
16:06:51 <tflink> nvm, I forgot that josef got around the normal policy :)
16:07:02 <adamw> seems to work
16:07:03 <adamw> :P
16:07:05 <Viking-Ice> tflink, we should be able to fake the actual address ( proxypass rewrite rules what not )
16:07:19 <adamw> I think we're ok there, sorry for the confusion :)
16:07:23 <tflink> Viking-Ice: you mean to use something like qa.fedoraproject.org/testdays/... ?
16:07:30 <Viking-Ice> tflink, yes
16:07:40 <adamw> *sigh*
16:07:53 <Viking-Ice> anywho that's technical
16:07:55 <tflink> Viking-Ice: that can't happen for other reasons, but we're off topic for an over time meeting
16:08:15 <adamw> i think we're just crossing wires and everyone is actually fine with  http://testdays.qa.fedoraproject.org/
16:08:18 <adamw> but let me know if i'm wrong
16:08:34 <adamw> i may have sounded like i was proposing moving it,  but I wasn't; tflink thought it wasn't available there, but it is. that's my current understanding.
16:08:38 <Viking-Ice> that's another topic
16:08:40 <adamw> OK
16:08:42 <adamw> for now:
16:08:51 <Viking-Ice> let's agree with switching to start using it
16:09:01 <Viking-Ice> for test days
16:09:07 <roshi> +1
16:09:07 <jreznik> it's not IP adress, lives in qa space, so pretty good for me
16:09:11 <jreznik> +1
16:09:16 <adamw> proposed #agreed we will update the Test Day SOP to encourage use of the webapp at  http://testdays.qa.fedoraproject.org/ for tracking test day results, with the results to be copied back into the test day wiki page within a few days of the end of the test day
16:09:16 <Viking-Ice> +1
16:09:25 <Viking-Ice> ack
16:09:26 <tflink> ack and +1
16:09:29 <roshi> ack
16:09:32 * jskladan is all in
16:09:39 <adamw> awesome
16:09:43 <adamw> #agreed we will update the Test Day SOP to encourage use of the webapp at  http://testdays.qa.fedoraproject.org/ for tracking test day results, with the results to be copied back into the test day wiki page within a few days of the end of the test day
16:09:49 <adamw> big vote of thanks to jskladan for the app
16:10:04 <adamw> does anyone want to take an action to update the SOP? roshi?
16:10:51 <roshi> I got it :)
16:11:07 <adamw> #action roshi will update the Test Day SOP as agreed (encourage use of webapp for tracking test day results)
16:11:21 <adamw> okay, quickly...:)
16:11:24 <adamw> #topic Open floor
16:11:30 <adamw> anything vitally important that we missed?
16:11:35 <satellit> 1015731 is still listed as proposed FE (sugar) I thought it was voted on last time to be accepted at the end of the meeting .https://qa.fedoraproject.org/blockerbugs/milestone/20/beta/buglist
16:11:43 <satellit> but looks removed now
16:11:56 <tflink> .bug 1015731
16:11:59 <zodbot> tflink: Bug 1015731 netinstall f20 Beta TC-1 x86_64 of sugar-desktop boots to console login - https://bugzilla.redhat.com/show_bug.cgi?id=1015731
16:12:19 <tflink> satellit: it was closed
16:12:46 <satellit> this is not livesoas but install from netinatall of sugar-desktop  diferent
16:12:54 <tflink> I just deployed a fix to the blocker tracking app to remove closed bugs from the lists
16:13:03 <satellit> ?
16:13:12 <tflink> satellit: the bug is CLOSED NEXTRELEASE
16:13:31 <tflink> so it should be fixed
16:13:55 <satellit> ok so sugar-desktop works in TC4?  have not tested yet
16:14:05 <adamw> depends on the exact status of the fix i guess
16:14:12 * adamw looks
16:14:41 <tflink> satellit: I'm not sure it's fixed, I was just explaining why it hadn't moved and why it disappeared
16:14:50 <satellit> ok   ok
16:15:17 <satellit> confusion of SoaS live bug and sugar-desktop here?
16:15:26 <adamw> "I was sure I closed this bug. I've added lightdm as a default DM in comps for F-20+ which will fix the problem. It was pushed on Oct 8th so should already be fixed in the latest compose."
16:15:28 <adamw> sounds clear enough
16:15:35 <adamw> so yeah, TC4 should be good, pbrobinson thinks
16:15:48 <satellit> thanks
16:16:04 <jreznik> tflink: thanks for blocker tracking app fix!
16:16:52 <tflink> np, I still don't understand why it stopped working like that but it's fixed now :)
16:18:27 <pbrobinson> adamw: satellit: I added lightdm into the sugar-desktop group as a DM, I dropped gdm from the list a while a go due to issues but the idea was to give people a choice of DM but I missed the "install from anaconda" options without thinking that people wouldn't think to choose a DM so I defaulted to lightdm
16:18:49 <satellit> thanks....
16:19:41 <adamw> satellit: check out TC4 and get back to us :)
16:19:46 <adamw> OK, sounds like that's all
16:19:52 * adamw sets the quantum fuse
16:22:37 <satellit> ok
16:23:56 <robatino> oh, there's no place to put checksum results for Images/i386 and Images/x86_64
16:24:23 <robatino> the install test matrix template needs to be updated
16:26:26 * Martix is here
16:26:30 <Martix> :-P
16:27:05 <robatino> pwhalen pointed it out to me
16:32:48 <adamw> #endmeeting