Hi Elijah, On 01/11/20 2:01 am, Elijah Newren wrote:
On Fri, Oct 30, 2020 at 2:02 AM Kaartic Sivaraam <kaartic.sivaraam@xxxxxxxxx> wrote:Thanks for the detailed concerns. Some thoughts: - Given that a major portion of the project would be to evaluate various algorithms and identifying the most suitable one, I believe implementation conflict shouldn't be a problem as it's expected to start only by late-January. Also, as Christian pointed out elsewhere it might be a good learning experience."late-January" _might_ be okay, but I'm worried that relying on optimistic timelines is a bad idea. However, if the primary purpose is a good learning experience, or if the primary purpose is to evaluate different algorithms (i.e. we're not relying on the timelines to avoid conflict, it's just a bonus if they don't), then sure, no problem there.
Yeah. I believe a good part of this project would be evaluating the various algorithms. Implementation would be a part of it, sure. I don't think it would be too time sensitive, though. So, I hope we can work through the timelines as the project and your work progress.
- I do have a concern about one thing, though. For evaluating the algorithm in the context of Git, we might need to do some experimental implementations to get some metrics which would serve as the data that we could use to identify the optimal algorithm. I'm wondering whether your planned changes might affect that. In the sense that, is there a chance for the evaluation to become obsolete as a consequence of those changes? If yes, what could we do to overcome that? Any thoughts on this would be helpful.That is certainly a possibility, yes. One way to address that concern is for me to freeze some branch (likely some version that I deploy internally at $DAYJOB for testing), and for you to build on that. If all the new merge backend code gets reviewed and upstreamed fast enough, and the areas you depend on don't change too drastically based on reviewer comments, then building on merge-ort creates no impediments for the Outreachy project to get upstreamed at the normal time.
Thanks. That does sound like a good way to overcome that problem. We can discuss more about that once the intern is selected and their internship period begins.
I can understand, though, if that plan seems worrisome due to worries about how fast the new backend will be upstreamed or how much it needs to change in the process; that is, after all, why I raised my concerns in the first place.
Which indeed is very helpful for planning the project. Thanks for that! Its pretty clear now that closely following your work and adapting the timeline accordingly as time progresses is a part of the project. That might indeed be an interesting experience in and of itself for the intern who would be working on this project.
-- Sivaraam
