FusionForge

Suggestions

From FusionForge Wiki
Jump to: navigation, search

Please use the Feature requests tracker for new suggestions. If a long explanation is required, you should feel free to create a Suggestions/FooBar page on this wiki (and link it from the tracker), but we're using the tracker to keep an eye on things.

Suggestions

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.


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.

I noticed one of our subscribers is linked with [1] see also [2], maybe useful for Mylyn (Note de Christian Bayle)

=> Interested in Mylyn integration, checkout the dedicated project Mylyn connector

Lolando: The OSLC-CM plugin (currently under development) should fulfill that need, I think.

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. The consensus favours Smarty.

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

  • Trackers
  • 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.

Common MediaWiki Site

The mediawiki-per-project model is useful, but on our intranet I would like the option of a shared mediawiki for all projects. Instead of associating the main MW page with the project, I'd associate a project MW page with the project. In our closed environment, reusability is much more important than strong project partitions (as long as our source control is partitioned).

Thanks for reading. --Salquint 04:35, 19 October 2011 (UTC)

Enhancements

Processors list update

it could be useful to update processor classes list by default:

  • AMD64
  • 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...

Other actions:

  • 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

Ergonomy rules

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