16:00:21 <stickster> #startmeeting Fedora Workstation 16:00:21 <zodbot> Meeting started Wed Feb 18 16:00:21 2015 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:26 <stickster> #meetingname workstation 16:00:26 <zodbot> The meeting name has been set to 'workstation' 16:00:36 <stickster> #topic Roll call! 16:01:23 * mclasen__ here 16:01:33 <stickster> mclasen__: Hi, you cast a long shadow today ;-) 16:01:59 <stickster> rdieter: kalev: juhp: cwickert: ping 16:02:17 <otaylor> here now 16:02:34 <stickster> Hi Owen 16:02:47 <kalev> hello 16:03:12 <stickster> #chair rdieter mclasen otaylor juhp cwickert kalev cschalle_ 16:03:12 <zodbot> Current chairs: cschalle_ cwickert juhp kalev mclasen otaylor rdieter stickster 16:04:10 <stickster> I believe Ryan may be out today 16:04:13 <stickster> Let's get started! 16:04:36 <cwickert> ! 16:04:45 <stickster> We'll add Michael's item on Anaconda after the feature + test days items 16:04:49 <stickster> cwickert: go right ahead :-) 16:05:20 <cwickert> stickster: I would like to step down from the WG. I will send a mail about my motivation later, basically it is just that I don't think I can bring much to the table and somebody else probably can 16:05:33 <cwickert> so feel free so elect/appoint somebody else 16:05:49 <rdieter> here 16:06:08 <rdieter> (got sucked into conversation by water-cooler/coffee-pot) 16:06:12 * mclasen finds a few hints in ryans cube, but no ryan 16:06:32 <stickster> cwickert: OK, thank you for letting us know. Would you mind sending something to list? I'll be happy to follow up and beat bushes for someone :-) 16:07:08 <cwickert> stickster: ok 16:07:12 <stickster> cwickert: I for one would like to say thanks for the time you were able to give us, though :-) 16:07:50 <stickster> #info cwickert is stepping down 16:08:13 <stickster> #action stickster follow up with list to work on filling open seat 16:08:28 <cwickert> welcome stickster and the others, keep up your great work for a really polished and shiny product 16:09:02 <stickster> Thank you sir! We will try. :-) and in that spirit... I guess I'll move on if no one objects 16:09:56 <stickster> #topic F22 feature progress 16:10:25 <mclasen> I did a round of updates for the changes we filed, earlier this week 16:10:40 <mclasen> they're all trying to land in the 3.15.90 releases this week 16:10:50 <mclasen> some are still struggling with the landing part... 16:11:34 * stickster suspects this is sort of de rigeur for the GNOME release feature, balancing upstream schedule with ours 16:11:51 <mclasen> well, we kinda have a big pileup of large branches this time around 16:11:57 <stickster> mclasen: Did I leave out any major features in the list I sent for agenda? I thought I got all the biggies. 16:12:29 <mclasen> I had hoped to land e.g. the notification redesign in stages, but florian only came out with a branch late last week... 16:12:37 <mclasen> let me check the list 16:12:51 <stickster> rdieter: Do you know the status of the change for libinput? ISTR there was a patch set we might need to carry while working it through upstream 16:13:03 <stickster> https://fedoraproject.org/wiki/Changes/LibinputForXorg 16:13:13 <kalev> I landed my branch! 16:13:38 <rdieter> stickster: the kde touchpad patch is imported, pkg built, ready for testing 16:13:46 <stickster> rdieter: Coolio! 16:14:17 <mclasen> do we need to update the status of that change ? are we supposed to move tracker bugs to modified ourselves ? 16:15:08 <stickster> rdieter: Could I ask you to update the page? 16:15:21 <stickster> mclasen: I think the change wrangler handles the tracker bug 16:15:54 <rdieter> stickster: I added the related bug to the tracker 16:16:10 <stickster> rdieter: eggggscellent 16:17:08 <stickster> I'm going to move on, then... we seem to be on target for all the major changes, awaiting GNOME 3.15.90 16:17:15 <stickster> #topic F22 Test Days 16:17:39 <mclasen> yeah, I'll make sure we get a) all the things into 3.15.90 and b) 3.15.90 into f22 pre-alpha freeze 16:17:49 <stickster> mclasen: Thanks, that's perfect! 16:18:24 <stickster> This raises the issue of what we'd like to get community help in testing... A couple of those changes seem susceptible to early testing. 16:19:07 <mclasen> the notification changes will be very prominent and certainly need to be tested by many users, so we find the gotchas and corner cases 16:19:34 <mclasen> but thats more crowd exposure, not so much filigrane test case execution by an expert qa team 16:20:31 <stickster> mclasen: Would the idea be for people to just try running their notifying apps on top of a test release to see if they run into any issues 16:20:45 <stickster> s/$/?/ 16:20:54 <mclasen> basically 16:21:21 <mclasen> if you have any specific workflows or habits involving notifications, seeing how they fare with the new system would be good 16:21:38 <mclasen> also, if you are using extensions that have opinions about notifications 16:21:41 <mclasen> those may need attention 16:22:30 <mclasen> I'll send a mail to devel when the build lands in f22 16:22:35 <stickster> mclasen: So are you suggesting rather than a Test Day, maybe just a call to action for the community to download a test release and drive it around for a few days or so, and file bugs on notification issues? Do we want to give them any expectations of what has changed so they can tell what's really a bug? 16:23:10 * stickster was thinking a blog entry on Planet could help... I'm willing to be useful and write something :-) 16:23:16 <mclasen> sure, that works too 16:23:25 <stickster> #action mclasen Post to devel when new notification builds land in F22 to encourage testing 16:23:47 <stickster> #action stickster Write blog entry for Planet on heels of mclasen post to do likewise 16:24:25 <stickster> mclasen: I'll look to your post for cues on what people should consider as bugworthy 16:24:53 <stickster> What about a Test Day for current Wayland? libinput? 16:26:15 <mclasen> wayland might be good to give a test day, when the login screen change has landed 16:26:16 * stickster not sure what's really testable about libinput other than "Yes, input devices still work"... but OTOH that seems like an easy test case to spray out to many people with disparate hardware via a Test Day 16:26:57 <stickster> mclasen: Should we perhaps schedule something for early March for both of these (login screen + libinput)? 16:27:18 <mclasen> sounds good to me, yes 16:27:33 <stickster> kalev: Could you respond on the list thread to do that? 16:27:42 * stickster starts spreading around actions since people are pretty quiet today ;-) 16:28:43 * rdieter hands stickster actions dart gun 16:29:10 <kalev> stickster: not sure I am the best person, I don't know a lot about libinput 16:29:29 <stickster> rdieter: Would you take that one? kalev: Could you take the Wayland side? 16:30:16 <mclasen> I can help out with putting together wayland test cases, if that is part of the assignment here 16:30:17 <rdieter> stickster: ok (I'll pick your brain after meeting for details) 16:30:20 <stickster> #action rdieter Respond to on-list thread to set up Test Day for libinput... work with hdegoede on details, probably just looking for input device "not working" regressions 16:30:37 <stickster> #action kalev mclasen Put together Wayland test cases and respond to on-list thread to set up Test Day 16:30:40 <stickster> cooll; 16:30:44 <kalev> stickster: sure -- should we schedule the test days now, or after the changes have actually landed? 16:31:02 <stickster> kalev: We can set them up in advance, early March should be sufficient, right? 16:31:26 * stickster not trying to be pushy. AIUI we should have testable stuff by later this month 16:31:33 <kalev> I hope so :) 16:32:25 <stickster> OK, does anyone have anything further on Test Days? (waiting 30 sec) 16:33:23 <stickster> #topic Anaconda + libpwquality issue 16:33:34 <mclasen> do we do a (not workstation-specific) fedup test day ? 16:33:49 <stickster> #undo 16:33:49 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x3d31a10> 16:34:09 <mclasen> we won't have a graphical frontend for it in f22, but it would still be nice to know that upgrading from f21 to f22 works reasonably well 16:34:16 <stickster> mclasen: That's a good question. Nothing on the TD calendar that I saw, but maybe it's up to us to suggest it. 16:34:39 <mclasen> its the first time we do 'product-product 16:34:42 <mclasen> ' upgrades 16:35:04 <stickster> yeah, good point. cschalle_, do you want to take this one? 16:35:46 <cschalle_> sure, I can follow up on this one 16:35:48 <stickster> I think the action is probably "Talk to fedup maintainers to ensure such a Test Day is planned" 16:36:18 <stickster> If they're not interested we can see if we have someone(s) in the WG to sit in on the Test Day, but really having folks involved who can deal with issues is the best thing 16:36:43 <stickster> #action cschalle_ Talk to fedup maintainers to ensure a Test Day for product -> product upgrades is planned 16:36:50 <stickster> OK, now moving on :-) 16:37:00 <stickster> #topic Anaconda + libpwquality issue 16:37:07 <otaylor> We'll definiteyl need some working group involvemnet - to sit there - and also to think about whether there are friction points on the upgrade - migration issues, etc. 16:37:17 <stickster> *nod 16:37:54 <stickster> Right, I was thinking about fedup bugs, but beyond that some product-specific advisors would be useful. 16:38:49 <kalev> talking about Anaconda, I just pushed the change sgallagh asked for, adding a FedoraWorkstationInstallClass 16:39:01 <kalev> we should be able to use it to do further Anaconda customization 16:39:03 <kalev> http://pkgs.fedoraproject.org/cgit/fedora-productimg-workstation.git/tree/fedora-workstation.py 16:39:08 <otaylor> stickster: If we are testing upgrades, we should take advantage of that to make sure we are testing all aspects of the upgrade not just that fedup runs without error 16:39:34 <stickster> OK, so on /topic... Last I heard, there was a question about whether pwquality might have changed from under Anaconda between F21/F22, but that's not the case per pwquality code. So the question was really about how we implement changes per-product 16:40:20 <stickster> kalev: Is FESCo generally receptive to making this work differently per product? 16:40:36 <jwb> stickster, we haven't talked about it yet 16:40:39 <kalev> stickster: I would think so, but my term just ended a week ago 16:40:47 <jwb> it's on the agenda for today 16:40:50 <kalev> all FESCo questions go to jwb now! 16:43:15 <stickster> ha 16:43:51 * mclasen apologizes for dropping off - I feel into a widening crack between telepathy and polari 16:43:57 <mclasen> fell, even 16:44:44 <stickster> mclasen: :-) 16:45:18 <stickster> So how do we want to pursue this? jwb, can you poke us about outcome here, so we can decide wehther we should be pursuing this product module further? 16:45:22 * stickster fires his typist 16:45:59 <stickster> sorry, "here" --> "#fedora-workstation" or the list 16:46:05 <jwb> stickster, um, sure. or if you really want to see it as a per-product thing, then show up to the FESCo meeting. the anaconda team doesn't seem thrilled with that idea. 16:46:10 <stickster> I was going to try to sit in on FESCo meeting 16:46:34 <jwb> as i understand things, they see it as more code that will have to be maintained or bitrot 16:46:53 <stickster> What are our alternatives? Based on the testing results I saw on list, it feels like a lot of what we would consider strong passwords are being rejected by Anaconda/libpwquality 16:47:31 <jwb> it's not anaconda afaik. so it's pwquality. why that is, no idea. 16:47:38 <jwb> but the choices are simple 16:47:52 <stickster> https://lists.fedoraproject.org/pipermail/test/2015-February/125074.html 16:47:54 <jwb> revert to the old way, make it per-product, do nothing 16:48:20 <kalev> options 1 and 2 seems acceptable to me 16:49:20 <jwb> personally, i'd like to see 2 implemented as a pluggable policy at runtime because it gets out of proscribing policy for the whole distro 16:49:34 <jwb> but i'm not in a position to decide or implement that 16:49:53 <cschalle_> jwb, its open source, you can do anything ;) 16:49:54 * satellit do a multi boot .iso with selection for product ; non product; server? 16:49:57 <otaylor> It would be nice if the determination of quality level was consistent and the per-product was just whether less strong passwords are allowed 16:50:08 <stickster> jwb: If I understand kalev's commit properly, this is something we could maintain on Workstation side and it would not be on the Anaconda team to maintain 16:50:19 <stickster> kalev: Tell me if I'm wrong about that, though :-) 16:50:31 <jwb> cschalle_, yes, true. let me put it this way: if the anaconda team doesn't commit to doing the work, we will have to carry a fork of anaconda to accomplish it. which i'm not thrilled to maintain :) 16:50:47 <jwb> stickster, kalev's commit? 16:50:49 <jwb> which commit 16:51:05 <stickster> IOW, I thought this *was* something pluggable... http://pkgs.fedoraproject.org/cgit/fedora-productimg-workstation.git/tree/fedora-workstation.py 16:51:24 <kalev> stickster: yes, but Anaconda core would still need to support both ways -- to enforce or not to enforce passwords 16:51:49 <jwb> ah, i missed that. when did that happen? 16:52:01 <stickster> Oh, I get it. In other words that's not really implemented as something a product can override 16:52:36 <stickster> http://pkgs.fedoraproject.org/cgit/fedora-productimg-workstation.git/ (5 hours ago) :-D 16:52:39 <kalev> Yes, I think that's the gist of the problem, that anaconda would need to still implement both code paths and then a product would be able to select which one they want 16:52:43 <jwb> ok, not fair then :) 16:52:58 <kalev> and the anaconda developers are objecting to that 16:53:05 <jwb> but yeah, ananconda still needs changes to support the plugin here 16:54:05 <otaylor> Maybe if we spec out exactly what we want to override and the behavior, it will seem less scary? It sounds like a one line thing (leave the next button sensitive if option is set oro something) 16:54:55 <stickster> Hm, it may be more complex than that, but I agree that if we could be a little more specific (or give an acceptable patch by working with Anaconda devs directly) that would be great 16:55:22 * mclasen would love for anaconda to get out of the password business altogether 16:55:29 <mclasen> less code for them! 16:55:53 <cschalle_> we could try pulling together a little meeting tomorrow and see if we can make some progress on this issue 16:56:06 <jwb> why don't we wait and see what FESCo turns up 16:56:18 <jwb> i'd rather avoid closed door meetings on this 16:56:30 <cschalle_> ok np 16:56:36 <stickster> cschalle_: I was about to say same as jwb -- we should probably have interested folks attend FESCo to listen in 16:56:42 <kalev> mclasen: ohhh, right -- maybe we could instead set a goal to have the Workstation Anaconda configuration drop their password page entirely 16:56:44 <otaylor> mclasen: It is a question if we start overriding things here, we should consider what we want to override - it's definitely not clear that you *should not* create a user account 16:56:46 <kalev> and rely on the initial setup instead 16:56:49 <mclasen> the thing is that at the end of the day, we'll have to have a meeting _with_ the anaconda folks to agree on something 16:57:48 <stickster> Yes. And clearly if passwords like "4muDb^pd" are not being accepted, something's a bit wonky 16:58:41 <stickster> cschalle_: If we pull together a meeting about this, we could easily do that here on IRC. 16:58:56 <mclasen> yes, that is a part of the problem here - we unified all the password policy checks in a single place, but the checks are just not very good/practical 16:59:30 <kalev> I would much like if the Anaconda part was a lot simpler and we could do timezone and user setup entirely post-install, using gnome-initial-setup 16:59:50 <stickster> We're running out of time here, so we'll table the item on privacy policy for now. I think we are waiting on Fedora Legal right now anyway to have a discussion with ABRT folks. 17:00:04 <cschalle_> stickster, maybe, the thing is I have not been following this issue much, so I don't know if its a issue mostly brought on by lack of bandwith in communication or by real differences. if the first then an IRC meeting might not be the right thing as it just propagates the bandwith issue 17:00:16 <mclasen> I have poked that discussion again this week (privacy policy) 17:00:31 <stickster> kalev: Perhaps, but if we're going to meet about libpwquality we may not want to conflate the pw issue with other things 17:00:36 <mclasen> no movement so far. meanwhile, we do have links to the existing policy in the control-center and gnome-initial-setup now 17:00:59 <stickster> #info Interested folks should attend FESCo meeting today regarding libpwquality issue 17:00:59 <sgallagh> kalev: I should note that relying on gnome-initial-setup doesn't currently work too well on headless installs like Fedora Server. 17:01:09 <stickster> That's a wrap, folks. 17:01:11 <stickster> #endmeeting