workstation
LOGS
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