- 1 Suggestions
- 1.1 Install without DNS & vhosts (David Partain)
- 1.2 Web pages hosting (David Partain)
- 1.3 Plugin manager improvements (Alain Peyrat)
- 1.4 Plugin to display a banner on the whole site (Alain Peyrat)
- 1.5 Roadmap/Timeline tool (Alain Peyrat)
- 1.6 Logging Framework (Muris Ahmovic)
- 1.7 IDE integration (Olivier Meunier)
- 1.8 Separate contents from presentation
- 1.9 More RSS feeds
- 1.10 Default skin appliance
- 2 Enhancements
Install without DNS & vhosts (David Partain)
I work in an environment where I cannot change DNS in any way. As such, virtual hosts with project.company.com are not an option. I'd like there to be a way to decide during installation whether you'll use subdomains or not. If not, the installation will then configure things appropriately. That means, as an example, that sys_default_domain, sys_scm_host, sys_ldap_host, etc in local.inc will all be the same, that "Project Home Page" will have to be something other than project.company.com (e.g., company.com/projects/project).
- → This is the "URL relocation" mentioned in the roadmap; the goal is to be able to run your forge as www.company.com/tools/forge/ and have non-web tools working too.
Web pages hosting (David Partain)
I'd really like to see a plain ol' Web area that is under the same access control as the rest of the project information, requires login if the site does, etc. Of course, a good wiki plugin will help here.
- → A solution that I use is to provide webdav directory, so projects have their own web space and can work on documents.
Plugin manager improvements (Alain Peyrat)
- The 'Run Init Script' is confusing users. If the init is needed, then why this option ?
- Add a description to explain the plugin, a version number for upgrading.
- Add a dependency (example: to enable only svn2tracker if scmsvn is active).
- Add a 'enabled by default' option.
To display a maintenance banner when an operation will be performed.
Roadmap/Timeline tool (Alain Peyrat)
To have a simple view of pending bugs, tasks, features. An example is: http://trac.edgewall.org/roadmap
Logging Framework (Muris Ahmovic)
The needs to use or develop a logging framework for fusionforge would help during development and users could easier report bugs
It should be well described and used by the plugins.
Another good convention (from my expirience) would be to have Entry/Leaving DEBUG log entries for EVERY function.
Example: "Entering - doSomeMagic($staff)"
The following features are needed:
- Log Levels (ERROR, WARN, INFO, DEBUG, etc.)
- Writing to stream/file (append)
- Log Rotation
- Setting the log level global (For example: During DEV the log level should remain debug/trace and for the production use erorr)
The only usable framework is Zend Framework -> Zend_Log: http://framework.zend.com/manual/en/zend.log.html
There is unfortunately no release yet for log4php http://incubator.apache.org/log4php/qsg.html
- → To get fine logging (like entry/leaving), xdebug can be used quite easily.
IDE integration (Olivier Meunier)
- Provide a connector to use fusionforge from Eclipse via Mylyn, using the SOAP interface. The Web Templates Connector is not easily (?) usable.
- Provide a Visual Studio plugin to access tasks in fusionforge projects from the task view in Visual Studio.
=> Interested in Mylyn integration, checkout the dedicated project Mylyn connector
Separate contents from presentation
It would make life much easier for graphic designers looking to customise the appearance of their forge if the display stuff were not so tightly bound with the code. Ideally, that would mean switching to a template system (Smarty or Flexy maybe?).
Separate translations files could be necessary too: one for the fusionForge functionalities, one for the rest of the purpose. the use of widgets (like projects list...) could be useful too (related translation could help to separate functionnalities and purpose translations)
More RSS feeds
- Project managers
- Also an aggregated feed for everything related to one project
Default skin appliance
Currently only the first skin (in the list) can be used as default skin. It could be useful to declare that a skin is the one per default to be sure that as a user is not connected, he will have the good "corporate" skin and it will ease the administrators to choose the skin per default to propose to their users.
Processors list update
it could be useful to update processor classes list by default:
- ARM Families
Topic list update
it could be useful to update topic items list by default:
- Control Version::GIT
- Operating System::Windows::Vista, Seven, 2008...
New categories could be added like:
- Terminal Classes::Laptop, Desktop, Embedded::Mobile, Smartphone, Pdas...
- Mobile standards::GSM, GPRS, UMTS with sub standards...
- Maybe the categories could be organized in a different order or subdivisions.
- Deactivating some of same could be more comfortable to manage than deleting some and their subtopics.
- giving consistence between licenses(same for processors) in the topic tree and in separate list could be
- Organizing their translations with the inner DB (not with po files) could be interesting too
It could be useful to edit some ergonomy rules to better define the work canvas. Suggestions:
- the name of the identified user is currently joined to the disconnect button/link. It could be better, my opinion, to join it to the "my account" button/link or to replace it.
Replace chroot creation by test script (Sylvain Le Gall)
Handling chroot creation in fusionforge is quite complicated and require a deep understanding of package manager, chroot building et al. A simple solution is to provide a list of requirement for a potential chroot and build distribution specific script. For example:
- The plugin git needs /usr/bin/git and /usr/bin/git-toto
- It stats that it requires "bin git" and "bin git-toto" in a file (lets call it /etc/fusionforge/plugin/scmgit/requirements)
- 1st solution: You can use "whohas git" and "whohas git-toto" to determine wich package is required and build a chroot with it
- 2nd solution: You can generate a script that transform /etc/fusionforge/plugin/*/requirements into a schell script that test any computer/chroot/vserver to comply. E.g. "bin .* => (command -v \1) || echo "\1 is required" >&2). This shell script will then be copied by sysadmin to target chroot/vserver/xen domu to check that installation comply with fusionforge installation (and mail it through cron job output if something goes wrong)
Back to FusionForge