15:00:24 <jwb> #startmeeting
15:00:24 <zodbot> Meeting started Wed Sep  3 15:00:24 2014 UTC.  The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:24 <jwb> #meetingname workstation
15:00:24 <zodbot> The meeting name has been set to 'workstation'
15:00:25 <jwb> #meetingtopic Workstation WG meeting
15:00:25 <jwb> #topic init
15:00:25 <jwb> #chair jwb mclasen cwickert juhp ryanlerch cschalle kalev ltinkl otaylor
15:00:25 <zodbot> Current chairs: cschalle cwickert juhp jwb kalev ltinkl mclasen otaylor ryanlerch
15:00:32 <jwb> hi all
15:00:35 <jwb> who's around?
15:00:40 * langdon lurking
15:00:42 * mclasen is here
15:00:42 <juhp_> hi
15:00:45 * cwickert is here
15:00:50 <jwb> #chair juhp_
15:00:50 <zodbot> Current chairs: cschalle cwickert juhp juhp_ jwb kalev ltinkl mclasen otaylor ryanlerch
15:00:52 <mclasen> cschalle is moving, so probably not going to be around today
15:00:55 <kalev> hello hello
15:01:01 <jwb> mclasen, what a slacker :)
15:01:16 * cwickert crosses his fingers that we won't have any netsplits this time
15:01:20 <jwb> cwickert, same
15:01:36 <jwb> i think ryanlerch is still on PTO, so he won't be joining us eitehr
15:02:09 <jwb> let's give otaylor and ltinkl just one more minute
15:02:51 <mclasen> owen was in another call earlier, let me poke him
15:02:55 <jwb> ok
15:03:06 <stickster> o/
15:03:26 <jwb> stickster, ?
15:03:43 <jwb> hi otaylor
15:03:43 <stickster> jwb: that was just waving hello. I came in a couple minutes late.
15:03:44 <otaylor> sorry to be late
15:04:01 * satellit listening
15:04:01 <jwb> stickster, ah.  i thought you were raising your hand for a question.  clearly school has started in the US
15:04:04 <stickster> ha
15:04:08 <jwb> ok, let's get rolling
15:04:15 <jwb> #topic net-install for Alpha
15:04:25 <jwb> i think we're up to TC5 now for composes
15:04:25 <kalev> so, I've been fixing this up
15:04:38 <jwb> kalev, excellent.  want to give an overview?
15:04:48 <kalev> right, so when I started it was in a very sad state
15:05:14 <kalev> it would basically just boot an anaconda that only allowed selecting minimal install
15:05:34 <kalev> anaconda on netinstall is a very different beast than what's on the live media
15:05:52 <mclasen> why is that ?
15:05:58 <kalev> and is entirely based on comps groups, whereas on the live media we can do excludes / additions in the kickstart file
15:06:11 <kalev> so the first step to get there was to move all package selection to comps
15:06:25 <kalev> and I've done that now and we have a workstation-product comps group
15:06:35 <mclasen> oh, yes. you mentioned that
15:06:44 <juhp_> kalev, nice
15:06:45 <kalev> so if anyone needs to add / remove packages, do it there and don't add stuff to kickstarts
15:06:52 <jwb> #info kalev has been fixing this up.  created workstation-product comps group
15:07:09 <kalev> and I've adopted the kickstarts to this and it seems to roughly work
15:07:15 <kalev> at least as much as our side is concerned
15:07:30 * juhp_ did a net install with TC5 and it seemed to go reasonably well
15:07:33 <jwb> very nice.  i plan on trying the next compose in a VM for this as well
15:07:36 <kalev> there's still an anaconda / release engineering issue that anaconda doesn't know how to select the right path where to fetch Workstation comps
15:08:05 <mclasen> we should probably document this (need to do all in comps) somewhere - at least with a comment in the .ks file
15:08:06 <kalev> so in practice it doesn't really work, but I believe releng and anaconda folks are looking into it
15:08:21 <kalev> I'll make sure we have a comment there
15:08:30 <jwb> #info anaconda/rel-eng looking into comps path issue
15:08:49 <otaylor> kalev: Are there other things that the kickstart does these days that the netinstall will miss?
15:09:03 <jwb> #action kalev to add comment in Workstation ks files to add packages to comps group instead
15:09:11 <kalev> there are some minor differences
15:09:33 <kalev> one is that the live media includes anaconda and all its dependencies and it's also installed to end user systems; netinstall doesn't pull in anaconda
15:09:46 <jwb> kinda nice
15:09:48 <kalev> and netinstall has like 3-4 extra packages that are related to language support, like hunspell-en or something
15:09:57 <kalev> I don't remember the exact names, was very minor
15:10:06 <elad661> kalev: I guess we want hunspell-en on live too
15:10:33 <mclasen> kalev: I've always considered that (anaconda left behind) a flaw of live installs
15:10:34 <cwickert> kalev: do we know where hunspell is coming from? is it a dependency or a default in some other comps group`
15:10:35 <cwickert> ?
15:11:08 <kalev> mclasen: yes, would be very nice to have a two-layer setup on the live media where anaconda lives in a separate overlay or something so it's not pulled in to the final install
15:11:18 <cwickert> mclasen: it definitely is, same for the spins and their guidelines, but too late to change it for F21 I guess
15:11:50 <kalev> cwickert: not sure where it comes from, I think the depsolvers that are used on live media and the one in anaconda are different
15:12:07 <cwickert> I see, thanks kalev, great work
15:12:10 <elad661> I think live still uses yum
15:12:11 <jwb> kalev, do you need help with anything in particular for netinstall at this point?
15:12:12 <kalev> it might be that anaconda has its own, DNF based depsolver and livemedia-creator uses yum, or something
15:12:16 <juhp_> mclasen, +1
15:12:21 <kalev> and anaconda based pulls in some extra packages
15:12:39 <kalev> jwb: no, everything is done from our side as much as I'm concerned
15:12:50 <mclasen> kalev: well done
15:12:55 <elad661> well done indeed!
15:13:12 <juhp_> I should be possible to post-remove anaconda, no?
15:13:14 <jwb> kalev, awesome.  big thank you for just going and getting this done
15:13:18 <juhp_> erm it should *
15:13:27 <elad661> juhp_: not in a clean way
15:13:29 <stickster> kalev++
15:13:32 <juhp_> hm
15:14:21 <jwb> #info follow up with ways to remove anaconda from the set of packages installed in the final live image
15:14:31 <mclasen> anything more to discuss on netinstall, or move on ?
15:14:37 <jwb> ok, we can all think about this a bit.  probably not an F21 item
15:14:41 <jwb> mclasen, yeah, let's move on
15:14:49 <kalev> nothing more from me
15:14:52 <jwb> #topic Workstation Marketing/Release notes
15:15:06 <jwb> so cshalle sent some marketing notes to the WG this week
15:15:23 <jwb> i thought they were well written, and Pete Travis from the docs/marketing team seemed to agree
15:15:30 <jwb> did everyone get a chance to read them over?
15:15:39 <juhp_> jwb, +1
15:15:43 * kalev hasn't read it yet.
15:16:37 <jwb> when you get a chance, please read them over and reply if you have concerns/additions
15:16:41 * cwickert likes them
15:16:49 <mclasen> did cschalle forward it to the list ?
15:16:54 <jwb> not yet
15:16:56 <cwickert> I don't think so
15:17:03 <mclasen> ah, ok
15:17:04 <cwickert> only the WG members so far
15:17:08 * mclasen goes to dig in another folder
15:17:26 <jwb> so related to this, we have a couple things concerning release notes
15:17:36 <jwb> they are, in no particular order:
15:17:37 * randomuser perks up
15:17:41 <jwb> 1) hardware requirements
15:17:59 <jwb> 2) included in default install or not (and where)
15:18:16 <jwb> 3) do we want each product to have it's own release announcement?
15:18:44 <jwb> let's start with hardware requirements/suggestions
15:19:03 <otaylor> Can someone summarize what the current proposal is for hardware requirements?
15:19:10 <juhp_> f21 seems a bit more memory hungry than f20?
15:19:17 <elad661> so 1GB is good enough for extremely minimal usage in a VM, but not installation as reported on the list, so I suggest 1.5GB minimal?
15:19:17 * stickster mentions jzb so he can lurk if desired, since we're talking about release announcement/notes
15:19:42 <juhp_> elad661, ok
15:19:53 <jwb> elad661, i was thinking the same.  1.5GB minimum, 2GB+ recommended
15:20:08 <elad661> is 1.5GB enough for installation? did anyone test that?
15:20:17 <elad661> I tested with 2GB in a vm and it runs smooth
15:20:25 <jwb> i can test that with the next compose
15:20:34 <randomuser> I'm *tempted* to say a recommend of 4GB - for a "workstation" that seems modest
15:20:35 <juhp_> me too
15:20:46 <juhp_> (testing)
15:20:54 <elad661> it works *well* with 2GB
15:20:56 <randomuser> ...but almost exclusionary
15:21:46 <jwb> 2GB does seem to work well generally.  we can always phrase it as "recommend 2GB or more"
15:22:01 <otaylor> randomuser: I  sort of agree, but am a little worried about sounding like we're exceptionally heavy - while the 4GB really just reflects modern websites and browsers and usage patterns
15:22:01 <elad661> jwb++
15:22:15 <stickster> jwb++
15:22:25 <jwb> i think that should mostly cover the DRAM recommendations.  do we want to suggest particular CPU families?
15:22:26 <elad661> most people will have 4GB anyway, if you recommend 4GB they'll think you're really bloated
15:22:32 <jwb> elad661, right
15:22:39 <randomuser> otaylor, it's more to the point about the overall *type* of system that comes with 4GB out of the box
15:22:48 <jwb> on CPU... i'd rather not even suggest a 32-bit CPU
15:22:56 <mclasen> elad661: works well for the bare desktop, or while using apps
15:22:56 <stickster> +1 that too
15:23:10 <elad661> yeah, we don't want people using Workstation on 32bit if they can avoid that
15:23:16 <juhp_> sure 4GB is fine for bare metal but not for guests so much
15:23:29 <randomuser> the generic 'more is better' copy will still be there, fwiw
15:23:35 <elad661> yeah but we're not telling users they can virtualize on 4GB
15:23:52 <jwb> elad661, erm... we're not telling them they can't either
15:23:55 <jwb> so they'll assume they can
15:24:17 <elad661> okay so let's add something: if you want to use Boxes, it is recommended to have more than 4GB of RAM
15:24:20 <elad661> or something like this
15:24:35 <otaylor> elad661: I don't think that's necessary
15:24:38 <elad661> to clarify virtualization is heavy, but the system is quite light compared to competitors
15:24:51 <randomuser> on the virt environment: i'm in favor of jwb's point about recommending a spice/qxl situation (presumably boxes does that?) and not addressing unsupported platforms
15:24:54 <otaylor> elad661: Even fedora+fedora is OK with 4GB if you need to
15:25:07 <jwb> otaylor, i agree.  i've done that many times
15:25:08 <randomuser> ksmd ftw!
15:25:09 <juhp_> (I just meant that I don't want to use 4GB guests normally:)
15:25:29 <jwb> multiple VMs on a 4GB host gets painful, but a single VM running at a time is generally ok
15:25:40 <otaylor> elad661: The recomemndations should talk about using Fedora on bare metal or a  guest- using fedora as a host for VM's is "app usage"
15:26:22 <juhp_> anyway +1 for "2GB+ recommended"
15:26:27 <mclasen> thats normally understood, right: "with more required depending on the used applications"
15:26:27 <cwickert> I did run it in a 2 GB netbook and the result was fine, so I suggest "2 GB or more".
15:26:36 <juhp_> right
15:26:47 * mclasen is using 2GB for his test vms regularly, so +1
15:26:50 <otaylor> jwb: So we want to say "64-bit CPU recommended" ?
15:26:59 <jwb> otaylor, i'd like to say that
15:27:17 <otaylor> jwb: That seems fine to me - if we think 4GB or more  is optimial, people shoudln't need to reinstall if they add more memory
15:27:45 <cwickert> do we need to make a recommendation for the architecture? I mean, 32bis is dying anyways
15:27:52 <otaylor> jwb: just recommending 64-bit also is good in keeping things simple
15:28:08 <jwb> cwickert, not fast enough
15:28:18 <cwickert> jwb: true that :)
15:28:40 <jwb> ok, so 2GB for DRAM, 64-bit CPU recommended
15:28:40 * mclasen is +1 on '64-bit recommended' too
15:28:47 <jwb> anyone have objections to either of those?
15:28:49 <juhp_> so probably the main WS download page might only link directly to 64bit images
15:29:04 <elad661> juhp_: yes, and with a smaller link for 32bit
15:29:05 <jwb> juhp_, yes, we can definitely look at that
15:29:26 <juhp_> okay
15:29:35 <elad661> I mean as long as we generate 32bit image there's no point hiding it
15:29:45 <juhp_> sure
15:29:54 <kalev> I would want to have a single download on the main page
15:30:00 <jwb> #agreed 2GB+ DRAM, 64-bit CPU recommended for hardware requirements
15:30:02 <kalev> like Get Workstation Here
15:30:03 <elad661> kalev: sure
15:30:15 <elad661> if we want to drop 32bit completely I'm all for it, but not for this cycle
15:30:32 <randomuser> There *is* still a residual stigma about 64bit incompatibility, an explicit recommends seems reasonable to me
15:30:49 <jwb> incompatibility?
15:30:52 <randomuser> plus, i think websites will be making 64bit the default offer
15:31:05 <elad661> randomuser: 64 has been default for a while
15:31:08 <juhp_> kalev, right that sounds attractive - and maybe an "Other downloads" page
15:31:13 <juhp_> elad661, +1
15:31:21 <randomuser> jwb, I don't pretend to support these misconceptions or understand them, just observe people's behavior
15:31:29 <langdon> what about VMs? Is the recco 64bit? or 32bit?
15:31:46 <elad661> langdon: 64bit still, I think
15:31:49 <jwb> langdon, "don't care but 64bit"
15:32:12 <jwb> people that want to use 32-bit VMs to avoid python memory usage overhead aren't going to be installing Workstation in their VM
15:32:14 * randomuser would also like guidance on the storage footprint recommendations, but it could go back to the list if meeting time is short
15:32:18 <juhp_> langdon, for WS I would say the same applies
15:32:31 <langdon> ok.. no particular opinion but i feel like most of the inter-tubes still seems to suggest 32bit for VMs in general..
15:32:33 <otaylor> langdon: I think it's 64-bit for simplicity - though it would be interesting to know if there is a signfiicant difference in free memory booting a 32-bit or 64-bit image in a 2GB vm
15:32:57 <elad661> we need to test this
15:32:59 <jwb> langdon, yes.  except most of the intertube VMs aren't running desktop systems in them.
15:33:33 <langdon> jwb: point
15:33:36 <juhp_> otaylor, +1
15:33:51 <jwb> #info recommendations for VMs are also 64-bit
15:33:52 <langdon> and +1 to otaylor
15:34:02 <jwb> otaylor, care to follow up on that?
15:34:18 <otaylor> jwb: I can, yes
15:34:21 <jwb> otaylor, great, thanks
15:34:42 <jwb> #action otaylor to compare memory differences between 32 and 64-bit VMs
15:35:01 <jwb> randomuser, can we take the storage recs to the list?  save us some time here
15:35:09 <randomuser> yes, that would be great
15:35:12 <jwb> ok
15:35:20 * elad661 can do some testing wrt storage
15:35:26 <jwb> elad661, that would be great
15:35:41 <jwb> #action elad661 to do some testing for storage recommendations
15:35:51 <jwb> ok, subitem 2) whither to install release notes
15:36:05 <jwb> i honestly don't know where the list discussion landed on this
15:36:20 <elad661> There was some suggestion to have them as PDFs on the ISO itself
15:36:25 <elad661> instead of the installed system
15:36:38 <elad661> that would make them available offline and also for people before they actually boot the system
15:36:58 <jwb> randomuser, how difficult would that be?
15:37:33 <randomuser> jwb, from my perspective, it isn't difficult to provide a PDF; publican can output lots of formats
15:37:45 <randomuser> we'd have to ask releng about putting it on the media, though
15:37:48 <stickster> yup
15:38:01 <jwb> or we could simply package it
15:38:07 <jwb> in fedora-release-workstation
15:38:07 <mclasen> how difficult is it to squeeze content 'under the crust' of the .iso like that ?
15:38:20 <stickster> dgilmore could tell us if he's around.
15:38:20 <jwb> mclasen, if it's in a package, very
15:38:21 <otaylor> And if we do that,are tehy going to be available from the booted live image?
15:38:31 <randomuser> I still maintain that providing rhe release notes prominently in the product will be a valuable thing for Workstation users that want information about their newly installed product
15:38:40 <elad661> I don't think tehy need to be available from the booted image
15:39:07 <stickster> I don't think it's any more valuable than just having it as a delivered bookmark/open tab in the browser
15:39:13 <otaylor> randomuser: In general, wouldn't we prefer that people got to them live on the internet rather than a canned copy?
15:39:14 <juhp_> I guess they are handy if offline...
15:39:50 <jwb> i have no overwhelming opinion, but if i was installing something new i'm much more likely to read about it _before_ i actually install it
15:39:53 <mclasen> do we have any data on whether people regularly consult the release notes ?
15:40:06 <randomuser> otaylor, I just prefer that people get them, period. The delivery mechanism isn't *that* important...
15:40:11 * mclasen personally admits to 'never ever'
15:40:30 <elad661> randomuser: they will be visible prominently on the website
15:40:39 <randomuser> but I can say [colloquially] that people regularly have issues or questions that would have been avoided if they had read the release notes
15:40:47 <jwb> lol
15:40:54 <randomuser> which suggests to me that people should be reading the release notes
15:40:58 <elad661> yeah, well, having them visible won't make people read them
15:41:04 <jwb> "you can lead a horse to water..."
15:41:10 <randomuser> removing an exposure vector won't help there
15:41:12 <stickster> it also suggests to me that going through a lot of effort to put them on the media or in packaging is not well spent.
15:41:18 <elad661> randomuser: it also won't harm
15:41:42 <elad661> if your system is installed and working you probably don't need the release notes, I think
15:41:47 <jwb> so does someone have a concrete suggestion/proposal?  perhaps something like "include a bookmark to the release notes in firefox"?
15:41:51 <stickster> randomuser: however, making it plainer where to find them at the time people download the product, including an easy PDF download link, would be more useful.
15:41:55 <randomuser> stickster, well, that too, but tagging the git repo and bumping the spec isn't exactly a trying endeavor.
15:41:57 <elad661> jwb: we already do include the bookmark
15:42:03 <elad661> afaik
15:42:13 <jwb> elad661, shows how often i read them...  /me runs away sheepishly
15:42:45 <randomuser> stickster, point. I'll update my copy of stg.fp.o and talk to websites about it
15:43:14 <jwb> ok, so we're at "don't install them in the Workstation images" now, correct?
15:43:28 <stickster> that sounds like the right proposal
15:43:42 <elad661> randomuser: I'm implementing the re-design of the start page now, there will be a link to "get help" there, very big one, clicking on it would lead to a page which would show a link to the release notes
15:43:46 <cwickert> I don't care if they are installed or not, as long as they are easy to find
15:44:00 <elad661> I think that would give them decent exposure
15:44:00 <jwb> ok, so let's go with that
15:44:17 <jwb> #agreed don't install the release notes in the workstation images.  work with docs and websites to make them easy to find
15:44:47 <jwb> subitem 3) do we think we need separate release announcements for each product?
15:45:06 <jwb> e.g. one big F21 release announce for each milestone, or 3 separate ones
15:45:16 <elad661> jwb: just fyi we'd need to talk with QA to remove "installing the release notes" from the final criteria
15:45:20 <cwickert> elad661: that would at least be firing up a browser, two clicks and looking. I think this is already a big setback compared to now.
15:45:34 <jwb> elad661, ok, i'll amend to include that
15:45:42 <elad661> cwickert: most users won't know "release notes" means "help"
15:45:43 <otaylor> jwb: I prefer separate release announcements
15:46:05 <otaylor> jwb: A unified release announcement is inevitably going to spend a whole lot of time on features that aren't relevant to workstation users
15:46:17 <juhp_> right
15:46:19 <jwb> otaylor, i'm leaning that way as well
15:46:20 <mclasen> you can probably have an 'umbrella' announcement
15:46:27 <juhp_> yes
15:46:31 <mclasen> that just refers to the individual product announcements
15:46:33 <elad661> Have a big announcement linking to more detailed ones
15:46:37 <elad661> yes
15:46:37 <randomuser> alpha/beta announcements are typically terse; if there's a split announcement, it should probably happen only for GA
15:46:43 <cwickert> elad661: but most users wouldn't know that "help" also means "release notes". In fact, "Help" assumes you are having a problem, while release notes are general information.
15:46:55 <juhp_> randomuser, that sounds okay
15:47:09 <elad661> cwickert: when is the last time you used the release notes launcher?
15:47:29 <elad661> Do you *actually* use it?
15:47:37 <cwickert> elad661: yes, after I installed F20
15:47:40 <elad661> randomuser: I agree
15:47:45 <otaylor> randomuser: I think mostly that when we have a release annoncement that goes into marketing about why you care about this, it has to be product specific
15:47:45 <cwickert> in fact I just used it yesterday
15:47:54 <elad661> cwickert: you're very special then, most people I talk with don't ever click on it
15:47:56 <randomuser> hopefully *someone* used it to test the new desktop file :P
15:48:07 <elad661> randomuser: I did, and filed a bug too
15:48:11 * stickster notes, everyone here is special, so nothing we personally do is really a good test case for "most users"
15:48:33 <juhp_> true
15:48:41 <elad661> yep
15:49:02 <elad661> Okay so back to the topic on hand, separate release announcements for GA, shared for alpha and beta?
15:49:12 <jwb> so: umbrella announcement that points to separate product announcements for final release.  shared for alpha/beta
15:49:18 <stickster> jzb: Does that agree with current plans for release announcements? ^
15:49:19 <juhp_> elad661, I think it is a good approach
15:49:25 <elad661> jwb++
15:49:31 <juhp_> jwb, +1
15:49:34 * mclasen tries to find the release notes bookmark in firefox, not easy
15:49:38 * stickster not sure if Marketing is thinking about this, looking for our recommendation, or what
15:49:57 <jwb> stickster, jreznik asked we discuss it because it was raised on the marketing list
15:49:58 <randomuser> I think Marketing would welcome recommendations in any context
15:49:58 <cwickert> mclasen: +1, not intuitive
15:50:04 <stickster> jwb: ah, right on
15:50:12 <elad661> cwickert: I'll include a direct link in the start page for the first month after GA
15:50:22 * jreznik is reading
15:50:27 <cwickert> elad661: fair enough, but "most people" is very vague. my point is: when you proposed the removal of the launcher, you said the release notes would be linked from start.fpo. and get.fpo. Now you say they will be linked from another help document, that is yet to be done.
15:50:27 <elad661> cwickert: like we did on the main page of fedoraproject.org before
15:50:32 <elad661> is that good?
15:50:38 <elad661> Like, it's orange and it sticks out
15:50:40 <mclasen> if we want to make a bookmark findable, it probably has to be in the 'new tab' grid at least
15:50:45 <elad661> we call it "the newsbar" in websites
15:50:48 <stickster> mclasen++
15:51:14 <jreznik> stickster: yes, it's discussed on marketing list, so when I saw agenda for this meeting, it was best place to ask
15:51:22 * randomuser would be happy do discuss a replacement presentation of the RNs on the list
15:51:25 <cwickert> elad661: I've heard at least 3 different statements from you now. please come up with a propsal, or even better with a draft. try to get a buy in from docs before we make a decision. ok?
15:51:28 <jwb> we have 10min left.  i'd like to get to the image viewer topic if we can
15:51:29 <juhp_> mclasen, good idea
15:52:09 * mclasen drops his random musings about bookmarks and sits straight
15:52:17 <jwb> does anyone have any issues with the release announcement proposal?
15:52:19 <jwb> which was:
15:52:20 <elad661> cwickert: Okay, let me rephrase: direct link from get.fpo, plus extra link from help page, and a very very prominent link from start.fpo for the first month in addition to the link from the help page
15:52:21 <jwb> so: umbrella announcement that points to separate product announcements for final release.  shared for alpha/beta
15:52:28 <jreznik> jwb: umbrella announcement with separate announcement for final and share alpha/beta makes sense for me (especially during alpha/beta time there's not much time to prepare real big announcement)
15:52:38 <cwickert> jwb: +1
15:52:43 <mclasen> +1
15:52:43 <otaylor> jwb: +1
15:52:51 <juhp_> +1
15:53:08 <kalev> sure, +1
15:53:10 <jwb> #agreed umbrella announcement that points to separate product announcements for final release.  shared for alpha/beta
15:53:21 <jwb> ok, let's move on to the image viewer topic
15:53:25 <jwb> #topic Default image viewer
15:53:26 <cwickert> elad661: lets discuss it on the list when you come up with a concrete proposal.
15:53:33 * jreznik is going to reply with it to the marketing list, thanks jwb
15:53:37 <jwb> jreznik, np
15:53:38 * cwickert is in favor of eog
15:53:40 <jwb> so image viewer
15:54:00 <jwb> cwickert, i agree.  we stick with eog for now, and we can look at switching to gthumb or gphotos for f22
15:54:01 <cwickert> what is developed more actively?
15:54:10 <cwickert> jwb: sounds good
15:54:16 <elad661> If eog is installed by default and it's not the default handler, it's doing nothing
15:54:27 <cwickert> good point, elad661
15:54:28 <jwb> elad661, right
15:54:36 <elad661> right now shotwell is the default handler
15:54:41 <elad661> and both are installed by default
15:54:58 <jwb> i think, after reading the thread 3 times, most people seemed to agree shotwell wasn't well suited to this
15:55:15 <elad661> okay, but there was also the concern of "changing the defaults too often"
15:55:18 <kalev> one thing I would like to avoid is changing image viewers every cycle
15:55:24 <kalev> what elad661 said :)
15:55:51 <elad661> but I also like to think of F21 as starting fresh with a whole lot of polish
15:56:16 <mclasen> what was the other image viewer we would switch to in f22 ?
15:56:20 <jwb> eog was the default a while ago.  i view it more as a return to simplicity while we wait for gthumb/gphotos
15:56:41 <elad661> mclasen: Photos, probably?
15:56:49 <jwb> yeah, Photos
15:56:55 <elad661> when Allan says it's ready :)
15:56:56 <otaylor> I certainly don't think switching to gthumb makes sense if F22 isn't clear for what we want as a manager app.
15:56:56 <jwb> sorry, that's what i meant by gphotos
15:57:06 <jwb> otaylor, right
15:57:39 <mclasen> I'm afraid that photos will probably end up with a similar poor fit than shotwell
15:57:49 <otaylor> There doesn't seem to be a ton of difference between eog and shotwell actually if you run them on a jpg - shotwell seems to start in some sort of viewer mode
15:58:18 <otaylor> But the existence of that viewer mode in itself is a bit confusing - your running shotwell, but where are all the management features?
15:58:57 <jwb> right.  and i think mizmo had mentioned something about eog being easier to "flip through" with a number of photos
15:59:42 <mclasen> owen: 'not a lot of difference' is that an argument in favor of switching (since most people won't notice) or against (because not a lot of win) ?
16:00:03 <jwb> if we switch, it's one less package installed by default and a smaller image
16:00:14 <jwb> (mabye)
16:00:20 <otaylor> mclasen: I think it was a weak argument against - it's not like we throw a manager app when you double click on a photo
16:00:45 <jwb> otaylor, so you're arguing for leaving things as they are and revisiting for f22?
16:00:47 <otaylor> jwb: Is te proposal to not install shotwell, or just switch the default view action?
16:01:03 <jwb> otaylor, i guess that's up for discussion too.  let's settle on the default first :)
16:01:07 <otaylor> jwb: I think I'm actually in favor of switching the default to eog but leaving shotwell installed, and revisiting for f22
16:01:15 <elad661> otaylor++
16:01:26 <elad661> I think it makes sense.
16:01:46 <jwb> i agree as well
16:01:51 <juhp_> sounds okay
16:01:53 <jwb> anyone care to differ?
16:01:59 <mclasen> I care to concur
16:02:04 <stickster> heh
16:02:08 <kalev> sure, sounds like a plan
16:02:30 <jwb> cwickert, want to weigh in?
16:02:36 <jwb> we're at 2min over, but we're soooo close
16:02:44 <elad661> yeah just this one last thing
16:03:04 <cwickert> jwb: sorry, I already did.
16:03:14 <elad661> you did?
16:03:17 <jwb> oh, he did
16:03:22 <jwb> basically he agreed at the start
16:03:24 <cwickert> I said I am in favor of eog
16:03:25 <jwb> so yay
16:03:40 <elad661> okay, all done then :)
16:03:41 <cwickert> and I think we can remove shotwell, but I don't really care
16:03:48 <jwb> #agreed switch default image viewer to eog but leave shotwell installed.  revisit for F22
16:03:54 <jwb> WHEW
16:03:56 <elad661> cwickert: I think it's just bikeshedding at this point (removing or not)
16:03:59 <cwickert> :)
16:04:12 <jwb> ok, that was actually productive.  amazing what functioning irc can provide
16:04:27 <jwb> thanks for coming everyone.  we'll end for today and be back on the regular schedule next week
16:04:37 <juhp_> thanks jwb
16:04:37 <kalev> do we have a meeting next week?
16:04:37 <mclasen> yep, that was a good meeting, thanks
16:04:41 <jwb> kalev, we do
16:04:45 <kalev> ok
16:04:51 <jwb> kalev, today was a one-off to cover stuff we should have gotten to last week
16:05:03 * kalev goes to drop release notes from the image.
16:05:14 <jwb> thanks again everyone
16:05:16 <jwb> #endmeeting