From: Kaartic Sivaraam <email@example.com> To: Elijah Newren <firstname.lastname@example.org> Cc: Sangeeta NB <email@example.com>, Christian Couder <firstname.lastname@example.org>, Git List <email@example.com> Subject: Re: [Outreachy][Proposal] Accelerate rename detection and the range-diff Date: Tue, 3 Nov 2020 00:05:29 +0530 [thread overview] Message-ID: <firstname.lastname@example.org> (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 > <email@example.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
prev parent 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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).