23 April
Participants:
- Bernard
- Ernest
- Ilan
- Georgia
- Paul
- Pradyun
- Sumana
- Tzu-Ping
Agenda:
- Checkin on how people are personally doing [private for team members]
- UX outputs
- Georgia: I think we jsut need to pull that together. We were going through the responses together. We'll pull together numbers, sample responses into a thing. thing might be blog post.
- Bernard: Yea, blog post. Opened a GH issue that isn't completed yet, how this is going to turn into dev-work. In terms of info users need to see; what format it takes.
GitHub issue: #i
- Sumana: so... in progress, have understanding of what kinds of information is involved.
- Sumana: Anything you're waiting on? Anything you need?
- No. The time we spent today was useful. It'd difficult to understand the implications of user responses on the resolver code / implementation.
- Need Pradyun or a similar person to help analyze things
- Pradyun: Happy to talk about this later.
- Estimated date of delivery: raw data, early next week, maybe Tuesday the 28th.... then ask feedback in order to make it useful for the resolver team.
- Ilan and testing
- "Now that you are ramped up and understand our current test format and codebase, we need you to give us new tests for additional resolution scenarios. That's the most important thing that we need from you and you should spend the rest of your 70 hours of contract time on writing new tests, submitting them to us, and responding to our revision requests. We would really like these tests in place by about May 4th-8th. That means that you would submit more pull requests this week and next week, and finish them up and get them merged, ideally, by about 2 weeks from now. Is that feasible?"
Pradyun: there's a tradeoff re time spent improving test infrastructure & existing YAML tests versus writing new tests ... until we finish a scaffold started in one of the meetings ... there are some requests Paul has made that would be very handy.
- Paul: key thing is -- I want lots of tests I can fire at the resolver. That is on the critical path. I want lots of complicated tests to aid what I can come up with. Tiny proviso: having them in the test suite is important. But also being able to generate test data standalone, or run a few of them manually, to compare old and new pip, are a huge plus. Right now I am struggling with not having complicated examples of test data.
- Tzu-Ping: Feels similarly to Paul. Wants lots of tests against resolver.
TODO: Pradyun to make a GitHub issue about the test infrastructure scaffolding work that Ilan started? working on?
- There's a PR that makes tests run on new resolver... there are niceties we could add
- Ilan: Paul, what do you mean by more complicated tests?
- Lots of dependencies, things that force a lot of backtracking
- Sumana: go back into your history - find things that caused problems for you, mine those.
- Pradyun: Look in Zulip, in the Resolver Testing topic for a lot of good raw material.
- "Now that you are ramped up and understand our current test format and codebase, we need you to give us new tests for additional resolution scenarios. That's the most important thing that we need from you and you should spend the rest of your 70 hours of contract time on writing new tests, submitting them to us, and responding to our revision requests. We would really like these tests in place by about May 4th-8th. That means that you would submit more pull requests this week and next week, and finish them up and get them merged, ideally, by about 2 weeks from now. Is that feasible?"
- Expectations for release schedule
- pip 20.1.0 - Tuesday the 28th
- the beta came out a few days ago
- Pradyun would like to: all the highlights we pointed out in the release announcement: go on the original tracking issue for those, and say "this is in our beta, could you test it?"
- TODO: Pradyun: go ahead and do it
- beta for widespread testing of the resolver
- currently alpha
- We planned for a May beta -- something that's stable and something that's well tested.
- Paul: key milestone for making that statement is that the tests pass and -- reasonable pace for making our way through the tests. Biggest concern re this timescale: dealing with the tests where the new resolver is putting out a slightly different message compared to the old one. We will have to change the tests to adjust to the new tests. We don't know how long a slog this will be. Concerns me that it might take work away from other stuff we are doing that needs doing but is not well-represented in tests.
- Tzu-Ping: I think timeline is workable and am conservatively confident they can be achieved if things go as planned. There are ~5 things we need to work on before we get beta out. Paul mentioned the different messaging problem. I think/we think we have fixed/can fix things. That can partly be part of the beta process
Paul: Revising earlier statement.... earlier I was thinking we need to focus TP, P, & P on getting code dealt with .... this means that the UX stuff ... I would prefer to focus on delivering code at expense of that if we are to meet that deadline ... if we have too many discussions re improving UX, we may not meet end-of-May
Pradyun: that was my point too. What Paul said. I am pretty sure we can do this by May if we just want to get the bare minimums done, get a test-case-passing thing out the door. But not superpolished & looks good. Won't give you a traceback when it fails, but non-nice error message.... not sure how high we want to prioritize that. Would like it to be a lot higher. But big problem to do a good job - difficult. old resolver was not great at this
- Bernard: I understand that, and it makes sense to get something _made_. In that time is there anything specific that I need to work on? I need some decision/direction (sometime).
- conflict deps output in the meantime: :thumsup:).
- Bernard: I understand that, and it makes sense to get something _made_. In that time is there anything specific that I need to work on? I need some decision/direction (sometime).
- pip 20.1.0 - Tuesday the 28th
- Contract logistics (end of May is approaching)
TP & (maybe) Paul: some avail in June
- More frequent high-bandwidth conversations, plus trying to be transparent
- Bernard: +1 for more frequent video/audio working - focusing on work I need input from others. It needs to stay on topic tho'. I have no feelings on video or not. I'll go with others opinions.
- Sumana: There is a divide here -- those who work better on a co-working all-the-time, more live high-bandwidth conversation. It does make sense to have higher bandwidth discussions as we move closer to the beta.
- Paul: if we have more video-type calls, can we be clear what the topic is? makes it easier going into something like that. +1
- Sumana: 2 types of thing: general "we're in the same room" thing, and agenda-type meetings
- set expectation early on
Pradyun: P, TP & I have multiple-times-per-week syncups for devs, unstructured, but agenda set when meeting happens, but Pradyun wants something like that with Bernard & Georgia.
Bernard: the collab sessions (today & 2 weeks ago) worked well for me because I came with "this is what I want input on" - I am desperate for more input from resolver team
- Sumana: ok! we will set up more high-bandwidth times for you, but you will not be able to get all of the input you want in meetings and you will need to get some of it asynchronously
- TODO: Bethanie to find some meeting times for 1-hr or additional half-hour times for subset of team
- TODO: Sumana to talk in Zulip about the transparency concern
- Sumana: 2 types of thing: general "we're in the same room" thing, and agenda-type meetings
TODO:
- talk with Bernard to explain yanking - DONE (at least initially)
[End of meeting.]