git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
To: Elijah Newren <newren@gmail.com>
Cc: Sangeeta NB <sangunb09@gmail.com>,
	Christian Couder <christian.couder@gmail.com>,
	Git List <git@vger.kernel.org>
Subject: Re: [Outreachy][Proposal] Accelerate rename detection and the range-diff
Date: Tue, 3 Nov 2020 00:05:29 +0530	[thread overview]
Message-ID: <af22d119-7ab9-d49e-279c-c912786098dd@gmail.com> (raw)
In-Reply-To: <CABPp-BE7+9_AiYCP+m7TOY85d4FWHG4rORk16Z6bsnAWxVPwCg@mail.gmail.com>

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

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

      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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=af22d119-7ab9-d49e-279c-c912786098dd@gmail.com \
    --to=kaartic.sivaraam@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=sangunb09@gmail.com \
    --subject='Re: [Outreachy][Proposal] Accelerate rename detection and the range-diff' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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:

	https://80x24.org/mirrors/git.git

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