Changes between Version 122 and Version 123 of SummerOfCode


Ignore:
Timestamp:
Mar 9, 2010, 6:01:25 PM (14 years ago)
Author:
raimue (Rainer Müller)
Comment:

Reorder tasks a little bit

Legend:

Unmodified
Added
Removed
Modified
  • SummerOfCode

    v122 v123  
    5757=== Core Tasks ===
    5858
    59 ==== Dependencies ==== #dependencies
    60 
    61 This task consists of implementing a new dependencies engine for MacPorts. The current dependency engine properly deals with installing packages, but it does not deal satisfactorily with dependencies on variants (and versions), uninstalling and upgrading. This very challenging task requires a complete formalization of the use cases (installation, upgrade, uninstallation) and of the user needs before any implementation, as well as a deep understanding of the dependency relations (required for fetching, building, configuring; static and dynamic linking; dependence at runtime).
    62 
    63 Classification: very challenging task[[BR]]
    64 Programming languages: Tcl and C[[BR]]
    65 Potential mentors: TBD
    66 
    67 {{{
    68 #!comment
    69 # Done 2009
    70 ==== Logging ==== #logging
    71 
    72 Currently MacPorts has no notion of logging of build activities of a given port or sets of ports. When a build is attempted but an error keeps it from completing, there's no way to track the problem other than the build progress that was output to the terminal, if verbose mode was requested in the first place. Otherwise, the build environment has to be pruned and the build attempted once again to even get a look at the precise error message. This is particularly problematic when automated builds are attempted, since there's usually no one around to have a look at the failure spew. An infrastructure to remedy this situation and endow MacPorts with a rich set of logging capabilities has to be developed to open up the door to true automated build runs of large sets of ports and thus to packaging of binaries, since with logging we'd have a fully reliable way of catching, reporting and processing of all sorts of fetch/configure/build/destroot/install/etc errors.
    73 
    74 This could be extended with the interaction with a server side application like MPWA that could consume these logs (read MPWA proposal). A more detailed draft of this task can be found on the LoggingProposal page.
    75 
    76 Classification: medium task to relatively challenging[[BR]]
    77 Programming languages: Tcl and C[[BR]]
    78 Potential mentor: blb
    79 }}}
    80 
    8159==== Configuration files handling ==== #configfiles
    8260
     
    8967Potential mentor: raimue
    9068
    91 ==== Scan for broken dynamic libraries for rebuild ==== #rev-upgrade
    92 
    93 Upgrading any port can naturally break its dependents if using dynamic libraries. The only way to fix this is currently rebuilding all dependents, no matter if necessary or not. MacPorts should get a new command to scan installed dynamic libraries and binaries for linker errors and mark the corresponding port for rebuild. After checking all files, broken ones should get rebuild in the correct order. Probably it has to do the check again after each set of rebuilds.
    94 
    95 {{{
    96 port rev-upgrade [portname]
    97 }}}
    98 
    99 If you are familiar with Gentoo, this would be the equivalent of the revdep-rebuild command. See #17473 for more information.
    100 
    101 Classification: easy to medium task[[BR]]
    102 Programming languages: Tcl[[BR]]
    103 Potential mentor: raimue
    104 
    105 ==== MacPorts Port for self-management ==== #self-management
    106 
    107 The MacPorts port should be the source for updating a user's MacPorts
    108 installation.
    109 
    110 Currently the MacPorts port is used to build the .dmg installer for MacPorts that is used for the initial installation of MacPorts, and port uses the "selfupdate" mechanism for maintaining the MacPorts installation. The selfupdate mechanism is (at least not documented as such) not accessible through the MacPorts API and does not use the MacPorts mechanisms for maintaining ports
    111 
    112 Classification: challenging task[[BR]]
    113 Programming languages: Tcl and C[[BR]]
    114 Potential mentor: blb
     69==== Graphical user interface ==== #GUI
     70
     71Come up with a front-end for installing packages (or building ports, where no package exists) for naive end-users. See also [http://ihack.us/2008/03/24/building-a-gui-for-macports/ drernie's post] about MacPorts GUIs. The  [http://trac.macports.org/wiki/armahg MacPorts.Framework] and [http://trac.macports.org/browser/users/rhwood/Pallet Pallet] projects contain some of the already done ground work for building such a GUI. Also see [wiki:MacPortsGUIFAQ GSoC 2009 MacPorts GUI "FAQ"] for some useful details on what this project would entail.
     72
     73Classification: major task[[BR]]
     74Programming languages: Tcl and any other language for the GUI part (e.g. ObjC)[[BR]]
     75Potential mentors: armahg
     76
     77==== MacPorts Web Application (MPWA) ==== #mpwa
     78
     79A very good start has been made on a Web Application for MacPorts to serve as a basis for easier user submission and maintenance of ports, not to mention monitoring of port build status, browsing of ports, etc. This work is known as MPWA and is written in Ruby on Rails. This task is to complete the work on MPWA so that it is usable for day to day usage by the MacPorts community. Work is needed on user credentials and authentication, port dependency  integration, port submission and tracking, etc. This is a very exciting project and can help MacPorts scale to support a larger community.
     80
     81Read more about the [source:contrib/mpwa/doc MPWA design and model] and look at the [source:contrib/mpwa/ existing code].
     82
     83Classification: moderate, with good follow through vision, and architecture required[[BR]]
     84Programming languages: Ruby, perhaps a bit of Tcl[[BR]]
     85Potential mentor: jberry
     86
     87==== Binaries ==== #binaries
     88
     89MacPorts project does not provide binaries yet (installation of software without compiling them). This project consists in working in concert (or cooperatively) with whomever does (virtual chroot) to setup a mechanism to automatically build packages, send reports on failures and implement a distribution mechanisms to allow users to fetch binary packages. This task could extend to support universal binaries, cross-testing (building on an intel box and testing on a powerpc box) and extending the livecheck mechanism to automatically send reports when ports are updated.
     90
     91See also [wiki:MPAB MacPorts AutoBuild].
     92
     93Classification: relatively challenging to challenging task[[BR]]
     94Programming language: Tcl[[BR]]
     95Potential mentors: TBD
     96
     97==== Dependencies ==== #dependencies
     98
     99This task consists of implementing a new dependencies engine for MacPorts. The current dependency engine properly deals with installing packages, but it does not deal satisfactorily with dependencies on variants (and versions), uninstalling and upgrading. This very challenging task requires a complete formalization of the use cases (installation, upgrade, uninstallation) and of the user needs before any implementation, as well as a deep understanding of the dependency relations (required for fetching, building, configuring; static and dynamic linking; dependence at runtime).
     100
     101Classification: very challenging task[[BR]]
     102Programming languages: Tcl and C[[BR]]
     103Potential mentors: TBD
    115104
    116105==== Check dependencies after destroot ==== #depcheck
     
    129118Potential mentor: raimue
    130119
    131 ==== Binaries ==== #binaries
    132 
    133 MacPorts project does not provide binaries yet (installation of software without compiling them). This project consists in working in concert (or cooperatively) with whomever does (virtual chroot) to setup a mechanism to automatically build packages, send reports on failures and implement a distribution mechanisms to allow users to fetch binary packages. This task could extend to support universal binaries, cross-testing (building on an intel box and testing on a powerpc box) and extending the livecheck mechanism to automatically send reports when ports are updated.
    134 
    135 See also [wiki:MPAB MacPorts AutoBuild].
    136 
    137 Classification: relatively challenging to challenging task[[BR]]
    138 Programming language: Tcl[[BR]]
    139 Potential mentors: TBD
    140 
    141 ==== Graphical user interface ==== #GUI
    142 
    143 Come up with a front-end for installing packages (or building ports, where no package exists) for naive end-users. See also [http://ihack.us/2008/03/24/building-a-gui-for-macports/ drernie's post] about MacPorts GUIs. The  [http://trac.macports.org/wiki/armahg MacPorts.Framework] and [http://trac.macports.org/browser/users/rhwood/Pallet Pallet] projects contain some of the already done ground work for building such a GUI. Also see [wiki:MacPortsGUIFAQ GSoC 2009 MacPorts GUI "FAQ"] for some useful details on what this project would entail.
    144 
    145 Classification: major task[[BR]]
    146 Programming languages: Tcl and any other language for the GUI part (e.g. ObjC)[[BR]]
    147 Potential mentors: armahg
     120==== MacPorts Port for self-management ==== #self-management
     121
     122The MacPorts port should be the source for updating a user's MacPorts
     123installation.
     124
     125Currently the MacPorts port is used to build the .dmg installer for MacPorts that is used for the initial installation of MacPorts, and port uses the "selfupdate" mechanism for maintaining the MacPorts installation. The selfupdate mechanism is (at least not documented as such) not accessible through the MacPorts API and does not use the MacPorts mechanisms for maintaining ports
     126
     127Classification: challenging task[[BR]]
     128Programming languages: Tcl and C[[BR]]
     129Potential mentor: blb
     130
     131==== Automatic testing ==== #testing
     132
     133MacPorts project currently includes a [source:trunk/base/tests test framework] to test features of the infrastructure. However, the tests do not cover all the code and they are not executed on an automatic basis. This task consists of extending the test framework and could be broadened to develop a code coverage technology for MacPorts to make the infrastructure more robust to future changes.
     134
     135Classification: relatively easy to very challenging[[BR]]
     136Programming languages: Tcl, C[[BR]]
     137Potential mentor: raimue
    148138
    149139==== Images (Pkgview, depot-to-depot dependencies) ==== #images
     
    172162Potential mentors: raimue
    173163
    174 ==== Automatic testing ==== #testing
    175 
    176 MacPorts project currently includes a [source:trunk/base/tests test framework] to test features of the infrastructure. However, the tests do not cover all the code and they are not executed on an automatic basis. This task consists of extending the test framework and could be broadened to develop a code coverage technology for MacPorts to make the infrastructure more robust to future changes.
    177 
    178 Classification: relatively easy to very challenging[[BR]]
    179 Programming languages: Tcl, C[[BR]]
    180 Potential mentor: raimue
    181 
    182 ==== MacPorts Web Application (MPWA) ==== #mpwa
    183 
    184 A very good start has been made on a Web Application for MacPorts to serve as a basis for easier user submission and maintenance of ports, not to mention monitoring of port build status, browsing of ports, etc. This work is known as MPWA and is written in Ruby on Rails. This task is to complete the work on MPWA so that it is usable for day to day usage by the MacPorts community. Work is needed on user credentials and authentication, port dependency  integration, port submission and tracking, etc. This is a very exciting project and can help MacPorts scale to support a larger community.
    185 
    186 Read more about the [source:contrib/mpwa/doc MPWA design and model] and look at the [source:contrib/mpwa/ existing code].
    187 
    188 Classification: moderate, with good follow through vision, and architecture required[[BR]]
    189 Programming languages: Ruby, perhaps a bit of Tcl[[BR]]
    190 Potential mentor: jberry
    191 
    192164=== Additional tasks ===
    193165
     
    201173==== Task A2: Documentation and Website ====
    202174 * Improve MacPorts documentation
    203  * Improve MacPorts website 
     175 * Improve MacPorts website
    204176 * Custom Trac plugins
    205177
     
    209181Programming languages: php, python[[BR]]
    210182Potential mentors: TBD
     183
     184
     185
     186
     187
     188{{{
     189#!comment
     190# Listing already done tasks here, maybe parts of this could spin-off a new project idea
     191
     192# Done 2009
     193==== Logging ==== #logging
     194
     195Currently MacPorts has no notion of logging of build activities of a given port or sets of ports. When a build is attempted but an error keeps it from completing, there's no way to track the problem other than the build progress that was output to the terminal, if verbose mode was requested in the first place. Otherwise, the build environment has to be pruned and the build attempted once again to even get a look at the precise error message. This is particularly problematic when automated builds are attempted, since there's usually no one around to have a look at the failure spew. An infrastructure to remedy this situation and endow MacPorts with a rich set of logging capabilities has to be developed to open up the door to true automated build runs of large sets of ports and thus to packaging of binaries, since with logging we'd have a fully reliable way of catching, reporting and processing of all sorts of fetch/configure/build/destroot/install/etc errors.
     196
     197This could be extended with the interaction with a server side application like MPWA that could consume these logs (read MPWA proposal). A more detailed draft of this task can be found on the LoggingProposal page.
     198
     199Classification: medium task to relatively challenging[[BR]]
     200Programming languages: Tcl and C[[BR]]
     201Potential mentor: blb
     202}}}