Fwd: Urgent communication required

[Umesh Singla]

Forwarding this to macports-dev mailing list once again, as I was not
subscribed to the mailing list with my @macports address.

Thanks

---------- Forwarded message ----------
From: Umesh Singla <umeshksingla at macports.org>
Date: Fri, Jun 9, 2017 at 3:42 AM
Subject: Re: Urgent communication required
To: Bradley Giesbrecht <pixilla at macports.org>
Cc: MacPorts Dev <macports-dev at lists.macports.org>


Hi Bradley,

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.


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.

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.


2. In the proposal, I had written "what would be desirable is if `port` was
to *recommend* 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.

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.

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?


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.


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.
The major target is to finish the snapshot action before Jun 24.


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?


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.

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.

I again apologize.

Regards,
Umesh

[1]: https://docs.google.com/document/d/1w5d3MPovc5eWfy5rI33
lnnOvMQMghDYkTH1GOPnRcXM/edit?usp=sharing


On Thu, Jun 8, 2017 at 7:57 PM, Bradley Giesbrecht <pixilla at macports.org>
wrote:

> Umesh:
>
>
> 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.
>
> 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.
>
> 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.
>
> Here is a good blog post [1] I encourage you to read.
>
>
> [1] “The DOs and DON’Ts of Google Summer of Code: Student Edition”
> https://opensource.googleblog.com/2011/03/dos-and-donts-of-g
> oogle-summer-of-code.html
>
>
> Regards,
> Bradley Giesbrecht (pixilla)
>
>
>
>
>



-- 
Umesh Singla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170609/a530accd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2017-06-09 at 3.18.20 AM.png
Type: image/png
Size: 176275 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170609/a530accd/attachment-0001.png>