15:00:01 #startmeeting Workstation WG (special timeslot) 15:00:01 Meeting started Wed May 27 15:00:01 2015 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:05 #meetingname workstation 15:00:05 The meeting name has been set to 'workstation' 15:00:07 * mclasen is here 15:00:08 #topic Roll call 15:00:26 * mcatanzaro is here 15:00:31 * kalev rolls in. 15:00:32 .hello pfrields 15:00:33 stickster: pfrields 'Paul W. Frields' 15:01:43 cschalle: juhp: rdieter: jwb: otaylor: ryanlerch: ^^ 15:01:51 hm? 15:01:54 oh 15:01:55 hi 15:02:04 #chair mclasen mcatanzaro kalev jwb rdieter cschalle 15:02:04 Current chairs: cschalle jwb kalev mcatanzaro mclasen rdieter stickster 15:02:15 jwb: In case you're interested. Hey! It's not Cloud. 15:02:29 .hello rdieter 15:02:30 rdieter: rdieter 'Rex Dieter' 15:02:32 #chair juhp 15:02:32 Current chairs: cschalle juhp jwb kalev mcatanzaro mclasen rdieter stickster 15:02:59 mcatanzaro: Thank you for sending topics to list. I plead insanity this week. 15:03:18 #topic Special time slot 15:03:38 #info This slot will not be repeated; next meeting is Monday 2015-Jun-08 at 1300 UTC 15:04:02 #topic F23/24 plans 15:04:43 #link https://fedorahosted.org/council/ticket/27 15:06:06 I'm not aware of any proposed changes to the PRD? 15:06:09 So the Fedora Council is looking to understand plans for F23/24 from the different working groups. I'm not sure how this fits the plan for Council to develop objectives under which different Fedora teams can direct efforts, but hey, having a plan is still good. 15:06:41 mcatanzaro: No, we haven't proposed any (yet) 15:07:41 But the PRD has a number of far-reaching objectives that I'd say we really haven't made substantial progress, although there are relevant things happening upstream 15:07:42 here now - sorry to be late! 15:07:46 #chair otaylor 15:07:46 Current chairs: cschalle juhp jwb kalev mcatanzaro mclasen otaylor rdieter stickster 15:07:49 no problem :-) 15:08:31 I think there are some pending actions from last meeting toward this and unfortunately I've been too swamped to sit and think up wiki pages to describe 15:09:12 * stickster tired of talking and decides to shut up and let other people discuss and throw tomatoes. 15:10:07 I agree that we've not really made too much inroads on some of the 'plans and policies' 15:10:10 One last point though -- many of those deliverables are highly related to non-WS work like release engineering, and a good deal of my effort the last couple weeks has been trying to help in different ways to pave the way for that 15:11:43 mclasen: Yes, that's the part of the PRD I was referring to. But also, I think we need to have a concept of which kind of use case "wins" when we're discussing whether/how to make certain changes, if conflicts come up 15:13:35 conflicts ? do you have any example ? 15:13:40 I've frequently seen comments along the lines of "Workstation is for developers, do you really expect a developer to not understand xyz, therefore do zyx which GNOME developers don't want." 15:13:49 I've noted there is sometimes tension (although constructive, I think) about whether we're trying to e.g. make minimal/no changes to upstream GNOME and ship that, or additionally build and promote an end-to-end solution that builds on top of it (for e.g. developers) 15:14:43 ok 15:14:48 I think stickster and I have noticed the same thing, he just phrases it more politely. :) 15:14:57 that would be a conflict if 'ship pristine upstream gnome 15:14:59 That being said... it's important to understand there's a lot of "90% cases"... where solving a problem really helps *everyone* 15:15:01 was a usecase 15:18:06 looking at the PRD it is a bit 'handwavy' but I think we did that on purpose, with the so called Technical Specification being the 'make it concrete' document. So I wonder if that is maybe the thing that needs updating more than the PRD itself? 15:18:12 do we need to make changes to the PRD ? or is it ok for us to just match up the existing PRD plans and goals with our ongoing initiatives (...the stuff thats on the task list) 15:18:26 * stickster not sure if we've put this topic to bed, but maybe it would be more constructive to just look at some of the detail topics in mcatanzaro's post to list, to see what's building on top and relevant toward the policies/plans section 15:18:52 (https://fedoraproject.org/wiki/Workstation/Technical_Specification) 15:19:10 It would probably be good to attempt to clarify the PRD with respect to the "optimize for power users or general users" question. 15:20:38 That would probably help us have a unified message for when people are suggesting enhancements 15:20:58 I think having a productive IRC discussion about unspecified edits is really hard, but I be happy to discuss/support concrete edit suggestions 15:21:02 mcatanzaro: I think the PRD is *intentionally* a bit vague there, since we had strong requests for both when we were drafting it - narrowing to just developers got a lot of pushback 15:21:07 Upstream GNOME is optimizing for general users, the Fedora Workstation developers working on upstream GNOME are optimizing for general users and assume developers appreciate having a system that's easy to use (like OS X!), but we regularly see comments from users who argue that e.g. it's OK to expect developers to use the command line, because they are power users not general users. 15:21:17 'power users' is not a very helpful term... 15:21:27 I don't know a better term. 15:21:41 I consider developers to be neither "power users" or "general users" - they are people who want to get a particular set of (complicated) things done with Fedora 15:23:02 * stickster thinks we should probably give this topic some discussion time on the list. We still have to outline some *actual plans* for the Council in a couple weeks, and this discussion isn't getting us closer. And those things we *do* want to do can be made more concrete in the time we have here :-) 15:23:13 ok, so if someone drafts a new text trying to clarify that we don't think just offering command line tools is good enough for developers I am fine with that 15:23:40 I'll put it on my to-do list; I guess we generally agree on that? 15:23:42 I don't think it's very incisive way to make decisions either - how does it inform whether gnome-tweak-tool should be installed by default or not? 15:24:18 developers are often comfortable with using the commandline - we've certainly made attempts to improve their life by investing in gnome-terminal features 15:24:34 *nod, including featured enhancements this and last cycle 15:25:13 * stickster would like to see us do something a little more comprehensive that helps developers (and probably everyone)... like the upgrade story 15:25:14 cschalle: What do you mean by that? that offering graphical development tools is part of our mandate? 15:26:28 otaylor, no, that you shouldn't need to use the command line to be able to get your desktop working; so for instance we currently fall short IMHO due to not having upgrades in Software 15:26:57 * kalev very much agrees. 15:26:58 #idea Can we work toward a better upgrade story in F23/24 15:27:12 That's a year to make things better than "run fedup and hope for the best" 15:27:29 Which is not to say fedup is not good. My experience has been that it's worked quite well for a few cycles now. 15:27:41 I think improving the terminal is well and good, but if we expect developers to use the command line then we give up on being a "polished and user friendly system that can appeal to a wide general audience" -- which is the most important component of the PRD IMO. I see our developer focus as being a great strategy and maybe an end goal, but I'd hate for it to compromise that. 15:27:44 But there's a lot of things you have to know to use it at the CLI. 15:28:23 I used fedup yesterday and it worked perfectly, but (a) I had to use the command line, and (b) I had to follow instructions on a wiki page. Neither should have been required. 15:28:36 otaylor, I was a bit inaccurate, I do think providing GUI tools being part of our mandate, but that mandate can be resolved mostly by just making sure tools provided by others work well, like the current vagrant work 15:28:36 mcatanzaro: EXACTLY 15:28:37 cschalle: OK - that wouldn't hurt to state explicitly - that all "normal" configuration and operation of the computer should not require using the commandline 15:29:13 otaylor, agreed 15:29:17 mcatanzaro, agreed 15:29:18 (where "normal" is in the eye of the beholder...) 15:29:25 * cschalle is very agreeable today 15:29:32 cschalle: Do you have an idea for how to make e.g. vagrant behave better for our developer target? 15:29:44 stickster, no, but langdon and co supposedly does :) 15:30:05 stickster, I mean we had a big fedora magazine article about it even along with the F22 release :) 15:30:14 cschalle: And he'd probably write it down for us if I'd only had the frakking time to write up a wiki page for him to fill in 15:31:10 * stickster points himself back at #action from last meeting to get it done 15:31:10 #action mcatanzaro to propose update to PRD to clarify that developer focus does not compromise the goal to be a "polished and user friendly system that can appeal to a wide general audience" 15:31:27 Thanks mcatanzaro 15:32:17 I asked anyone from Anaconda to lurk here for a relevant topic. I think we are looking for some changes in Anaconda and we should make that an explicit request so we don't just "hope it happens" and then get disappointed later 15:32:24 F23 Alpha is only a couple months away 15:32:52 stickster: Yes, but I wanted to discuss the changes in a WG meeting before sending them on as if it's an official request. 15:33:11 yeah, I think the hope is to reduce the overlap between anaconda and intital-setup even further 15:33:12 mcatanzaro: Absolutely -- feel free to describe the idea! 15:33:13 https://lists.fedoraproject.org/pipermail/desktop/2015-May/012065.html 15:33:45 Oh right, this was a helpful list 15:34:37 That list accounts for everything except the installation location (disk layout) spoke, which is the most problematic part by far, but I didn't have any grand ideas for that and thought it might be helpful to split our Anaconda wishlist into two different issues: (a) general workflow and (b) the installation location spoke. 15:34:44 I disagree with removing the hub and spoke idea. But other than that, some interesting stuff 15:35:18 * mclasen would love a straight-line installer 15:35:26 I personally find anaconda incredibly unintuitive after the big rewrite 15:35:29 Wasn't there also some idea about installation sources as well viz. rpm-ostree or a Live image? 15:35:31 kinda the opposite of hub-and-spokes... 15:35:48 (b) is hard because we want it to provide useful partitioning tools to power users, but displaying them to general users would be too confusing and not user friendly. The current design attempts to do this but did not get it quite right: the user-friendly screen that hides the advanced partitioning screen is still too complicated. 15:36:40 stickster: The thing about keeping hub-and-spokes is, with the requested changes there are *very* few spokes left: keyboard layout, installation location and *maybe* hostname (which is really not enough to be a full spoke anyway!). 15:36:54 mcatanzaro: that is something being looked at - do you have any sketches or thoughts on simplification of the partition screen? 15:37:09 stickster: what is the current status of the live installer vs 'full anaconda' ? 15:37:14 I don't really like the way the hub and spoke model works out for the use case of just slapping standard bits onto disk - it's meant to hide complexity that we'd rather just not have - *but* asking to remove may be going too far in asking for something that doesn't have the fundamental UI idea of current Anaconda 15:37:15 mcatanzaro: But we are not the only consumer of the installer -- other spokes might be added by any number of other downstreams 15:37:42 and is anaconda any closer to a frontend/backend separation that would enable a different ui ? 15:38:14 if it was a straight line installer, other downstreams could still add individual pages for the wizard type up 15:38:28 well from my conversations with dcantrell the current goal is to make what is offered by Anaconda highly configurable, that doesn't do away with the hub and spoke model, but it should let us hide almost all spokes 15:38:29 mclasen: I'm pretty sure pyanaconda has been greatly beefed up. 15:38:32 spoke model vs straight line doesn't really mean that downstreams can edit one and can't the other 15:38:39 stickster: that sounds a little more grandiose than it really is, I think - are there any other downstreams than rhel ? and in the rhel case, the only addition I can think of really shouldn't be there in ther first place... 15:38:50 Kellin: I don't, that's why my list covers everything except the partition screen. :) But https://lists.fedoraproject.org/pipermail/desktop/2015-May/012109.html seems like a good idea to me. 15:39:04 kalev: I think it's pretty clear that if the hub and spoke was off - it would have to be something configured specifically for the workstation - that we wouldn't be asking for a redesign 15:39:47 CentOS, Scientific, http://distrowatch.com/search.php?basedon=Fedora ... 15:40:30 But RHEL/CentOS are by far the biggies, sure 15:41:12 To be clear, my proposed changes are only for the Workstation installer: they don't make any sense at all for Cloud or Server. So the expectation is indeed that Anaconda is configurable (already different media have different spokes) and that other products can keep hubs/spokes even if we get rid of them. 15:41:14 The "what's happening in Anaconda" questions would be best answered by Anaconda folks, though. We should probably get them in an actual discussion to help figure it out ;-) 15:41:59 But anyway, I propose presenting this to the Anaconda developers as a wishlist, not as a formal policy statement, and just see where it goes from there. I guess the only controversial part of my proposal is removal of hubs/spokes? 15:42:23 i think proposing it as something other than a wishlist is going to be more productive 15:43:00 perhaps start a conversation with the offer to help implement the changes with guidance from the anaconda developers 15:43:08 jwb: +1 15:43:13 stickster: yeah, so I'm here now. tried joining earlier but could not for whatever reason 15:43:25 dcantrell: technology stinks 15:43:35 mcatanzaro: have you worked through how timezone selection removal works with respect to installation timestamps? that was always the argument there 15:43:38 dcantrell: We were talking about https://lists.fedoraproject.org/pipermail/desktop/2015-May/012065.html 15:43:40 Well I think nobody from Workstation is going to help implement the changes TBH. If someone volunteers, that would be awesome.... 15:43:56 mcatanzaro, then tbh i don't think they'll ever get done 15:44:02 mcatanzaro: let 15:44:14 's figure out what needs to be done, then we can figure out what help can be provided :-) 15:44:18 I think we also make everyones life a lot easier if we try to avoid 'bundling' requests as much as possible. Ie. reducing anaconda and initial-setup overlap shouldn't be tied to 'do away with hub and spoke', and neither should be tied to 'improve partition tool' 15:44:23 dcantrell: With the caveat that the hub-n-spoke "removal" item there is controversial within this group and I don't think we have a consensus that should happen 15:44:42 I don't think it is out of the question - just a matter of priorities. Is 'remove hub-and spokes' more important that 'graphical upgrades', e.g ? 15:45:03 otaylor: I wondered about that but decided installation timestamps don't matter much. If we are concerned about timestamp accuracy, then it has to be done by anaconda, and we should completely remove that panel from g-i-s. 15:45:10 cschalle: Yes. I think the first thing we should talk through specifically with Anaconda folks is reduction of intial-setup overlap, and doing that in a way that continues to work well for other Fedora editions 15:45:41 stickster: yes, I think so too - let's tackle this as a first step and leave other anaconda items for another time 15:46:52 kalev: I recall that's been batted around for some time, and even some broad head-nodding that it should happen, but we really need to plan the actual changes with dcantrell & co., and have a timeline to get them done. 15:47:57 mcatanzaro: that should be spelled out explicitly (I don't have a big opinion on the matter - hard to be sure about the time until you are on the network in any case) 15:49:09 stickster: I did read that post, but as you've indicated, these deserve a more detailed discussion with me/my_team to figure out some plans and options 15:49:13 dcantrell: Looking at just the first four bullets in that email I linked... what there makes your head explode, vs. "yeah, this seems doable, modulo design agreed, etc." 15:49:18 dcantrell: Yeah 15:49:38 in regards to the partition tool, while I do see people online complain about it we need someone to mockup possible improvements, giving dcantrell and the team the feedback that 'it sucks' is as useless feedback to them as that specific form of feedback is to anyone else 15:49:55 dcantrell: So what I'm thinking is we should set up a time to do just that, in whatever venue makes sense 15:50:19 I know we have a lot of folks co-located in Westford, but it would be nice to be able to participate from here too :-) 15:50:31 will we have anaconda/workstation wg quorum at flock ? 15:50:46 cschalle: fwiw, "it sucks" was the feedback received on the previous partitioning UI too, so whatever. it's easy for people to complain. I would say storage in general sucks 15:50:47 mclasen: That's after F23 alpha, so you're basically writing off any work until F24 only in that case 15:51:23 * mclasen is currently thinking in rhel timelines more than fedora schedules... 15:51:23 I would prefer in-person and/or video conf to actually go over these things. 15:51:40 mclasen: Perhaps that makes sense, but I guess I'm asking what our time limits are 15:51:48 yeah, understood 15:51:52 mclasen has a valid point, RHEL 7.2 is a *huge* commitment from his group and mine right now 15:51:58 mclasen: Ah, I see you just answered that. So there's a lot of RHEL pressure, and that makes it harder to get anything going before then 15:52:06 *jinx 15:52:08 the rebasing 15:52:50 OK, so we can certainly set this up for F24 if that makes the most sense 15:53:22 It would be nice then to shuffle something like "better upgrade" to F23, *if* the people working on that are different than the people stuck in RHELL 15:53:37 it's all the same people 15:53:40 you know that 15:53:54 Well wait, better upgrade to F23 is GNOME Software land now. 15:54:11 * mclasen can put on a hughsie mask and pretend to speak british 15:54:31 mcatanzaro, i'm sorry, i didn't follow that 15:54:32 heh 15:54:53 dcantrell: I'm being explicit for benefit of people here in channel who aren't so aware ;-) 15:55:10 anyway, the reminder of the f23 alpha deadline reinforces that we should review the tasklist and see what things are underway and can be completed for f23 15:55:19 jwb: Well we want a graphical upgrade, not command-line fedup, and I can't think of any good place for that besides GNOME Software? 15:55:21 * mclasen takes that action item 15:55:27 https://fedoraproject.org/wiki/Workstation/Tasklist 15:55:37 mcatanzaro, oh, i see. 15:55:47 #link https://fedoraproject.org/wiki/Workstation/Tasklist 15:56:34 #info many people who could work on F23 improvements are bound up on immediate RHEL work 15:56:42 #action mclasen will also review foregoing task list to see what's already up that could be completed for F23 15:57:12 mclasen: So we want to have such a list ready for a Council report that happens on... the 12th? 15:57:20 * stickster consults schedule because he may be mixing up dates 15:57:31 mclasen: fedup + plymouth hits my mind. I mean, really it's about status reporting, right? the user has opted in before the reboot to apply updates. I suppose that side could be graphical, but that could be a gnome software center piece or whatever 15:57:37 mclasen: anyways, separate problem 15:57:43 I'll get it done next week 15:58:02 mclasen: That sounds good, and I can bring that stuff together into Council report 15:58:02 fedup + plymouth is already pretty good. 15:58:10 I got a nice progress bar when I tried it yesterday. 15:58:36 I was thinking beyond the progress bar I guess 15:58:41 * stickster is kind of assuming he's going to be the guy doing that (as semi-official WG "janitor"), :-) unless someone else wants to take it 15:58:43 dcantrell: just a button to trigger it, really. Plus some nice looks 15:58:44 That was way better than how our standard charge theme handles updates. 15:58:45 https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/software/version2/wire-os-upgrades.png 15:59:05 stickster: Probably a safe assumption. :D 15:59:09 ;-) 15:59:11 (Thanks!) 15:59:29 #action stickster pull together tasks from mclasen + update + anaconda requests into Council report for F23/24 15:59:59 I think we had two open questions here: 16:00:12 do we have quorum for anaconda / workstation at flock ? 16:00:28 mclasen: Thanks, you're right. I'll be at Flock. 16:00:29 do we want to arrange an (online) meeting before flock ? 16:00:33 I don't think I'll be there, at least my talk wasn't selected 16:00:36 (When will be flock?) 16:00:39 * mclasen plans to be at flock too 16:00:44 Aug 12-15 in Rochester, NY 16:00:45 kalev: oooh :-( 16:01:12 * nirik notes talk selection isn't done yet. 16:01:29 * stickster notes, no one is in this meeting channel this next hour, so we can go over a bit, but I can't stay too much longer 16:01:47 nirik: Correct, I don't think anyone's been accepted/axed yet 16:01:58 I'll be at flock 16:02:13 mclasen: I think we do want to meet online beforehand if possible 16:02:15 ahh ok, I only found https://admin.fedoraproject.org/voting/results/flock-2015 with a fat red line between talks :) 16:02:32 ah I see, kalev used the data ;-D 16:02:48 I will likely not be at flock, but I think the WG is mostly on the same page with respect to the installer so that's OK. Removing redundancy between g-i-s and anaconda is the most important part. Removing hub-n-spokes is optional. 16:02:56 kalev: the red line doesn't mean anything :) 16:02:59 there may be some tuning before the official schedule comes out 16:03:34 voting is just one datapoint they will use in selecting talks. 16:04:54 yep 16:05:02 OK -- we are kind of drifting off topic here :-) 16:05:26 stickster: how do we go about scheduling that meeting ? 16:06:00 mclasen: set up a whenisgood.net ... I have an account there and will be happy to do it, what is the right time to get out of internal crunch time? 16:06:47 * otaylor will be at flock as well 16:07:31 dcantrell: I'll give you and our list the links, anyone who's involved can just paint their availability on the time chart. 16:07:52 * mclasen thinks an hour of tea and cookies with the anaconda team would fit in anytime 16:08:57 mclasen: OK, something in the next couple weeks then perhaps? 16:09:17 yes, sounds fine 16:09:21 * stickster trying to be sensitive to schedules 16:09:44 * mclasen drops out, apologizing for not making it next monday - travelling 16:09:46 #action stickster Set up whenisgood for WG + anaconda folks to discuss requests 16:10:00 mclasen: No worries, we don't meet again until week after that. 16:10:48 I think we got the things we needed today, which was a short list of F23/24 major items, with minor items also following from mclasen review, and I'll pull it all together for Council. 16:11:04 This will come back through the list for review too 16:11:10 I had a list of other topics to discuss, but none are urgent so we might as well put them off to the next meeting? 16:11:28 I have to go, sorry 16:11:33 mcatanzaro: Yeah, although a couple of them are roughly in today's notes :-) 16:11:38 mcatanzaro: I'll carry over 16:11:59 #info stickster will carry over agenda items from mcatanzaro list so we can pick up at next meeting 16:12:11 #info Next meeting: 2015-Jun-08 UTC 1300 16:12:15 Thanks everyone 16:12:17 #endmeeting