<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
Hi Mihir,<br>
<br>
On Thu, Mar 28, 2019 at 12:07:20AM +0530, Mihir Luthra wrote:<br>
> On Wed, Mar 27, 2019 at 10:22 PM Mojca Miklavec <<a href="mailto:mojca@macports.org" target="_blank">mojca@macports.org</a>> wrote:<br>
> > What I miss a bit is some clear definition of deliverables, what<br>
> > pieces of code would be suitable enough for merging them into base<br>
> > and when.<br>
> ><br>
> > Background: One of the problems with many earlier projects with<br>
> > macports base was that a student was working all summer in his own<br>
> > branch, waiting for the code to be "complete and well-tested", and<br>
> > the code was subsequently never merged into the trunk / master, or<br>
> > maybe it's still considered useful, just not 100% polished, and some<br>
> > members still plan to clean up and merge the code as old as 10<br>
> > years. On the other hand, if the code ends up in the master branch<br>
> > early and some issues are discovered, they would still be fixed. If<br>
> > the code lies in its own branch, it doesn't get nearly as much<br>
> > testing and might get forgotten.<br>
> ><br>
> > Of course you cannot always merge immediately, as some pieces might<br>
> > need a bigger pile of code at once to produce something useful<br>
> > without breaking stuff. But it would be very helpful if some code<br>
> > could be merged into master at least once per week. If you could<br>
> > split it into smaller reasonable chunks, it would be even better to<br>
> > do this on an almost daily basis when possible (it's still ok to<br>
> > have two weeks of some bigger feature rework in the meantime).<br>
<br>
I'd like to second Mojca's feedback on this. There should be clear<br>
milestones with dates and you should have a rough plan on what you're<br>
going to implement over the summer. In my experience, projects that<br>
start out designing the solution during the implementation period tend<br>
to run into time problems later on and don't finish.<br>
<br>
In terms of your proposal, that likely means you should look up<br>
literature on one or two, at most three data structures that you would<br>
deem suitable for the task (like the arXiv link I sent you) and maybe<br>
have a clear plan on how to compare them and choose one as an action<br>
item in your plan, but not a period of "look up potential data<br>
structures", because that task would have a time boundary.</blockquote><div><br></div><div>Understood. I will update the draft asap. ^_^ </div><div><br></div></div></div>