14 | | MacPorts is a ports collection and packaging system for OS X. Created in 2002 as !DarwinPorts, we have an ever-growing collection of ports (currently over 16500), many of which accept multiple configuration variants. MacPorts is one of the primary means of building and installing open source software on OS X, making it an important interface between OS X and the rest of the open source world. |
| 17 | MacPorts is a ports collection and packaging system for OS X. |
| 18 | Created in 2002 as !DarwinPorts, we have an ever-growing collection |
| 19 | of ports (currently over 16500), many of which accept multiple |
| 20 | configuration variants. MacPorts is one of the primary means of |
| 21 | building and installing open source software on OS X, making it an |
| 22 | important interface between OS X and the rest of the open source |
| 23 | world. |
17 | | We apply once more as we hope to implement new features in MacPorts. We also intend to attract new developers to our project and its community. With new feature additions and enhancements to our components (e.g. our GUI), we hope to become more user-friendly for the average OS X user and further increase the quality of our packages. Some big goals this year are improving dependency resolution and minimizing MacPorts’ dependency on Xcode (since we now provide pre-built binaries, and Apple now provides standalone CLI tools). |
| 26 | We apply once more as we hope to implement new features in MacPorts. |
| 27 | We also intend to attract new developers to our project and its |
| 28 | community. With new feature additions and enhancements to our |
| 29 | components (e.g. our GUI), we hope to become more user-friendly for |
| 30 | the average OS X user and further increase the quality of our |
| 31 | packages. Some big goals this year are improving dependency |
| 32 | resolution and minimizing MacPorts’ dependency on Xcode (since we |
| 33 | now provide pre-built binaries, and Apple now provides standalone |
| 34 | CLI tools). |
24 | | MacPorts has taken part multiple times in the program since 2007 and greatly appreciates those contributions. Most of our students completed their projects successfully. We had previous GSoC students coming back as mentors in the following years; for example, our backup administrator was a student for our organization back in GSoC 2011. |
| 41 | MacPorts has taken part multiple times in the program since 2007 and |
| 42 | greatly appreciates those contributions. Most of our students completed |
| 43 | their projects successfully. We had previous GSoC students coming back |
| 44 | as mentors in the following years; for example, our backup administrator |
| 45 | was a student for our organization back in GSoC 2011. |
55 | | Rainer was previously a GSoC mentor, and as a MacPorts manager he brings great experience in our base code. Clemens was a GSoC student, and after completion of his project has stayed with us and implemented many new features in the base code. He can also be influential in helping get people setup for editing Tcl/Tk if they're new to it, since he went through it! Clemens took backup admin when I moved from mentor to admin when Rainer was too busy last year, and we’ve kept that structure this year. Lawrence is also contributing greatly to our base code, specifically ensuring packages are built with compilers they “support”. This is very helpful as some packages still don’t build right on Clang, or have legacy issues with old Apple GCC. His efforts allow MacPorts to switch out compilers based on their version for a given package. |
| 79 | Rainer was previously a GSoC mentor, and as a MacPorts manager he brings |
| 80 | great experience in our base code. Clemens was a GSoC student, and after |
| 81 | completion of his project has stayed with us and implemented many new |
| 82 | features in the base code. He can also be influential in helping get |
| 83 | people setup for editing Tcl/Tk if they're new to it, since he went |
| 84 | through it! Clemens took backup admin when I moved from mentor to admin |
| 85 | when Rainer was too busy last year, and we’ve kept that structure this |
| 86 | year. Lawrence is also contributing greatly to our base code, |
| 87 | specifically ensuring packages are built with compilers they “support”. |
| 88 | This is very helpful as some packages still don’t build right on Clang, |
| 89 | or have legacy issues with old Apple GCC. His efforts allow MacPorts to |
| 90 | switch out compilers based on their version for a given package. |
61 | | We require contact information from our students as part of the application. Students should report their progress to their mentor at least once a week, via whichever communication medium works best for both. We know from past experiences that a student can just disappear without any notice, but if this happens we will not let them pass the midterm or final evaluation. We will make this clear from the start, and students will be urged to maintain regular communication. |
| 97 | We require contact information from our students as part of the |
| 98 | application. Students should report their progress to their mentor |
| 99 | at least once a week, via whichever communication medium works best |
| 100 | for both. We know from past experiences that a student can just |
| 101 | disappear without any notice, but if this happens we will not let |
| 102 | them pass the midterm or final evaluation. We will make this clear |
| 103 | from the start, and students will be urged to maintain regular |
| 104 | communication. |
71 | | Projects will usually have multiple mentors, to provide redundancy if one disappears. If a student cannot reach any of their mentors, they should contact an organization administrator, who will have more contact information. If somehow that fails, they should post to the development mailing list, to send people after myself and the backup admin. |
| 121 | Projects will usually have multiple mentors, to provide redundancy if |
| 122 | one disappears. If a student cannot reach any of their mentors, they |
| 123 | should contact an organization administrator, who will have more contact |
| 124 | information. If somehow that fails, they should post to the development |
| 125 | mailing list, to send people after myself and the backup admin. |
76 | | We like to make contact with our students even before they submit their application, via IRC or on our mailing list. During the application phase we will refine and discuss proposals with other developers. In the program, students participate in the normal development process: They get their own Subversion branch to work on, all their commits are publicly viewable, and any member of the MacPorts community can provide feedback by replying to the commit system’s emails. We also like students to post status reports to the public development mailing list as they reach specific milestones. By requiring communication with people other than their mentors, we encourage them to work in the spirit of open source development. |
| 130 | We like to make contact with our students even before they submit their |
| 131 | application, via IRC or on our mailing list. During the application |
| 132 | phase we will refine and discuss proposals with other developers. In the |
| 133 | program, students participate in the normal development process: They |
| 134 | get their own Subversion branch to work on, all their commits are |
| 135 | publicly viewable, and any member of the MacPorts community can provide |
| 136 | feedback by replying to the commit system’s emails. We also like |
| 137 | students to post status reports to the public development mailing list |
| 138 | as they reach specific milestones. By requiring communication with |
| 139 | people other than their mentors, we encourage them to work in the spirit |
| 140 | of open source development. |
78 | | As we let students work as one of the organization’s developers, we look forward to their continued development of MacPorts after GSoC concludes. Like any other developer, they will get regular commit privileges to help the project as they see fit; this also provides an introduction to future work. Multiple students have returned as mentors in the following years, demonstrating the effectiveness of this method. |
| 142 | As we let students work as one of the organization’s developers, we look |
| 143 | forward to their continued development of MacPorts after GSoC concludes. |
| 144 | Like any other developer, they will get regular commit privileges to |
| 145 | help the project as they see fit; this also provides an introduction to |
| 146 | future work. Multiple students have returned as mentors in the following |
| 147 | years, demonstrating the effectiveness of this method. |
88 | | We keep all students’ work in our source repository, and rebase it often so it’s ready to be integrated. Seeing a student’s code “go live” and get used by the project is the single best incentive. We also plan to keep in contact with the student to see if there are additional areas of MacPorts that might interest them for long-term involvement. |
| 157 | We keep all students’ work in our source repository, and rebase it |
| 158 | often so it’s ready to be integrated. Seeing a student’s code “go |
| 159 | live” and get used by the project is the single best incentive. We |
| 160 | also plan to keep in contact with the student to see if there are |
| 161 | additional areas of MacPorts that might interest them for long-term |
| 162 | involvement. |