| 1 | = MacPorts User Experience Improvements |
| 2 | |
| 3 | == Aliases |
| 4 | Should we support specifying aliases? The consensus seems to be that there is not really a need for it at the moment, especially since we allow abbreviating commands. |
| 5 | |
| 6 | == Learning from Gentoo: Displaying an Execution Plan |
| 7 | * Gentoo shows a [http://www.krizalys.com/sites/default/files/colors-everywhere.png nice summary] of what it will do when upgrading packages. It uses colors, font weight and a column with status letters to tell users: |
| 8 | * Which ports that are being changed are requested (bold) |
| 9 | * The old and new versions |
| 10 | * Whether the port will be upgraded, freshly installed as a dependency and whether it will be compiled from source |
| 11 | * The variants (use-flags) |
| 12 | * The download size |
| 13 | * A summary of the operations to be performed |
| 14 | * A lot of this information is not very easy to display in MacPorts because we do not compute a complete execution plan for upgrades before executing it, but rather recursively iterating through dependencies (which may in turn pull in other dependencies, etc). |
| 15 | * For example, our package index does not know whether a binary package is available |
| 16 | * libsolv would help with some of these issues, but requires accurate dependency information in the portindex. |
| 17 | * Initial plan was to extend portindex and use symbolic execution of the variant sections when parsing a portfile for the portindex so that the changes done by a variant could be added to the index. |
| 18 | |
| 19 | == Learning from Gentoo: Passing Messages to Users |
| 20 | * Gentoo has a mechanism to display messages to users |
| 21 | * It's not hard to implement, could be a potential GSoC task |
| 22 | * We could have a format that allows selecting which users see a certain message, e.g. `showif: os() >= 10.6`, `showif: port-installed(foobar)` |
| 23 | |
| 24 | == Learning from Gentoo: Colors |
| 25 | * Colors could make output nicer to read |
| 26 | * The split between `macports1.0` and the `port(1)` command line client makes it somewhat difficult to use ANSI color escape sequences, since theoretically, `macports1.0` could be used by a non-commandline-client. |
| 27 | * A simple first step would be to make warnings yellow and errors red |
| 28 | * As far as visibility on light and dark backgrounds is concerned, we should be fine if we only use the 8 standard colors |
| 29 | * Aljaž will implement this as a first step: #56022 |
| 30 | |
| 31 | == Making Build Failures More Bearable |
| 32 | * We could have a simpler method to inform the project about failed builds of ports |
| 33 | * E.g. a one-click button on a port's website (on a hypothetical new website) |
| 34 | * Just a "this port is broken for me" is not really useful without logs |
| 35 | * We could do opt-in submission of build failures, e.g. if the user is in interactive mode |
| 36 | * We could run some quick analysis to speed up analysis, such as "OS version: x.y.z", "non-default prefix", "known problem: no destroot found", etc. |
| 37 | * This could be done as a GSoC project |
| 38 | * Other one-click buttons on a port website: |
| 39 | * This port is outdated: Lets us focus on updating ports that users care about to maximize the value we generate with the time invested (perceived currency vs. actual currency) |
| 40 | * This port is important to me |
| 41 | |
| 42 | == Statistics |
| 43 | * Nobody is keen on the Ruby server part. The client is fine, but we should replace the server part with a new website. |
| 44 | * The problem is that we have always been waiting for the website |
| 45 | * Usual approach in other projects is to set up third-party website that just works |
| 46 | * With the message feature outlined above, we could improve participation in statistics; e.g. push a message that will be displayed as long as a certain file does not exist. Ask user to run a command that will record decision whether to contribute in this file. |