Re: [Outreachy][Proposal] Accelerate rename detection and the range-diff

From: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Date: Nov 2, 2020, 18:35 UTC
Message-ID: <af22d119-7ab9-d49e-279c-c912786098dd@gmail.com>
In-Reply-To: <CABPp-BE7+9_AiYCP+m7TOY85d4FWHG4rORk16Z6bsnAWxVPwCg@mail.gmail.com>

Hi Elijah,

On 01/11/20 2:01 am, Elijah Newren wrote:

Show 19 quoted lines

> 
> On Fri, Oct 30, 2020 at 2:02 AM Kaartic Sivaraam
> <kaartic.sivaraam@gmail.com> 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.

Show 17 quoted lines

>> - 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.

Show 5 quoted lines

> 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