Please use this page as an index for your developing ideas.

1. Please keep discussion within bounds of Terms of Reference
2. Please cite any sources by using double brackets/parentheses in the wiki. This automatically creates footnotes.¹⁾
3. Please use “>” to reply to comments.

I am for something
> I disagree
>> Okay, I see your point

I am for something

I disagree

Okay, I see your point

Overview Use Linus Torvald's distributed version control system with GitHub, a codehosting site th.

Website

Licence

Major Pluses

1. 1st plus
2. 2nd plus

Major Negatives

1. 1st negative
2. 2nd negative

Other Pluses

1. Input here

Other Negatives

1. data here

Quirks (neither positive nor negative, but relevant for decision)

1. ?

suggested by dominic

Kohana PHP5 RAD WebFramework (BSD-like license)

Homepage: kohanaphp.com/home

Features

• Highly secure
• Extremely lightweight
• Short learning curve
• Uses the MVC pattern
• 100% UTF-8 compatible
• Loosely coupled architecture
• Extremely easy to extend

Technology

• Strict PHP 5 OOP
• Simple database abstraction using SQL helpers
• Multiple session drivers (native, database, and cookie)
• Powerful event handler allows small modifications dynamically
• Originally based on CodeIgniter

Comment: Kohana is somewhat web2py for PHP5

Overview Use Linus Torvald's distributed version control system with GitHub, a codehosting site that is free for individuals.

Website

Licence

Major Pluses

1. Very Fast

Major Negatives

Harder to learn. No Windows client

Other Pluses

1. Input here

Other Negatives

1. data here

Quirks (neither positive nor negative, but relevant for decision)

1. ?

Webpages: http://bazaar-vcs.org/ and https://launchpad.net//

Licence: Bazaar - GPL, Launchpad currently closed source. To be released under the AGPL 21 July 2009.²⁾

Major Pluses

1. Natively supports mentoring - in fact it encourages it
2. Very easy syntax
3. Very easy to create branches and merge them into the trunk
4. Supports “Answers”, e.g. questions from end-users can. This is far simpler than a mailinglist because all replies can be tracked, etc.

Major Negatives

1. New kid on the block

Other Negatives

1. Doesn't support skins
2. GOTCHA - Mailinglists are supported through teams,³⁾ which are semi-seperate from the developers themselves. Not a major point, but counter intuitive. Note, end-user support is provided by “Answer” tickets, not a mailinglist.

Other pluses

1. Supports full Unicode.⁴⁾ This assists because we have several contributors whose names are best spelt in non-Latin characters
2. Has an integrated translation feature - should reduce Dominic's workload
3. Pretty interface
4. Bug tickets support tags as well as priorities

Quirks (neither positive nor negative, but relevant for decision)

1. Integrated with Ubuntu. This helps Ubuntu users, but may irk others.

tbc

• Documentation/Wiki - a single wiki that covers all Sahana projects built upon the widely deployed MediaWiki
• Release Repository - a file-based approach containing compressed archives of all Sahana releases
• Project Repositories - up to each project to select Source Code Management solution that best meets the need of the individual projects based on number of developers and nature of the project
• Project Management - each project to decide on most suitable project management system e.g. Launchpad
• Release/Version Numbering - all projects will adopt the same versioning system, but will maintain control on deciding on increments
• Coding Standards - standardised across projects as much as possible, with leeway given for language specific demands e.g. Python and indenting
• Mail Lists - all mail lists will be hosted on Google Groups, primarily for developers
• Forums - a Sahana-wide set of forums will be made available for domain and end-user discussion and will use phpbb3
• Branding - all projects that use the Sahana name must be approved by the community, and will be given a consistent name, project URL, imagery, and how to link back to the master Sahana website e.g. Sahana navigation blocks

The project should select MediaWiki as the wiki engine. It has arguably the largest number of worldwide users as it is the same engine used for Wikipedia. MediaWiki is commonly used as project wikis for a number of significant open source projects (references to come).

Namespaces in the current dokuwiki should be deprecated in favour of MediaWiki Categories - whereby a page can be assigned to multiple cagetories within the wiki. Sometimes a given page has relevance to multiple namespaces in the current Dokuwiki and this can be confusing.

As the Sahana wiki is unlikely to be uploaded to a Sahana instance, the file based approach used for storing the current dokuwiki is not necessary, and the project should move to a database driven wiki. Any future wiki that is to be part of a Sahana deployment will need to be kept entirely separate from the Sahana wiki, as the choice of wiki software for Sahana deployment has a quite different set of requirements from consolidating information across all Sahana projects.

To ensure that all design information is captured in one wiki - the use of Blueprints in Launchpad should link back to design discussion in the master wiki, and Launchpad Blueprints should only deal with specific implementation issues for the project using Launchpad.

The single master repository to contain copies of all releases from Sahana projects should be a simple folder and compressed archive repository. Source Code Management software should not be used for the release repository. A wiki page can be created to provide a web accessible list of all project releases linking directly to the compressed source code.

Each Sahana sub-project can select the SCM solution that is most appropriate to their project. The number of developers associated with each project, and the nature of the project itself will determine whether a centralised or distributed approach is best. Every release however will be submitted to the Sahana Release Repository as a compressed archive. This may well be tightly integrated into Project Management

Each project will be able to select the most suitable project management solution for their project, such as Launchpad. Note that some features, such as Blueprints in Launchpad will need to defer some information back to the master Sahana wiki. Local project wikis may only be used to record project-specific implementation details. As much information as possible much instead be stored in the master Sahana wiki.

All projects will use the same release numbering system to ensure consistency and to avoid confusion. Projects will have complete control as to when to increment releases, but the overall system must be the same for all projects.

Code standards, such as indenting will often have to be deferred to each project to define, as some languages demand certain coding practices such as Python. As much as possible, coding standard should be consistent across projects, but flexibility will be given for language-specific issues.

All projects will use Google Groups to host email developer lists. A consistent list naming process will be developed to ensure similar names are used for similar lists across the sub-projects.

Phpbb3 will be used to provide a single set of forums that can be used by all Sahana projects. These should be promoted as the primary means of engaging in domain and end-user discussion. These will also be used for special interest groups (SIGs) that may be created from time to time.

Each project that uses the Sahana brand needs to be approved by the community. Upon approval the new project will be provided a Sahana URL for that project, as well as imagery that fits with the overall appearance of the Sahana project. Minimum requirements in terms of linking back to the master Sahana website will also be required (e.g. Sahana-wide and consistent navigation block). Any email lists required will also be created to fit with existing list names.