Here are the projects currently under way (or being actively contemplated on the freebsd-doc mailing list).
If you think you can contribute to any of these, please do not hesitate to stand up and be counted. You should talk to the person responsible for that particular project, who can then bring you up to speed on what is happening. If you have any ideas for a new project then please email FreeBSD-doc@FreeBSD.org.
The Documentation TODO list is an up-to-date list of documentation issues that should be resolved. If you wish to help us to improve the FreeBSD documentation set you should, at first, choose to work on one of the TODO list items.
Current FreeBSD problems reports are tracked using a Problem Reports database. You can view the open documentation problem reports.
Responsible: FreeBSD-doc <FreeBSD-doc@FreeBSD.org>
Synopsis: Many new sections have been added to the FreeBSD Handbook without index terms, others have been added under inappropriate primary or secondary indexterms that do not fit the existing scheme. Some indexterms have been added inside list items or other areas where they are not allowed by our stylesheets, causing ??? to be printed in the index instead of a real page number.
Index work requires experience and anyone who works on this task is highly encouraged to carefully read through the existing (print-output) index, and to have read the Chicago Manual of Style or other style books that deal with indexing. Please see - the CVS history of some of the chapter.xml files to see some of + the SVN history of some of the chapter.xml files to see some of the indexing errors that have been corrected in the past. It is imperative to view the PostScript version of the Handbook after making any changes to indexterms as many errors, such as long words or deeply nested indexterms will break the two column output there, or cause the page number to be listed as ???.
There is a script doc/share/misc/indexreport.pl which can be used to find areas of an SGML file where <indexterms> are sparse.
Responsible: FreeBSD-doc <doc@FreeBSD.org>
Synopsis: Presentations marked up in the DocBook-slides DTD have recently been added to the documentation set in doc/en_US.ISO8859-1/slides. More advocacy content is needed, and additional stylesheet work is needed to pull in content from the release notes and other XML content in our documentation set to build up-to-date slides with 'make'. A simple example presentation was committed with some of this functionality, but there is more work to be done! Also, the stylesheets for print/PDF output (using the Java based XSLT processors, PassiveTeX is too limiting for slides) could be improved as the default DocBook Slides XSL-FO stylesheets produce very spartan slides.
Responsible: FreeBSD-doc <doc@FreeBSD.org>
Synopsis: Chunks of the FAQ and Handbook have empty sections in them. They need filling. If you have just had to use one of these documents to complete a task, and found them lacking, please find the time to write up your experiences as a possible replacement.
Alternatively, if you have just had to do something that had no entry in the FAQ and/or Handbook, please consider writing a new section. Then submit it as outlined above.
Responsible: <doc@FreeBSD.org>, <scsi@FreeBSD.org>
Synopsis: See The Design and Implementation of the FreeBSD SCSI Subsystem for a first snapshot.
Responsible: <doc@FreeBSD.org>, Wolfram Schneider <wosch@FreeBSD.org>
Synopsis:Modify the CGI script ports.cgi and the script portindex to use the Perl FreeBSD::Ports modules. These modules also need thorough testing.
Responsible: <doc@FreeBSD.org>
Synopsis:
Our main Web pages are written in (American) English. The FreeBSD Translations Projects translate the web pages, Handbook and FAQ to other languages.
We must translate the cgi scripts and web build scripts too. The scripts should support multiple languages, not only one. Most scripts are written in perl.
Responsible: <doc@FreeBSD.org>
Translate the FreeBSD documentation (Web pages, FAQ, Handbook, Manual pages) into other languages. See the FreeBSD translations projects
Index: head/en_US.ISO8859-1/htdocs/docproj/doc-set.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/docproj/doc-set.xml (revision 47799) +++ head/en_US.ISO8859-1/htdocs/docproj/doc-set.xml (revision 47800) @@ -1,48 +1,46 @@ ]>FreeBSD's documentation falls into three basic categories:
The Project does not really concern itself with these, since - they are a part of the base system. The exception to this is the - Japanese team, who are translating them. There is no reason other - volunteers could not step in to translate the manual pages to other - languages as well.
+The manual pages are part of the base system, but are also + an important component of the documentation. Both the + Documentation project and source committers update and + maintain manual pages.
-That is not to say that the manual pages are unimportant, far from - it. It is just that they are intimately tied to specific systems of - FreeBSD, and most of the time the best person to write the manual - page is the person that wrote that part of FreeBSD.
At present, the Japanese team has translated many of the + manual pages. Other volunteers could pitch in to translate + the manual pages to other languages as well.
The project has a large amount of documentation that is "book length", or becoming that way. These include the FreeBSD FAQ and the FreeBSD Handbook.
FreeBSD has a wealth of information available in shorter, article form -- similar to the tutorials or HOWTO documentation of other projects.
The project is a fairly loosely knit group of people, and the only thing - we have got in common is that we are subscribed to the mailing list + we have in common is that we are subscribed to the mailing list FreeBSD-doc@FreeBSD.org.
Some of us can commit changes directly to the FreeBSD - documentation tree. You can view a complete list of all FreeBSD developers with commit privileges, as well as a list of the principal committers for the FreeBSD Documentation Project.
-Others do not have commit privileges, but they write and submit +
Others do not have commit privileges, but write and submit documentation nonetheless. Once the documentation has been submitted according to the Submit Documentation page, one of the committers will then review it and include it in the documentation set.
-If you want to help out with the documentation project (and I fervently - hope you do) all you have to do is subscribe to the mailing list and +
To help with the documentation project (and we fervently + hope you do), just subscribe to the mailing list and participate. As soon as you have done that, you're a member of the project.
FreeBSD Documentation Project Home
Index: head/en_US.ISO8859-1/htdocs/internal/developer.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/internal/developer.xml (revision 47799) +++ head/en_US.ISO8859-1/htdocs/internal/developer.xml (revision 47800) @@ -1,78 +1,79 @@ ]>This document is an overall guide for all new committers, including both technical details and policy details. For the former, see the chapters on VCS Operations, the Bugzilla bug tracking system, and the SSH Quick-Start Guide.
It contains almost everything a new committer to the FreeBSD Project needs to know. See the Documentation Project Primer and the Ports Guide, below, for more info.
This primer covers everything you will need to know in order to start contributing to the FreeBSD Documentation Project, from the tools and software you will be using (both mandatory and recommended) to the philosophy behind the Documentation Project.
A guide for FreeBSD ports committers. This includes the canonical Table of __FreeBSD_version Values.
This document describes how to build and update -the FreeBSD Web pages from the CVS repository by hand.
+the FreeBSD Web pages from the SVN repository by hand.This page contains pointers to pages documenting aspects of the FreeBSD project itself, as viewed separately from the codebase.
There are various - -projects which lie outside the mainstream development path, -in which a number of groups are working on the 'cutting edge' +projects which lie +outside the mainstream development path. +A number of groups are working on the 'cutting edge' to expand FreeBSD's range of capabilities in new directions.
Here is an overview of the FreeBSD Release Engineering Process.
And here you will find the schedules for upcoming official releases of FreeBSD.
To avoid chaos with a project this large spread out all over the globe, there have to be some Policies for FreeBSD Committers.
The &os; Project Staff consists of teams, groups and individuals with designated project roles and areas of responsibility and the developers. By following the links, one will find a list of them, as well as explanations of who is responsible for what.
You can read here core's Hat Term Limits Policy and some guidelines from &a.imp; on how to work with hats.
Here is a list of some technical resources for FreeBSD committers.
For those with accounts on the main FreeBSD.org network, here are the machine resources that are available and the sorts of work they are intended for.
You can learn more about the FreeBSD WWW server, including the machine, the software, mirroring the FreeBSD web pages.
Index: head/en_US.ISO8859-1/htdocs/news/pressreleases.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/news/pressreleases.xml (revision 47799) +++ head/en_US.ISO8859-1/htdocs/news/pressreleases.xml (revision 47800) @@ -1,91 +1,92 @@ + ]>Most press releases are now handled by the FreeBSD Foundation.
+These are historical FreeBSD press releases. For press releases since 2005, please see +FreeBSD Foundation's archive.
&os; status reports are published quarterly and provide the general public with a view of what is going on in the Project, and they are often augmented by special reports from Developer Summits. As they are one of our most visible forms of communication, they are very important. This page will provide some advice on writing status report entries from David Chisnall, experienced in technical writing.
Do not worry if you are not a native English speaker. The team handling status reports, monthly@FreeBSD.org, will check your entries for spelling and grammar, and fix it for you.
Do not assume that the person reading the report knows about your project.
The status reports have a wide distribution. They are often one of the top news items on the &os; web site and are one of the first things that people will read if they want to know a bit about what &os; is. Consider this example:
abc(4) support was added, including frobnicator compatibility.
Someone reading this, if they are familiar with UNIX man pages, will know that abc(4) is some kind of device. But why should the reader care? What kind of device is it? Compare with this version:
A new driver, abc(4), was added to the tree, bringing support for Yoyodyne's range Frobnicator of network interfaces.
Now the reader knows that abc is a network interface driver. Even if they do not use any Yoyodyne products, you have communicated that &os;'s support for network devices is improving.
Status reports are not just about telling everyone that things were done, they also need to explain why they were done.
Carry on with the previous example. Why is it interesting that we now support Yoyodyne Frobnicator cards? Are they widespread? Are they used in a specific popular device? Are they used in a particular niche where &os; has (or would like to have) a presence? Are they the fastest network cards on the planet? Status reports often say things like this:
We imported Cyberdyne Systems T800 into the tree.
And then they stop. Maybe the reader is an avid Cyberdyne fan and knows what exciting new features the T800 brings. This is unlikely. It is far more likely that they have vaguely heard of whatever you have imported (especially into the ports tree: remember that there - are 20,000 other things there too...). List some of the new + are over 20,000 other things there too...). List some of the new features, or bug fixes. Tell them why it is a good thing that we have the new version.
Do not recycle the same status report items.
Bear in mind that status reports are not just reports on the status
of the project, they are reports on the change of status of the
project. If there is an ongoing project, spend a couple of
sentences introducing it, but then spend the rest of the report
talking about the new work. What progress have been made since the
last report? What is left to do? When is it likely to be finished
(or, if finished
does not really apply, when is it likely to
be ready for wider use, for testing, for deployment in production,
and so on)?
Do not forget about your sponsors.
If you or your project has received sponsorship, a scholarship from somebody or you have been already working as a contractor or an employee for a company, please include it. Sponsors always certainly appreciate if you thank them for their funding, but it is also beneficial for them to show that they are actively supporting the Project this way. Last, but not least, this helps &os; to learn more about its important consumers.
If help is needed, make this explicit!
Is there any help needed with something? Are there tasks other people can do? There are two ways in which you can use the open items part of the status report: to solicit help, or to give a quick overview of the amount of work left. If there is already enough people working on the project, or it is in a state where adding more people would not speed it up, then the latter is better. Give some big work items that are in progress, and maybe indicate who is focussing on each one.
List tasks, with enough detail that people know if they are likely to be able to do them, and invite people to get in contact.
Index: head/en_US.ISO8859-1/htdocs/platforms/index.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/platforms/index.xml (revision 47799) +++ head/en_US.ISO8859-1/htdocs/platforms/index.xml (revision 47800) @@ -1,83 +1,103 @@ - + ]>Here is a list of platforms that FreeBSD currently - supports along with platforms currently being ported to.
-If you have comments about a port, or wish to provide feedback to the developers, send it to the relevant mailing list.
+Here is a list of platforms that FreeBSD currently supports.
+| Project Page | Mailing List | Support Tier |
| FreeBSD/amd64 Project | freebsd-amd64@FreeBSD.org | Tier 1 |
| FreeBSD/ARM Project | freebsd-arm@FreeBSD.org | Tier 2 |
| FreeBSD/i386 Project | freebsd-current@FreeBSD.org | Tier 1 |
| FreeBSD/ia64 Project | -freebsd-ia64@FreeBSD.org | -Tier 2 through FreeBSD 10. Unsupported after. | -
| FreeBSD/MIPS Project | freebsd-mips@FreeBSD.org | Tier 3 |
| FreeBSD/pc98 Project | re-pc98@FreeBSD.org | Tier 2 |
| FreeBSD/ppc Project | freebsd-ppc@FreeBSD.org | Tier 2 |
| FreeBSD/sparc64 Project | freebsd-sparc@FreeBSD.org | Tier 2 |
| FreeBSD/xbox Project | freebsd-current@FreeBSD.org | N/A |
| Project Page | +Mailing List | +Support Tier | +
| FreeBSD/alpha Project | +freebsd-alpha@FreeBSD.org | +Tier 4 (support discontinued as of 7.0R) | +
| FreeBSD/ia64 Project | +freebsd-ia64@FreeBSD.org | +Tier 2 through FreeBSD 10. Unsupported after. | +
For general architecture questions, mail freebsd-arch@FreeBSD.org
Index: head/en_US.ISO8859-1/htdocs/ports/index.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/ports/index.xml (revision 47799) +++ head/en_US.ISO8859-1/htdocs/ports/index.xml (revision 47800) @@ -1,73 +1,73 @@ %ports.ent; %statistics.ent; ]>The FreeBSD Ports and Packages Collection offers a simple way for users and administrators to install applications. There are currently &ports.count; ports available.
The Ports Collection supports the latest release on the FreeBSD-CURRENT and FreeBSD-STABLE branches. Older releases are not supported and may or may not work correctly with an up-to-date ports collection. Over time, changes to the ports collection may rely on features that are not present in older releases. Wherever convenient, we try not to gratuitously break support for recent releases, but it is sometimes unavoidable. When this occurs, patches contributed by the user community to maintain support for older releases will usually be committed.
Each port
listed here
contains any patches necessary to make the original application source
code compile and run on FreeBSD. Installing an application is as
simple as typing
make
install
in the port directory. If you
download the framework for the entire list of ports by installing the
ports hierarchy, you can have
thousands of applications right at your fingertips.
Each port's Makefile automatically fetches the application source code, either from a local disk, CD-ROM or via ftp, unpacks it on your system, applies the patches, and compiles. If all went well, a simple make install will install the application and register it with the package system.
For most ports, a precompiled package also exists, saving the user the work and time of having to compile anything at all. Use -pkg +pkg install to securely download and install the precompiled version of a port. For more information see Using pkg for Binary Package Management
Index: head/en_US.ISO8859-1/htdocs/relnotes.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/relnotes.xml (revision 47799) +++ head/en_US.ISO8859-1/htdocs/relnotes.xml (revision 47800) @@ -1,113 +1,115 @@ ]>
Each distribution of FreeBSD includes several documentation files describing the particular distribution (RELEASE, SNAPSHOTs, etc.). These files typically include:
Of the files listed above, the release notes, hardware notes, and installation instructions are customized for each architecture supported by FreeBSD.
The release documentation for each -RELEASE version of FreeBSD (for example, &rel.current;-RELEASE) can be found on the releases page of the FreeBSD Web site, as well as its mirrors.
These files (usually in both HTML and text forms) can be found in the top-level directory of each distribution (whether on CD-ROM, an FTP site, or the install floppy disks).
The release documentation files for snapshots can generally be found in the top-level directory of each snapshot.
Automatically-generated HTML versions of the release documentation for FreeBSD -CURRENT and FreeBSD -STABLE are available on the FreeBSD Web site. These documents are continually changing; the versions on the Web site are rebuilt at the same time that the rest of the Web site is updated.