[MacPorts] SummerOfCode modified

[MacPorts]

Changed page "SummerOfCode" by raimue at macports.org from 131.188.30.102*
Page URL: <http://trac.macports.org/wiki/SummerOfCode>
Diff URL: <http://trac.macports.org/wiki/SummerOfCode?action=diff&version=123>
Revision 123
Comment: Reorder tasks a little bit

-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: SummerOfCode
=========================================================================
--- SummerOfCode (version: 122)
+++ SummerOfCode (version: 123)
@@ -56,28 +56,6 @@
 
 === Core Tasks ===
 
-==== Dependencies ==== #dependencies
-
-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).
-
-Classification: very challenging task[[BR]]
-Programming languages: Tcl and C[[BR]]
-Potential mentors: TBD
-
-{{{
-#!comment
-# Done 2009
-==== Logging ==== #logging
-
-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.
-
-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.
-
-Classification: medium task to relatively challenging[[BR]]
-Programming languages: Tcl and C[[BR]]
-Potential mentor: blb
-}}}
-
 ==== Configuration files handling ==== #configfiles
 
 MacPorts has no way to track configuration files. Currently if a configuration file is part of a port it will get overwritten on every upgrade which makes it less useful. At the moment, many ports only install default configuration files and the user has to copy it to the original location. But this always requires manual action and the user is not informed of updates in this configuration file.
@@ -88,30 +66,41 @@
 Programming languages: Tcl[[BR]]
 Potential mentor: raimue
 
-==== Scan for broken dynamic libraries for rebuild ==== #rev-upgrade
-
-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.
-
-{{{
-port rev-upgrade [portname]
-}}}
-
-If you are familiar with Gentoo, this would be the equivalent of the revdep-rebuild command. See #17473 for more information.
-
-Classification: easy to medium task[[BR]]
-Programming languages: Tcl[[BR]]
-Potential mentor: raimue
-
-==== MacPorts Port for self-management ==== #self-management
-
-The MacPorts port should be the source for updating a user's MacPorts
-installation.
-
-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
-
-Classification: challenging task[[BR]]
-Programming languages: Tcl and C[[BR]]
-Potential mentor: blb
+==== Graphical user interface ==== #GUI
+
+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.
+
+Classification: major task[[BR]]
+Programming languages: Tcl and any other language for the GUI part (e.g. ObjC)[[BR]]
+Potential mentors: armahg
+
+==== MacPorts Web Application (MPWA) ==== #mpwa
+
+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.
+
+Read more about the [source:contrib/mpwa/doc MPWA design and model] and look at the [source:contrib/mpwa/ existing code].
+
+Classification: moderate, with good follow through vision, and architecture required[[BR]]
+Programming languages: Ruby, perhaps a bit of Tcl[[BR]]
+Potential mentor: jberry
+
+==== Binaries ==== #binaries
+
+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.
+
+See also [wiki:MPAB MacPorts AutoBuild].
+
+Classification: relatively challenging to challenging task[[BR]]
+Programming language: Tcl[[BR]]
+Potential mentors: TBD
+
+==== Dependencies ==== #dependencies
+
+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).
+
+Classification: very challenging task[[BR]]
+Programming languages: Tcl and C[[BR]]
+Potential mentors: TBD
 
 ==== Check dependencies after destroot ==== #depcheck
 
@@ -128,23 +117,24 @@
 Programming languages: Tcl and C[[BR]]
 Potential mentor: raimue
 
-==== Binaries ==== #binaries
-
-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.
-
-See also [wiki:MPAB MacPorts AutoBuild].
-
-Classification: relatively challenging to challenging task[[BR]]
-Programming language: Tcl[[BR]]
-Potential mentors: TBD
-
-==== Graphical user interface ==== #GUI
-
-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.
-
-Classification: major task[[BR]]
-Programming languages: Tcl and any other language for the GUI part (e.g. ObjC)[[BR]]
-Potential mentors: armahg
+==== MacPorts Port for self-management ==== #self-management
+
+The MacPorts port should be the source for updating a user's MacPorts
+installation.
+
+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
+
+Classification: challenging task[[BR]]
+Programming languages: Tcl and C[[BR]]
+Potential mentor: blb
+
+==== Automatic testing ==== #testing
+
+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.
+
+Classification: relatively easy to very challenging[[BR]]
+Programming languages: Tcl, C[[BR]]
+Potential mentor: raimue
 
 ==== Images (Pkgview, depot-to-depot dependencies) ==== #images
 
@@ -171,24 +161,6 @@
 Classification: easy task [[BR]]
 Potential mentors: raimue
 
-==== Automatic testing ==== #testing
-
-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.
-
-Classification: relatively easy to very challenging[[BR]]
-Programming languages: Tcl, C[[BR]]
-Potential mentor: raimue
-
-==== MacPorts Web Application (MPWA) ==== #mpwa
-
-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.
-
-Read more about the [source:contrib/mpwa/doc MPWA design and model] and look at the [source:contrib/mpwa/ existing code].
-
-Classification: moderate, with good follow through vision, and architecture required[[BR]]
-Programming languages: Ruby, perhaps a bit of Tcl[[BR]]
-Potential mentor: jberry
-
 === Additional tasks ===
 
 ==== Task A1: Ports ====
@@ -200,7 +172,7 @@
 
 ==== Task A2: Documentation and Website ====
  * Improve MacPorts documentation
- * Improve MacPorts website 
+ * Improve MacPorts website
  * Custom Trac plugins
 
 '''Note''': Pure documentation proposals are not allowed by Google.
@@ -208,3 +180,23 @@
 Classification: minor task[[BR]]
 Programming languages: php, python[[BR]]
 Potential mentors: TBD
+
+
+
+
+
+{{{
+#!comment
+# Listing already done tasks here, maybe parts of this could spin-off a new project idea
+
+# Done 2009
+==== Logging ==== #logging
+
+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.
+
+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.
+
+Classification: medium task to relatively challenging[[BR]]
+Programming languages: Tcl and C[[BR]]
+Potential mentor: blb
+}}}

-------8<------8<------8<------8<------8<------8<------8<------8<--------

* The IP shown here might not mean anything if the user or the server is
behind a proxy.

--
MacPorts <http://www.macports.org/>
Ports system for Mac OS

This is an automated message. Someone at http://www.macports.org/ added your email
address to be notified of changes on SummerOfCode. If it was not you, please
report to .