GSoC 2019 [Phase out dependency on Xcode]

[Mojca Miklavec]

Dear Satryaji,

On Fri, 29 Mar 2019 at 09:35, Satryaji Aulia <satraul at gmail.com> wrote:
>
> Hi Marcus, I’m a final-year student from University of Indonesia interested in contributing to MacPort, and I’m working on my proposal right now.
>
> I’d like to ask about the Phase out dependency on Xcode project idea on the Wiki page.
>
> Just making sure of the flow: user/maintainer installs a Port using trace mode (-t), if it turns out it the Port needs the full Xcode package, it outputs:
> - An error message if full Xcode is not installed.
> - A warning message if use_xcode yes in the Portfile is not set.
> Thus, all the contributions are to be made on the macports-base repo. Correct?
>
> In achieving this, exactly which parts of the codebase need to be modified and how do you detect that a package needs full Xcode?
>
> I understand that trace mode reads filenames that are accessed using DYLD_INSERT_LIBRARIES. Do we compare these filenames to a list of filenames that are from the full Xcode?


I would love to be able to respond to your enquiry, but I'm not so
familiar with the part of the code that handles this to be able to be
of any help as far as the contents go.

I hope that Marcus (or Clemens or anyone else from the core group)
reply as soon as possible.


Some general feedback though:

- "Demonstrate ability to MacPorts mentor if needed": this needs to be
done *BEFORE* the selection process rather than until May. That
basically means until the 9th of April + maybe a short buffer beyond
(until we cast the vote and request the desired number of slots to
Google). It would be awesome if you could (with help of others, of
course) try to create some pull requests to demonstrate your
capability of contributing and solving problems, even if the
contributions start from very small ones. Proving to us that you could
make some awesome contribution during the summer (before we select
students) is probably the only way to get accepted.

- "Consult with mentors to identify which parts of the codebase need
to be modified": this needs to be done before the end of application
period (9th of April). You need to understand the problem and have an
idea of what needs to be done before you can make a good proposal.

- "Open a merge request and review with mentors": this should ideally
be done on regular basis (ideally every few days) and by the time of
*FIRST* evaluation you should ideally already have some functional
improvements merged to the codebase. Planning to have the first code
merged only after two months (+ all of the usual delays that you
forgot to count in) is probably way too late into the process.

Mojca

(It wasn't my intention to scare you off, and I hope I didn't :) :) :)