list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Kaartic Sivaraam <>
To: Elijah Newren <>
Cc: Sangeeta NB <>,
	Christian Couder <>,
	Git List <>
Subject: Re: [Outreachy][Proposal] Accelerate rename detection and the range-diff
Date: Tue, 3 Nov 2020 00:05:29 +0530	[thread overview]
Message-ID: <> (raw)
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.


      reply	other threads:[~2020-11-02 18:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-26  7:49 Sangeeta NB
2020-10-26 16:52 ` Elijah Newren
2020-10-30  9:02   ` Kaartic Sivaraam
2020-10-31 20:31     ` Elijah Newren
2020-11-02 18:35       ` Kaartic Sivaraam [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [Outreachy][Proposal] Accelerate rename detection and the range-diff' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).