<div dir="ltr"><div>Forwarding this to macports-dev mailing list once again, as I was not subscribed to the mailing list with my @macports address.</div><div><br></div><div>Thanks</div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Umesh Singla</b> <span dir="ltr"><<a href="mailto:umeshksingla@macports.org" target="_blank">umeshksingla@macports.org</a>></span><br>Date: Fri, Jun 9, 2017 at 3:42 AM<br>Subject: Re: Urgent communication required<br>To: Bradley Giesbrecht <<a href="mailto:pixilla@macports.org" target="_blank">pixilla@macports.org</a>><br>Cc: MacPorts Dev <<a href="mailto:macports-dev@lists.macports.org" target="_blank">macports-dev@lists.macports.<wbr>org</a>><br><br><br><div dir="ltr">Hi Bradley, <div><br><div>I'm very sorry to not communicate for a long time. I did not plan any absence before and yes, I'll update you every detail from now on, better to be transparent about any other commitments and my work. I'm bad at communicating and I should not let it reflect here. Someone suggested pushing your work even if it is incomplete, it acts like a record or backup for your record, I can feel the importance of it now.</div><div><br></div><div><br></div><div>1. The agenda as per the proposal timeline [1] for the period from May 30 to Jun 10 is to finalize the different cases to be included in the scope of the project and their priorities, plan the design of the procedures to be written in port.tcl (now in snapshot.tcl and migrate.tcl in macports1.0) and begin with the implementation of the snapshot action. So, for now, we'll be focusing only on the specific snapshot action.</div><div><br></div><div>I have not followed Rainer's strategy for having `port snapshot --create` and `port snapshot --restore` as discussed in the previous thread, instead have 3 separate actions. Since we agreed on other use cases as well during the proposal submission time like only keeping a snapshot for now, listing the snapshots to choose from later etc. which will be cumbersome if we resort to `port snapshot <--create, list, migrate, restore>` and could be confusing at times. </div></div><div><br></div><div><br></div><div>2. In the proposal, I had written "what would be desirable is if `port` was to <i>recommend</i> a migration upon detecting a new environment", so we can have it two ways - either check for the changes in the environment before running every command or only check for the changes when a user actually uses restore (or migrate) action. </div><div><br></div><div>While the first one seems to be more realistic from user's perspective but running it every time is also not a good idea since OS/hardware changes are not frequent. I suggest running the detection for changes in architecture before a set of some commands like install, sync, selfupdate etc. The second option is actually on-top-of-head type solution which assumes the user to be aware of any arch changes by himself and thus, is actually not "recommending". Please suggest a way to proceed.<br></div><div><br></div><div>Also, is there any existing action which checks for changes in the environment which I can use as a reference. I checked selfupdate but it only checks how old port definitions are. Is it sufficed to check for universal_arch/build_arch like options in `macports.conf` file, comparing it with `uname -a` or `env` command outputs. How rigorous we need the detection to be?</div><div><br></div><div><br></div><div>3. For the flow, I am following the strategy of diagnose: Add the action in action_array list -> call macports::snapshot_main{} -> call main{} from namespace eval snapshot procedure with opts. If you have another specific flow in mind like you had a nice solution of going with 3 actions before and we finally sorted to that, please share. I'm thinking about adding the detection procedure as a middleware once we finalize the strategy to follow for it, as discussed in the previous point. </div><div><br></div><div><br></div><div>4. Another thing that ran my mind while pondering that there are 2 options for sqlite database as well: make the tables in the very beginning (while initial installation) or while running the snapshot for the first time. I suggest to go with the first one because it's simple.</div><div>The major target is to finish the snapshot action before Jun 24.</div><div><br></div><div><br></div><div>5. I saw the copyright license on top of most of the files. Do developers have this, right from the beginning or after the initial work on the module gets finished?</div><div><br></div><div><br></div><div>6. One request, I asked this before too, can we please, please fix some time for IRC/Hangouts meeting at least a week for the beginning if it's comfortable with you or Clemens or other people involved? This will help me keep on track. I am a person who can only work under strict deadlines. I have failed under loose deadlines before.</div><div><br></div><div>Also, Brad, I have missed one of your emails in the past, too, even after marking them important. For some reason, it ended up in spam folder. Please check the screenshot if it is of some use.</div><div><br></div><div>I again apologize.</div><div><br></div><div>Regards,</div><div>Umesh</div><div><br></div><div>[1]: <a href="https://docs.google.com/document/d/1w5d3MPovc5eWfy5rI33lnnOvMQMghDYkTH1GOPnRcXM/edit?usp=sharing" target="_blank">https://docs.google.com/d<wbr>ocument/d/1w5d3MPovc5eWfy5rI33<wbr>lnnOvMQMghDYkTH1GOPnRcXM/edit?<wbr>usp=sharing</a></div><div><br></div></div><div class="m_-7511102419332939170gmail-HOEnZb"><div class="m_-7511102419332939170gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 8, 2017 at 7:57 PM, Bradley Giesbrecht <span dir="ltr"><<a href="mailto:pixilla@macports.org" target="_blank">pixilla@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Umesh:<br>
<br>
<br>
The GSoC 2017 coding period began May 30th, 2017. I have not received any communications from you and your project blog has not been updated since your first post.<br>
<br>
If you have a planned absence you must communicate in advance. If you do not communicate effectively this project will not be successful and you will be in jeopardy of failing your evaluation.<br>
<br>
I hope you respond favorably to this notice so we can all do are part to have a successful project thereby maintaining and enhancing our reputations.<br>
<br>
Here is a good blog post [1] I encourage you to read.<br>
<br>
<br>
[1] “The DOs and DON’Ts of Google Summer of Code: Student Edition” <a href="https://opensource.googleblog.com/2011/03/dos-and-donts-of-google-summer-of-code.html" rel="noreferrer" target="_blank">https://opensource.googleblog.<wbr>com/2011/03/dos-and-donts-of-g<wbr>oogle-summer-of-code.html</a><br>
<br>
<br>
Regards,<br>
Bradley Giesbrecht (pixilla)<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div>
</div></div></div><br><br clear="all"><div><br></div>-- <br><div class="m_-7511102419332939170gmail_signature"><div dir="ltr">Umesh Singla</div></div>
</div>