| *** gcb has joined #openstack-tc | 02:50 | |
| openstackgerrit | Flavio Percoco proposed openstack/governance master: Drop Technical Committee meetings https://review.openstack.org/459848 | 04:55 |
|---|---|---|
| *** jpich has joined #openstack-tc | 07:32 | |
| *** alex_xu has quit IRC | 08:06 | |
| *** alex_xu has joined #openstack-tc | 08:12 | |
| *** cdent has joined #openstack-tc | 08:50 | |
| openstackgerrit | Merged openstack/governance master: Amend leaderless program resolution timeframe https://review.openstack.org/492578 | 08:56 |
| * cdent opens for business | 09:00 | |
| cdent | tc office hours is now in session | 09:00 |
| openstackgerrit | Merged openstack/governance master: Allow teams to host meetings in their channels https://review.openstack.org/485117 | 09:02 |
| openstackgerrit | Merged openstack/governance master: verb-subject agreement in meeting scheduling resolution https://review.openstack.org/495886 | 09:02 |
| cdent | Bueller? | 09:03 |
| * johnthetubaguy lurks | 09:06 | |
| ttx | hola! | 09:10 |
| ttx | Sorry was busy replying to the code complexity review | 09:11 |
| ttx | (best excuse ever) | 09:11 |
| ttx | TL;DR: being good thing to raise, but top-5 probably not the way to box it | 09:11 |
| ttx | Would be great to get https://review.openstack.org/#/c/498363/ merged so that we have the right PTLs listed, so please pile up +1s | 09:12 |
| cdent | ttx yeah, I figured top 5 was simply a way to get it into a box, and then once contained, we could put it in the right place | 09:13 |
| ttx | cdent: anything I missed in the channel chatter by skipping next week entirely ? | 09:13 |
| ttx | cdent: I like the idea of having a group of people focused in making our community more accessible in general. Could be wrapped as a SIG since it's not really upstream-specific imho | 09:14 |
| ttx | Handling code complexity being just one aspect to it. | 09:14 |
| cdent | ttx no, not much happened, in irc, as I recall | 09:14 |
| openstackgerrit | John Garbutt proposed openstack/governance master: Top 5 idea: service layering https://review.openstack.org/498719 | 09:14 |
| ttx | We could definitely produce more code walk-in blogposts/videos | 09:14 |
| ttx | Like an intro of the ins and outs of a cookiecutter openstack service | 09:15 |
| ttx | Would speed up initial dive in code | 09:16 |
| johnthetubaguy | would putting it in the top5 things help that all happen more quickly? | 09:16 |
| ttx | johnthetubaguy: I think it's too vague to be actionable | 09:16 |
| ttx | maybe once the group is set up and it's mostly struggling with manpower, it could help to be top-5 | 09:17 |
| ttx | but without some structure, you are asking for someone to build a thing, rather than to help with a thing | 09:17 |
| cdent | we did come up with some ways to make it (if we’re still talking about complexity) actionable in discussion late last week: there’s a flake8 plugin that might be useful to turn on in various places | 09:17 |
| cdent | if we make it adivisory, the thing we are asking for help with is lessen the output of that plugin | 09:18 |
| johnthetubaguy | feels like the first action is making it more actionable? Its meta, but it raises the priority | 09:18 |
| ttx | cdent: feels more of a goal-thing once we can get a quantified objective | 09:18 |
| johnthetubaguy | so I added a similar kind of thing here: https://review.openstack.org/498719 | 09:19 |
| ttx | like "reduce code complexity by 20%" | 09:19 |
| johnthetubaguy | I would be very suspicious of anything like that myself, its more a people issue, did we make it simple enough we have the time to describe things to new comes | 09:20 |
| ttx | johnthetubaguy: yeah, that also feels like a design priority / strategic goal rather than a "we are struggling in this department, please help!" | 09:20 |
| cdent | well the thing that made me write something up is because I’m concerned that the current state of things is turning people away | 09:21 |
| ttx | My view of top-5 things is that we should keep them for distress calls, not strategic orientations | 09:21 |
| ttx | although some things can be both | 09:21 |
| cdent | that’s probably true, but I think perhaps we have an opportunity here to be far more verbose about strategic directions | 09:22 |
| cdent | (and I think complexity reduction should be considered tactical) | 09:22 |
| cdent | the strategy is to get people to think _far_ more about maintainability | 09:22 |
| ttx | For example, we have that list of 5 strategic goals from the board/tc/uc workshop | 09:22 |
| cdent | and “developer happiness” (whatever that is) | 09:22 |
| ttx | Those are communicated separately from the top-5 | 09:22 |
| ttx | Simplification, ensuring that components can be reused in other stacks... | 09:23 |
| ttx | Those are strategic goals | 09:23 |
| ttx | The other 3 being: better communicate what is openstack, raising the next generation of leaders and closing the ops-dev feedback loop | 09:24 |
| ttx | Some strategic goals might be missing from that list, but I'd rather add them to that list, rather than overload our private "help needed here now!" list | 09:25 |
| ttx | If only because getting board/UC input on what strategic goals are is a good idea | 09:26 |
| ttx | I'd like to keep the top-5 list at TC level | 09:26 |
| ttx | It's for things where the TC perceives an area will die/starve if nobody helps with it | 09:27 |
| ttx | Not really for things the Board/TC/UC thinks OpenStack will die long-term if we don't address it | 09:27 |
| cdent | my eyes are going to fall out if we don’t work more on code readability :) | 09:27 |
| ttx | (I don't know if I make sense) | 09:27 |
| cdent | you do | 09:27 |
| ttx | cdent: so on code readability it's certainly on the fence, since it's so updatream-focused | 09:28 |
| ttx | upstream* | 09:28 |
| ttx | But John's "Improved layering" definitely sounds strategic to me | 09:28 |
| ttx | One way to phrase it is that the top-5 list is hightly tactical | 09:29 |
| ttx | It's really a boots-on-the-ground thing | 09:29 |
| ttx | More of a "we should really turn left if we want to avoid that iceberg there" than "we should really turn left if we want to ever reach New York" type of thing | 09:30 |
| cdent | I think that these two things have come up, have chosen the top-5 list as a target, but missed somewnat, suggests that we need a more concrete and visible form of “stuff that matters” | 09:32 |
| cdent | (“but is not icebergs") | 09:33 |
| cdent | or more accurately: a more concrete and visible path. As we probably the things but not the shared understanding of how it all fits together | 09:33 |
| ttx | I think that the best forum for non-iceberg things is the strategy workshop (Board+TC+UC thing) | 09:35 |
| ttx | That list of 5 things got even more widely communicated than the top-5 list | 09:35 |
| cdent | to whom? | 09:36 |
| ttx | Community in a large sense. Like it appeared in Summit keynotes, in openstack Days keynotes | 09:36 |
| ttx | in blogposts etc | 09:37 |
| ttx | We also have people assigned to work on each | 09:37 |
| ttx | So they are actually staffed with Board/TC/UC members at creation time | 09:38 |
| ttx | So the question becomes more "what should we really do to address that strategic issue" rather than "we need help to work on this" | 09:38 |
| ttx | The code complexity issue could be seen as strategic, but as part of a larger "we need to keep openstack attractive to devs" bucket | 09:39 |
| * johnthetubaguy re-reads scrollback | 10:01 | |
| johnthetubaguy | cdent: I think I am wanting a way to wave the "this is important" flag, and I saw top 5 list as a way to do that, more lists of things feels bad somehow | 10:03 |
| johnthetubaguy | cdent: that sounds a bit like what you are saying above? | 10:03 |
| cdent | yeah, that’s how it feels to me too | 10:03 |
| cdent | it doesn’t feel like we currently have a way of saying “this is important” or “this feels bad” that is … successful? | 10:04 |
| johnthetubaguy | +1 | 10:04 |
| johnthetubaguy | that mysql debate, and the wider tested versions of dependencies, it feels like that would live on a similar list | 10:05 |
| johnthetubaguy | the conversation I really want, I think is, no those 5 things are pointless what we really need is these other 2 things first | 10:07 |
| cdent | I tend to think that part of the job of the TC should be both discovering and representing those issues because we’re suppose to be able to have that wider view and the experience to know when something is important/feels bad and is also real | 10:07 |
| cdent | but at the moment I don’t feel … traction? | 10:08 |
| johnthetubaguy | cdent: I am feeling the same thing | 10:08 |
| johnthetubaguy | I don't really care how we have the conversation about these things, or how we communicate them, as long as its a thing that happens | 10:08 |
| * cdent gives johnthetubaguy a nice cup of tea and a biscuit | 10:08 | |
| * johnthetubaguy makes happy noises as he eats the biscuit | 10:09 | |
| johnthetubaguy | I feel like we need to trigger the debate that leads to a nice list of top problems, that makes it easy for folks to tell us we are wrong | 10:10 |
| johnthetubaguy | its more how do we fuel that community wide discussion | 10:11 |
| johnthetubaguy | I find putting a best guess list down is a good starting place to kick off such discussions | 10:11 |
| * cdent nods | 10:13 | |
| cdent | there’s a lot of fear about having “useless” or “repeated” conversations, which is a shame | 10:14 |
| cdent | it’s a trap! | 10:14 |
| johnthetubaguy | I think writing it down someone where centrally helps some | 10:22 |
| cdent | yes | 10:22 |
| johnthetubaguy | sometimes including someone new feels like a "useless" conversation... | 10:23 |
| johnthetubaguy | I duno, feel there is something missing we should try, even if its just a wiki page | 10:23 |
| johnthetubaguy | cdent: you fancy trying to make a list of lists, with some things that need to go on a list, in a wiki page? | 10:23 |
| *** dtantsur|afk is now known as dtantsur | 10:23 | |
| cdent | only if we can list that wiki page in some list somewhere | 10:24 |
| cdent | (but yes, definitely, sure) | 10:24 |
| cdent | I’m travelling, starting today through to the ptg, but should have some time in the gaps | 10:27 |
| johnthetubaguy | cdent: cool, thanks | 10:36 |
| johnthetubaguy | cdent: once we have a wiki, we can always move it to governance, or link to it from the top 5 as an overflow, etc | 10:36 |
| cdent | It seems like the sort of thing (listing these kinds of things) that we should be doing as a sort of ritual | 10:37 |
| johnthetubaguy | cdent: +1 | 10:37 |
| johnthetubaguy | cdent: would be good thing to do in the PTG room | 10:37 |
| cdent | yup | 10:38 |
| cdent | I am, as usual, completely overbooked on monday and tuesday | 10:38 |
| cdent | want to be in several places at once | 10:38 |
| johnthetubaguy | same here | 10:39 |
| *** dtantsur is now known as dtantsur|busy | 12:23 | |
| *** gcb has quit IRC | 12:29 | |
| *** gcb has joined #openstack-tc | 12:30 | |
| fungi | i've discovered it's possible to be in all places at once, until you're observed directly and your wave function collapses | 12:34 |
| * fungi is more effective as a wave than a particle | 12:34 | |
| cdent | I tend to become decoherent if I sustain that too long | 12:35 |
| fungi | probably not enough gluons | 12:47 |
| openstackgerrit | Chandan Kumar proposed openstack/governance master: Add aodh-tempest-plugins to aodh project https://review.openstack.org/498798 | 12:48 |
| * cdent give fungi a cookie | 12:50 | |
| smcginnis | Cookie time? | 12:54 |
| smcginnis | cdent: To make things more concrete, I wonder if we try to have a release cycle goal of "All projects should have an average cyclomatic complexity of <= 700" or something. It would be a start at least. | 13:08 |
| * smcginnis is just brainstorming | 13:08 | |
| cdent | smcginnis: you’ve got to make a good pun to get a cookie | 13:08 |
| smcginnis | Shoot, I only make puns by accident. :) | 13:09 |
| cdent | A release goal could work, I suppose, but I would hope that release goals have fairly universal acceptance and it’s unclear if something like “reduce cyclomatic complexity” would not meet with resistance | 13:10 |
| smcginnis | Yeah, chances are probably high it would. | 13:10 |
| cdent | I think, in the back of my mind, that I went the top 5 list path to try to do an end run around the resistors: find other people ... | 13:12 |
| openstackgerrit | Merged openstack/project-team-guide master: Revise the format https://review.openstack.org/487267 | 13:32 |
| openstackgerrit | Merged openstack/project-team-guide master: Document process for lib release during freeze https://review.openstack.org/489723 | 13:33 |
| openstackgerrit | Merged openstack/project-team-guide master: Add reno usage for editing stable branch notes https://review.openstack.org/496318 | 13:33 |
| fungi | cyclomatic complexity is also an idea many teams may meet with skepticism. i'm concerned that if we hit them with too many required goals they have a hard time seeing the value in, they'll be less inclined to work with us overall | 13:34 |
| fungi | so... we'd need it to be pretty convincing, and probably set the bar low in terms of amount of work involved | 13:34 |
| openstackgerrit | Merged openstack/project-team-guide master: Move 'big tent' to history https://review.openstack.org/480513 | 13:34 |
| fungi | likely need to start with a complexity analysis across the entire corpus of official deliverables? | 13:35 |
| fungi | so that we know what a good target is without being excessively burdensome | 13:35 |
| fungi | though if it's something we can get buy-in for, we can consider progressively ratcheting down the target each cycle | 13:36 |
| fungi | so starting with a relatively high complexity limit could be a way to get teams used to continually measuring it | 13:37 |
| dhellmann | https://medium.com/@copyconstruct/small-functions-considered-harmful-91035d316c29 has an interesting take on the function complexity/length discussion | 13:38 |
| fungi | the other challenge i see is that we need domain-specific tools to measure it... remember that not all code in official deliverables is written in python | 13:38 |
| smcginnis | Good points. | 13:39 |
| fungi | dhellmann: excellent counterarguments in that article | 13:39 |
| openstackgerrit | Doug Hellmann proposed openstack/project-team-guide master: Add "How to Preview Release Notes at RC-time" https://review.openstack.org/497589 | 13:39 |
| cdent | dhellmann: that makes a good point about DRY and complexity minimization _not_ being the same thing | 13:40 |
| cdent | I tend to be anti-dry but pro-small | 13:41 |
| fungi | another way to tackle the code complexity issue is to try solutions in a limited number of deliverables for a cycle or two, where the teams doing it are convinced of the benefit, and then if it seems to be working out make a goal | 13:42 |
| cdent | In typical fashion I think we’re getting overly focused on the detail of a proposed implementation (tell people to lower cyclomatic complexity) rather than the real goals, which are: make code easier to read, more maintainable, and more “accessible” to new congtributors | 13:42 |
| dhellmann | true. | 13:42 |
| dhellmann | so how do we do that in an objective way without encouraging unnecessary code churn? | 13:42 |
| cdent | this is likely because the latter is very very hard to talk about while the former is relatively easy to dismiss (if you’re a mind to) | 13:43 |
| fungi | so far cross-project patterns we've seen emerge successfully are ones where a few projects try something out and then others see that working out for them and want the benefits so join in. jumping straight to a cross-project goal without some indication that it's measurable, achievable and beneficial is perhaps premature | 13:43 |
| cdent | bbs | 13:44 |
| dhellmann | that's very true, and that's part of why the current goals process leans so heavily on community consensus to identify goals to "finish" | 13:44 |
| smcginnis | I was just thinking setting a bar for a complexity measurement would be a specific thing to target to move in the right direction to the overall, non-specific, goal. | 13:46 |
| smcginnis | Still pondering a good way to approach this. | 13:46 |
| fungi | so, like, if measuring and reducing cyclomatic complexity is being seen as a potential solution to the stated concerns, try to interest some guinea pig projects in it or find ones who are already doing this and see how it's going, then do some analysis across all potentially effected projects to see what a reasonable target value might be before starting the larger discussion of making it a community | 13:46 |
| fungi | goal | 13:46 |
| smcginnis | I agree it's an issue that we should address. I just don't know how. | 13:47 |
| smcginnis | fungi: That could be a good start. | 13:47 |
| fungi | i don't mind discussing these problems in the abstract, but we need concrete recommendations which can be objectively evaluated across participating deliverables/teams before it's a suitable "goal" in the sense of the framework we've defined | 13:48 |
| fungi | so i agree with cdent that we shouldn't jump to solutions too quickly until we've got a good consensus on the problems we want to address, but once we do that we also shouldn't jump to a community goal too quickly once we think we might have some solutions | 13:50 |
| fungi | and definitely can't go from problems to some vague goal which nobody knows whether they're meeting or not | 13:52 |
| cdent | Setting some concrete measurable goals is a good thing, but what’s really (really!) needed here is cultural change, and that’s difficult to measure or delineate. It’s really more about inspriration. | 13:53 |
| openstackgerrit | Merged openstack/project-team-guide master: Add "How to Preview Release Notes at RC-time" https://review.openstack.org/497589 | 13:53 |
| fungi | cultural change probably needs to focus more on message and marketing, yeah | 13:54 |
| fungi | rhetoric even | 13:55 |
| ttx | In other news, I'd like to find an effective way to promote public cloud needs. the Public Cloud WG (soon to become a SIG) has a number of suggestions that I think should have more visibility @ https://docs.google.com/spreadsheets/d/1Mf8OAyTzZxCKzYHMgBl-QK_2-XSycSkOjqCyMTIedkA/edit#gid=0 | 13:55 |
| fungi | goals (in the tc cross-project goals sense) may reinforce cultural change, but they won't create it | 13:55 |
| ttx | The issue being, public cloud is at the far end of the usage spectrum, not so many users, but everyone in the ecosystem needs them | 13:56 |
| ttx | so it's hard to expect them to "show up and do the work" as much as it is from private cloud users wanting a feature | 13:56 |
| fungi | seems like public cloud would have _more_ users (consumers of the end product), just fewer operators/deployers | 13:57 |
| ttx | sure, different def of user | 13:57 |
| ttx | I mean, not so many different organizations | 13:57 |
| fungi | also public clouds tend to have more in-house development resources, and are more likely to want to extend/fork the software | 13:57 |
| fungi | and do home-grown deployments | 13:58 |
| ttx | we have tens of public cloud deployments and hundreds/thousands of private cloud deployments | 13:58 |
| fungi | rather than relying on distribution vendors and support organizations | 13:58 |
| ttx | fungi: I think that used to be true, but most of the current public clouds have less dev resource and deploy more vanilla openstack | 13:59 |
| ttx | agree on not relying on distro vendors as much | 13:59 |
| ttx | if only because the support contract cost math just doesn't work well | 13:59 |
| fungi | oh, fair point the ones who ran massive forks do tend to be atrophying and going extinct | 13:59 |
| fungi | seems like there's more of a competitive pressure on public clouds to "differentiate" themselves in what they see as a limited market | 14:00 |
| ttx | I think their differentiation is no longer against other openstack clouds though | 14:01 |
| ttx | They present interoperability between themselves as a differentiator against AWS/Google/Azure | 14:01 |
| fungi | that message we tried to push years ago about banding together to take on the major proprietary players is finally catching on? | 14:01 |
| ttx | i.e. "no lock in" | 14:01 |
| ttx | Like CityCloud said they were very happy to see more European OpenStack clouds | 14:02 |
| ttx | same for OVH | 14:02 |
| ttx | definitely not a zero-sum game | 14:02 |
| ttx | yes, the message is definitely catching on from what I hear | 14:03 |
| *** marst has joined #openstack-tc | 14:03 | |
| ttx | at least in Europe | 14:03 |
| fungi | or if it is zero-sum, the amount of market they have the potential to draw from outside is still a significantly more than what they already have | 14:03 |
| fungi | so might approach zero-sum across the spectrum of openstack/aws/gce/azure/misc | 14:04 |
| fungi | might make sense to carve up that public cloud wishlist a bit. some entries there definitely look like "if you run a public cloud this is something missing to help you do that" while others are more along the lines of "we've had a few customers request the ability to do this" | 14:08 |
| fungi | self-service sign-up for example, obvious benefit to public cloud use cases | 14:09 |
| fungi | volume multi-attach and multiple ceph? those are more general use case support features i could see all sorts of environments wanting, nothing public-cloud-specific | 14:10 |
| cdent | multi-attach, the feature that refuses to land | 14:12 |
| *** marst has quit IRC | 14:16 | |
| fungi | might make sense to qualify the list based on features most public cloud providers have cobbled together themselves but would rather not have to maintain (i.e. required for the general public cloud use case), features which reinforce interoperability/portability of workloads to help them band together against the proprietary services, and things customers have requested which would make their service | 14:18 |
| fungi | offering more competitive in the market | 14:18 |
| *** hongbin has joined #openstack-tc | 14:19 | |
| ttx | ack, a more categorized laundry list would not hurt | 14:20 |
| *** marst has joined #openstack-tc | 14:23 | |
| *** marst_ has joined #openstack-tc | 14:23 | |
| *** marst has quit IRC | 14:27 | |
| fungi | prioritizing the laundry list is a lot harder than prioritizing specific benefits | 14:30 |
| fungi | do we want to help public clouds gain market share from proprietary services? okay here's the list of features they'd need to make that task easier... (something about federation, vouchers, interoperability standards, stuff leveraged directly by cloud-bursting solutions...) | 14:31 |
| EmilienM | ttx: really nice reading https://ttx.re/queens-ptg.html | 14:33 |
| EmilienM | ttx: thanks! | 14:33 |
| cdent | ttx (or anyone else): Are openstack-specs (and its repo) dead, paused, on hiatus, or just slow? | 14:46 |
| fungi | good question... seems like cross-project specs process took a back seat when the goals work started up | 14:47 |
| mtreinish | cdent: heh, it's probably all of those | 14:47 |
| mtreinish | cdent: although it never really was active | 14:47 |
| cdent | We should consider killing it if it is in fact dead, otherwise it is effectively noise | 14:50 |
| ttx | cdent: it was one more attempt at describing cross-project work, I'd say it's mostly dead at this point. thingee is the reference there, but he is burning the man this week | 14:54 |
| cdent | as ya do | 14:54 |
| ttx | I feel like all those attempts fail because nobody really project-manage them to completion, as sdague once said | 14:55 |
| ttx | which is why we introduced goal champions this cycle | 14:55 |
| ttx | basically, having a cross-project spec or goal blessed by the TC is not enough to make it happen | 14:56 |
| ttx | you need at least one person taking significant time to make it happen | 14:56 |
| ttx | as proved by dhellmann and sdague and others on various topics | 14:57 |
| cdent | I think there’s some truth to that, but it also results in some of the changes sometimes feeling like they are just happening because the project managing person wants them to (which could be a good thing, not sure) | 15:07 |
| cdent | which can result in a bit of detachment or lack of awareness where things change out from under people | 15:08 |
| dhellmann | the problem is that we haven't really established a history of successfully motivating the community to act without a leader to keep applying pressure and reminding and tracking. To some extent that's natural, since we all come with our priorities, but it makes these sorts of initiatives harder because it's not like we have a large number of people willing and able to drive such large projects all the time. | 15:15 |
| dhellmann | the idea behind the goals process was originally that we'd use it as the motivational lever, but that hasn't proven to be an effective approach | 15:16 |
| cdent | well before we head back down the road of “how do we manage traction” should we consider destroying the openstack-specs repo? Or is that something we need thingee around to be able to decide? | 15:19 |
| * smcginnis lights a match | 15:19 | |
| dhellmann | the history in that repo is still useful, so I don't think we want to "destroy" it. We're already not using it. We could mark it as deprecated somehow. | 15:42 |
| smcginnis | Probably should update the README in there to state it is for historical reference, and update the docs index page with something similar. | 15:51 |
| cdent | dhellmann, smcginnis: if you guys thinks that’s a good way to proceed I’ll go ahead and propose something | 15:52 |
| smcginnis | cdent: Works for me. | 15:53 |
| *** dtantsur|busy is now known as dtantsur|afk | 15:53 | |
| dhellmann | ++ | 15:54 |
| cdent | ✔ | 15:54 |
| smcginnis | You and your fancy UTF-8. | 15:58 |
| cdent | it’s pretty much the only one I can remember | 16:01 |
| *** jpich has quit IRC | 16:38 | |
| * fungi can make √ with compose+v+/ but not sure whether there's a good compose sequence for ✔ | 17:49 | |
| cdent | ¶ | 17:50 |
| smcginnis | I just resort to here: • | 17:54 |
| smcginnis | Fail | 17:54 |
| smcginnis | https://github.com/dysfunc/ascii-emoji | 17:54 |
| cdent | 🎃 | 17:56 |
| * dhellmann wonders if a bunch of emoji-slinging teens have taken over the irc accounts of the tc | 17:57 | |
| cdent | omg ndb pos | 17:57 |
| smcginnis | LOLOL | 17:57 |
| * cdent hides | 17:58 | |
| smcginnis | It's not even a Friday. Must be the end of release. | 17:58 |
| cdent | 🤘🏼 | 17:59 |
| * dhellmann still spells his emoticons out in longhand | 17:59 | |
| cdent | i’ve got this (terrible) new macbook with the touchbar, it make emoji available by sliding around on the touchbar | 18:00 |
| cdent | do not recommend | 18:00 |
| smcginnis | No, not happy with it? | 18:00 |
| cdent | internally it’s great: fast cpu and disk. the screen is really nice. but for my typing style the keyboard has _way_ too little movement and the trackpad is too big. the touchbar is a neat trick but it means most of the things you would have done with the keys that used to be there now involve more cognitive steps | 18:01 |
| mtreinish | cdent: heh, having the touch bar for a function row was bad on the 2nd gen x1 carbon I used to have too | 18:02 |
| smcginnis | That trackpad is ridiculously large. | 18:02 |
| smcginnis | Not a mac person, but I've considered one just because my current work VPN options are either Mac or Windows. Lesser of two weevils. | 18:02 |
| cdent | ewwww | 18:03 |
| cdent | that’s an unfortunate set of choices | 18:03 |
| mtreinish | smcginnis: route the traffic through a windows vm? Assuming you can do that in windows | 18:03 |
| cdent | i have read of some people doing that kind of thing | 18:03 |
| cdent | having to run a whole windows vm for that is icky though | 18:04 |
| smcginnis | mtreinish: I could look into that. Just annoying travelling to have to do that. | 18:04 |
| fungi | as someone who builds portable computers with _no_ pointer device at all, having a touchpad take up so much real estate would drive me bonkers | 18:07 |
| smcginnis | fungi: Hah, I think the touchpad is larger than your entire setup. | 18:07 |
| fungi | frightening | 18:08 |
| cdent | it’s pretty good at dealing with accidental taps from things like the base of the palm, but if you slide, it can get confused. I sadly had to turn on click to click (I usually prefer tap to click) | 18:11 |
| *** cdent has quit IRC | 19:13 | |
| *** gcb has quit IRC | 19:33 | |
| *** marst has joined #openstack-tc | 21:58 | |
| *** marst_ has quit IRC | 22:01 | |
| *** dtroyer has quit IRC | 22:14 | |
| *** lbragstad has quit IRC | 22:20 | |
| *** dtroyer has joined #openstack-tc | 22:40 | |
| *** marst has quit IRC | 23:24 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!