From: Kaartic Sivaraam Date: Mon, 02 Nov 2020 18:35:29 GMT Subject: Re: [Outreachy][Proposal] Accelerate rename detection and the range-diff Message-ID: In-Reply-To: Hi Elijah, On 01/11/20 2:01 am, Elijah Newren wrote: > > On Fri, Oct 30, 2020 at 2:02 AM Kaartic Sivaraam > 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