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 <[email protected]> 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 >
