[GSoC] migration

[Umesh Singla]

Hi Rainer,

I have already created a new branch gsoc17-migrate in macports-base after
discussing with Jackson on IRC and just now, pushed some initial code to
https://github.com/macports/macports-base/tree/gsoc17-migrate, to begin
with. For the copyright part, I'll just ignore it, for now, it doesn't seem
to be a big deal.

Thanks

On Fri, Jun 9, 2017 at 5:18 AM, Rainer Müller <raimue at macports.org> wrote:

> Hello Umesh,
>
> good to hear from you! I was afraid we had already lost you...
>
> Where you will push your work to? Either create a new branch (e.g.
> gsoc17-migration) in macports/macports-base, or push to your own github
> account. It would be good to know which place to watch for updates.
>
> I will answer some of other questions inline below.
>
> On 2017-06-09 00:38, Umesh Singla wrote:
> > 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?
>
> Such a check already exists, which is executed an every initialization
> of the macports1.0 package. As this is just a simple compare of the OS
> version, it is no problem to run this every time. Currently it prints a
> link to the Migration wiki page:
>
> https://github.com/macports/macports-base/blob/
> e3a0dc2ebde62a9c5feac6a1edee1708a95bb02a/src/macports1.0/
> macports.tcl#L651-L656
>
> > 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?
>
> The following goes with the usual IANAL disclaimer. In almost all
> jurisdictions, you own the copyright from the moment you create
> something. There is no need to explicitly claim copyright any more
> (mostly after USA reformed their copyright law in 1989). The headers in
> source code files have pure informational use.
>
> In my opinion, it only makes sense to list authors who contributed a
> significant amount of code to the file. Most of files in base should
> already list "The MacPorts Project". Although not being a legal entity,
> this is a kind of placeholder for all contributors holding the joint
> copyright ownership.
>
>
> While I could not answer all your questions right now (I have to leave
> some work for Bradley ;-)), feel free to ask questions as much as you
> like on the list or via IRC.
>
> Happy hacking on your project!
>
> Rainer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170609/188d42b3/attachment.html>