SME Server:Documentation:Technical Manual:Chapter1

From SME Server
Revision as of 07:50, 17 February 2007 by Snoble (talk | contribs) (New page: ==Chapter 1. How you can help== ===Documentation=== Documentation for SME Server was inherited from the prior distribution maintainers, e-smith and mitel. Their work gave SME a great base...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Chapter 1. How you can help


Documentation for SME Server was inherited from the prior distribution maintainers, e-smith and mitel. Their work gave SME a great base to work from.

The current developers have continued to improve the SME Server software and to reflect these improvements the Documentation has to develop too. These wiki-based manuals have been put in place to allow anyone to update or add new sections where they see fit.

Bug and New Feature Verification

Please help us to make our software as reliable as possible. Your role in that is to report possible bugs only via the bug tracker, and to encourage others to do the same. Thanks.

[Reporting a New Bug] If you have searched the Manual and Bug Tracker and not found an answer or someone else's report that matches yours, you should register on the Bug Tracker and enter a new bug. The debugging process of any issue requires active participation on the part of the reporter, providing further information and clarification of the problem.

  • So how do I know it is a bug?

You don't need to. If there's any chance that it is a bug, please report to the bug tracker. It doesn't matter whether anyone else has seen it. It doesn't matter whether anyone else has a theory as to what is happening. You have noticed something that doesn't seem to work right, so just report it. Please.

To enter a bug choose a category, component, fill in the details of the bug, and commit. Please use a descriptive Summary, as most of the header searches just show the Summary 'panel errors' is not helpful, what panel, what errors ? 'Add option to limit mailman web access ' explains the topic very well

Anyone reporting problems, ask yourself these important questions, so that you know what to tell the developers in the bug report:

  1. What version am I using and are there any contribs installed or other customisations?
  2. What did I do?
  3. What did I expect to happen?
  4. What happened?
  5. What do the logs say?

[Lifecycle of a Bug] If you find a bug you can work on, eg updating information on the wiki, do so. There are likely to be a lot of these as they were generated before the wiki was in place.

In this example of adding documentation, after you have updated the wiki, return to the bug post brief details of the fix, and how to verify it, eg 'updated wiki re: passwords' and give the URL then change the Status to 'Resolved - Fixed'.

Someone else can then review your changes and change the Status from 'Resolved - Fixed' to Verified and the bug is finished. Bug Tracker Administrators Close bugs in SME Current or SME Future, but the reporter or maintainer can close in other sections.


FIXME See the Developers manual

Maintaining existing Languages

Changes to Existing Language sets are posted to the Translations section of the Bug Tracker. Making a patch to keep your language updated isn't difficult, follow these steps

Obtain an original file that you are going to modify, it will usually be a translation of a panel, eg. /etc/e-smith/locale/en-us/etc/e-smith/web/functions/hostentries or /etc/e-smith/locale/fr/etc/e-smith/web/functions/hostentries if a patch from the Bug Tracker is available it will guide you on what has changed [[1]]

make a directory and copy your file there as name.old make a copy and edit it to suit

from the command line create a patch diff -u name.old > name.patch

add this to the existing bug or create a new one in Translations

Donations & Funding Work

Help pay it's bills

Pay a developer to add a feature you would like Email a developer directly with your request or open a bug with your proposal