From c6442cf5548dc6e643c7ac833d04049361133f00 Mon Sep 17 00:00:00 2001 From: "Benj. Mako Hill" Date: Sat, 4 Jun 2005 00:07:37 +0000 Subject: [PATCH 1/1] Section 2 on completely a project is complete. The whole thing Author: mako Date: 2001/03/26 04:46:54 Section 2 on completely a project is complete. The whole thing validates and looks good with db2html and db2ps. All that's left to be written is the two Maintaining Sections. --- FreeSoftwareDevelopmentHOWTO.sgml | 405 ++++++++++++++++++++++-- FreeSoftwareProjectManagementHOWTO.sgml | 405 ++++++++++++++++++++++-- 2 files changed, 740 insertions(+), 70 deletions(-) diff --git a/FreeSoftwareDevelopmentHOWTO.sgml b/FreeSoftwareDevelopmentHOWTO.sgml index 4499e57..d41ae2b 100644 --- a/FreeSoftwareDevelopmentHOWTO.sgml +++ b/FreeSoftwareDevelopmentHOWTO.sgml @@ -206,9 +206,9 @@ - The latest version number of this document should always be listed - at my webpage at - http://people.debian.org/~mako/ Debian. + The latest version number of this document should always be listed + on my webpage at + Debian. @@ -319,7 +319,7 @@ development process that it heralds and I think its ultimate success will be rooted in this fact. Please send your additions, comments and criticisms to the following email address : - mako (at) debian (dot) org. + mako@debian. org. @@ -339,8 +339,7 @@ available. If you would like to help with or do a translation, you will gain my utmost respect and admiration and you'll get to be part of a cool process. If you are at all interested, please don't - hesitate to contact me at: mako (at) debian (dot) - org. + hesitate to contact me at: mako@debian.org. @@ -397,7 +396,7 @@ - Indentify and Articulate Your Idea + Indentify and articulate your idea Eric S. Raymond writes about how free software projects start in his paper, "The Cathedral and the Bazaar" which comes as required @@ -427,7 +426,7 @@ - Evaluate Your Idea + Evaluate your idea In evaluating your idea, you need to ask yourself questions. @@ -473,7 +472,7 @@ - freshmeat.net + freshmeat.net: freshmeat describes itself as, the Web's largest index of Linux @@ -485,7 +484,7 @@ - Slashdot + Slashdot: Slashdot provides News for Nerds: Stuff that Matters, @@ -497,7 +496,7 @@ - SourceForge + SourceForge: SourceForge houses and facilitates a growning number of open source and @@ -517,7 +516,7 @@ - Google and Google's Linux Search + Google and Google's Linux Search: Google and Google's Linux @@ -585,7 +584,7 @@ - Choosing a License + Choosing a license Any discussion of licenses is also sure to generate at least a @@ -666,7 +665,7 @@ - The Mechanics of Licensing + The mechanics of licensing The text of the GPL offers - Final License Warning + Final license warning Please, please, please, place your software under some @@ -809,18 +808,18 @@ for details. - Whether you plan on having a split development model or only one version released at a time, my - experience with several free software projects and with the - Debian project has taught me taht use of Linux's version - numbering system is worth taking into consideration. In Debian, - all minor versions are stable distributions (2.0, 2.1, - etc). However, many people assume that 2.1 is an unstable or - development version and continue to use an older version until - they get so frusterated with the lack of development and - progress that they complain. If you never release an odd minor - version but only release even ones, nobody is hurt, and less - people are confused. + Whether you plan on having a split development model (as + described in ) or only one version + released at a time, my experience with several free software + projects and with the Debian project has taught me taht use of + Linux's version numbering system is worth taking into + consideration. In Debian, all minor versions are stable + distributions (2.0, 2.1, etc). However, many people assume that + 2.1 is an unstable or development version and continue to use + an older version until they get so frusterated with the lack of + development and progress that they complain. If you never + release an odd minor version but only release even ones, nobody + is hurt, and less people are confused. @@ -879,16 +878,337 @@ for details. Documentation - + + + A huge number of otherwise fantastic free software applications + have withered because their author was the only person who knew + how to use them well. Even if your program is written primarily + for a techno-savvy group of users, documentation is helpful and + necessary for the survival of your project. You will learn later + in that you must always release + something that is usable. A piece of software without + documentation is not usuable. + + + + There are lots of ways to document your project and lots of + different people to document for. The idea of documentation the + code itself to help facilitate development by a large community is + vital but is outside the scope of this HOWTO. This being the case, + this section deals mostly useful tactics for user-directed + documentation. + + + + A combination of tradition and necessity has resulted in a + semi-regular system method of documentation in most free software + projects that is worth following. Both users and developers expect + to be able to get documentation in several ways and its essential + that you provide the information they are seeking in a form they + can read if your project is ever going to get off the + ground. People have come to expect: + + + + Man pages + + Your users will want to be able to type man + foo end up with a nicely formatted man page highlighting + the basic use of their application. Make sure that before you + release your program, you've planned for this. + + + + Man pages are not difficult to write. There is excellent + documentation on the man page process available through the + The Linux Man-Page-HOWTO available through the + Linux Documentation project (LDP) written by + Jens Schweikhardt. It is available from + Schweikhardt's site or from the + LDP. + + + + It is also possible to write man pages using DocBook SGML and + convert them into man pages. Because manpages are so simple, I + have not been able to follow this up but would love help from + anyone who can give me more information on how exactly this is + done. + + + + + Command line accessable documentation + + + Most users will expect the most basic amount of documentation to + be easily availabe from the command line. For few programs should + then documentation extend for more than one screen (24 or 25 + lines) but it should cover the basic usage, a brief (one or two + sentance) description of the program, a list of commands, all the + major options, and a pointer to more in-depth documentation for + those who need it. The command line documentation for Debian's + apt-get serves as an excellent example and a useful model: + + + +apt 0.3.19 for i386 compiled on May 12 2000 21:17:27 +Usage: apt-get [options] command + apt-get [options] install pkg1 [pkg2 ...] + +apt-get is a simple command line interface for downloading and +installing packages. The most frequently used commands are update +and install. + +Commands: + update - Retrieve new lists of packages + upgrade - Perform an upgrade + install - Install new packages (pkg is libc6 not libc6.deb) + remove - Remove packages + source - Download source archives + dist-upgrade - Distribution upgrade, see apt-get(8) + dselect-upgrade - Follow dselect selections + clean - Erase downloaded archive files + autoclean - Erase old downloaded archive files + check - Verify that there are no broken dependencies + +Options: + -h This help text. + -q Loggable output - no progress indicator + -qq No output except for errors + -d Download only - do NOT install or unpack archives + -s No-act. Perform ordering simulation + -y Assume Yes to all queries and do not prompt + -f Attempt to continue if the integrity check fails + -m Attempt to continue if archives are unlocatable + -u Show a list of upgraded packages as well + -b Build the source package after fetching it + -c=? Read this configuration file + -o=? Set an arbitary configuration option, eg -o dir::cache=/tmp +See the apt-get(8), sources.list(5) and apt.conf(5) manual +pages for more information and options. + + + + It has become a GNU convention to make this information + accessable with the -h and the + --help options. Most GNU/Linux users will expect + to be able to retrieve basic documentation these ways so if you + choose to use different method, be prepared for the flames and + for the fallout that may result. + + + + Files users will expect + + In addition to man pages and online help, there are certain files + where people will look to documentation, especially in any + package containing source code. In a source distribution, most of + these files can be stored in a the root directery of the source + distribution or in a subdirectory of the root called + doc or Documentation. These files include: + + + + + README or Readme + + + + A document containing all the basic installation, + compiliation, and even basic use instructions that make up + the bare minimum information needed to get the program up and + running. A README is not your chance to be verbose but needs + to be concise and effective. An ideal README is at least 30 + lines long and more no more than 250. + + + + + + INSTALL or Install + + + + The INSTALL file should be much shorter than the INSTALL file + and should quicly and concisely describe how to build and + install the program. Usually an install simply instructs the + user to run ./configure; make; make install and touches on + any unusual options that may be necessary. More advanced + users can usually avoid them but it's good practice to at + least glance at the file to understand what can be + expected. For most relatively standard install procedures and + for most programs, INSTALL files are as short as possible are + rarely over 100 lines. + + + + + + Changelog, ChangeLog, CHANGELOG, or changelog + + + + A changelog is a simple file that every well-managed free + software project should include. A changelog is simple the + file that, as its name would imply, logs or documents the + changes to a program. The most simple way to do a changelog + is to simply keep a file with teh source code for your + program and add a section to the top of the changelog with + each release describing what has been, changed, fixed, or + added to the program. It's a good idea to post the changelog + onto the website as well because it can help people decide + whether they want or need to upgrade to a newer version or + wait for a more signifigant upgrade. + + + + + + FAQ + + + + For those of you that don't already + know. FAQ stands for Frequently Asked + Questions and the file is a collection of exactly that. FAQs + are not difficult to make. Simply make a policy that if you + are asked a question or see a question on a mailing list two + or more times, add it the question (and its answer) to your + FAQs. FAQs are more optional than the files listed above but + they can save your time, increase useability, and decrease + headaches on all sides. + + + + + + + + + + Website + + It's only a sort of an issue of documentation but a good website + is quickly becoming an essential part of any free software + project. Your website should provide access to documentation (in + HTML if possible). It should also include a + section for news and events around your program and a section + that details the process of getting involved with development or + testing and creates an open invitation. It should also supply + links to any mailing lists, similar websites, and directly to all + the available ways of downloading your software. + + + + + Other documentation hints + + + It doesn't hurt to distribute any documentation for your program + from your website or anywhere else (FAQs etc) with the + program. Make a FAQ by cutting and posting common questions and + answers from a mailing list or your own email. Then, don't + hesitate through this in the programs tarball. If people don't + need it, they will delete it. I can repeat it over and over: + Too much documentation is not a sin. + + + + All your documentation should be in plaintext, or, in cases where + it is on your website primarily, in HTML. Everyone can cat a + file, everyone has a pager, (almost) everyone can render + HTML. You are welcome to distribute information in PDF, + PostScript, RTF, or any number of other widely used formats but + this information must also be available in plaintext or HTML or + people will be very angry at you. + + Other Presentation Issues - - + + Many of the remaining issues surrounding the creation of a new + free software program fall under what most people describe as + common sense actions. Still, they are worth noting briefly in + hopes that they may remind a developer of something they may have + forgotten. + + + + Package formats + + Package formats may differ depending on the system you are + developing for. For windows based software, Zip archives (.zip) + usually serve as the package format of choice. If you are + developing for GNU/Linux, *BSD, or any UN*X, make sure that your + source code is always available in tar'ed and gzip'ed format + (.tar.gz). UNIX compress (.Z) has gone out of style and + usefulness and faster computers have brought bzip2 (.bz2) into + the spotlit as a more effective compression medium. I now make + all my releases available in both gzip'ed and bzip2'ed formats. + + + + Binary packages are largely distribution specific. You can build + binary packages against a current version of a major + distribution, you will only make your users happy. Try to foster + relationships with users or developers of large distribution to + develop a system for consistent binary packages. It's often a + good idea to provide RedHat RPM's (.rpm), + Debian deb's (.deb) and source RPM's + SRPM's. Binary packages can also be compiled + against a specified system with specificed libraries and + distributed in tar.gz format as well. Remember: While + these binaries packages are nice, geting the source packaged and + released should always be your priority. Other can and will do + the the binary packages for you. + + + + + Useful tidbits and presentation hints + + + + + + + Make sure that your program can always be found in a + single location. Often this means that you have a + single directory accessable via FTP or + HTTP where the newest version will be + quickly recognized. One effective technique is a provide a + symlink called projectname-latest that is + always pointing to the most recent released or development + version of your free software project. + + + + + + Make sure that there is a consistent email address + for bug reports. It's usually a good idea to make + this something that is NOT your primary email address like + projectname@host or projectname-bugs@host. This way if you + ever decide to hand over maintainership or if your email + address changes, you simply need to change where this email + address forwards to. It also will allow for more than one + person to deal with the influx of mail that is created if your + project becomes as huge as you hope it will. + + + + + + + @@ -946,6 +1266,26 @@ for details. fswd!users + + + + Testing and Testers + + + + + + + Setting up a Support Infrastructure + + + + + + + Releasing Your Program + + @@ -954,12 +1294,7 @@ for details. - - - Testing and Testers - - diff --git a/FreeSoftwareProjectManagementHOWTO.sgml b/FreeSoftwareProjectManagementHOWTO.sgml index 4499e57..d41ae2b 100644 --- a/FreeSoftwareProjectManagementHOWTO.sgml +++ b/FreeSoftwareProjectManagementHOWTO.sgml @@ -206,9 +206,9 @@ - The latest version number of this document should always be listed - at my webpage at - http://people.debian.org/~mako/ Debian. + The latest version number of this document should always be listed + on my webpage at + Debian. @@ -319,7 +319,7 @@ development process that it heralds and I think its ultimate success will be rooted in this fact. Please send your additions, comments and criticisms to the following email address : - mako (at) debian (dot) org. + mako@debian. org. @@ -339,8 +339,7 @@ available. If you would like to help with or do a translation, you will gain my utmost respect and admiration and you'll get to be part of a cool process. If you are at all interested, please don't - hesitate to contact me at: mako (at) debian (dot) - org. + hesitate to contact me at: mako@debian.org. @@ -397,7 +396,7 @@ - Indentify and Articulate Your Idea + Indentify and articulate your idea Eric S. Raymond writes about how free software projects start in his paper, "The Cathedral and the Bazaar" which comes as required @@ -427,7 +426,7 @@ - Evaluate Your Idea + Evaluate your idea In evaluating your idea, you need to ask yourself questions. @@ -473,7 +472,7 @@ - freshmeat.net + freshmeat.net: freshmeat describes itself as, the Web's largest index of Linux @@ -485,7 +484,7 @@ - Slashdot + Slashdot: Slashdot provides News for Nerds: Stuff that Matters, @@ -497,7 +496,7 @@ - SourceForge + SourceForge: SourceForge houses and facilitates a growning number of open source and @@ -517,7 +516,7 @@ - Google and Google's Linux Search + Google and Google's Linux Search: Google and Google's Linux @@ -585,7 +584,7 @@ - Choosing a License + Choosing a license Any discussion of licenses is also sure to generate at least a @@ -666,7 +665,7 @@ - The Mechanics of Licensing + The mechanics of licensing The text of the GPL offers - Final License Warning + Final license warning Please, please, please, place your software under some @@ -809,18 +808,18 @@ for details. - Whether you plan on having a split development model or only one version released at a time, my - experience with several free software projects and with the - Debian project has taught me taht use of Linux's version - numbering system is worth taking into consideration. In Debian, - all minor versions are stable distributions (2.0, 2.1, - etc). However, many people assume that 2.1 is an unstable or - development version and continue to use an older version until - they get so frusterated with the lack of development and - progress that they complain. If you never release an odd minor - version but only release even ones, nobody is hurt, and less - people are confused. + Whether you plan on having a split development model (as + described in ) or only one version + released at a time, my experience with several free software + projects and with the Debian project has taught me taht use of + Linux's version numbering system is worth taking into + consideration. In Debian, all minor versions are stable + distributions (2.0, 2.1, etc). However, many people assume that + 2.1 is an unstable or development version and continue to use + an older version until they get so frusterated with the lack of + development and progress that they complain. If you never + release an odd minor version but only release even ones, nobody + is hurt, and less people are confused. @@ -879,16 +878,337 @@ for details. Documentation - + + + A huge number of otherwise fantastic free software applications + have withered because their author was the only person who knew + how to use them well. Even if your program is written primarily + for a techno-savvy group of users, documentation is helpful and + necessary for the survival of your project. You will learn later + in that you must always release + something that is usable. A piece of software without + documentation is not usuable. + + + + There are lots of ways to document your project and lots of + different people to document for. The idea of documentation the + code itself to help facilitate development by a large community is + vital but is outside the scope of this HOWTO. This being the case, + this section deals mostly useful tactics for user-directed + documentation. + + + + A combination of tradition and necessity has resulted in a + semi-regular system method of documentation in most free software + projects that is worth following. Both users and developers expect + to be able to get documentation in several ways and its essential + that you provide the information they are seeking in a form they + can read if your project is ever going to get off the + ground. People have come to expect: + + + + Man pages + + Your users will want to be able to type man + foo end up with a nicely formatted man page highlighting + the basic use of their application. Make sure that before you + release your program, you've planned for this. + + + + Man pages are not difficult to write. There is excellent + documentation on the man page process available through the + The Linux Man-Page-HOWTO available through the + Linux Documentation project (LDP) written by + Jens Schweikhardt. It is available from + Schweikhardt's site or from the + LDP. + + + + It is also possible to write man pages using DocBook SGML and + convert them into man pages. Because manpages are so simple, I + have not been able to follow this up but would love help from + anyone who can give me more information on how exactly this is + done. + + + + + Command line accessable documentation + + + Most users will expect the most basic amount of documentation to + be easily availabe from the command line. For few programs should + then documentation extend for more than one screen (24 or 25 + lines) but it should cover the basic usage, a brief (one or two + sentance) description of the program, a list of commands, all the + major options, and a pointer to more in-depth documentation for + those who need it. The command line documentation for Debian's + apt-get serves as an excellent example and a useful model: + + + +apt 0.3.19 for i386 compiled on May 12 2000 21:17:27 +Usage: apt-get [options] command + apt-get [options] install pkg1 [pkg2 ...] + +apt-get is a simple command line interface for downloading and +installing packages. The most frequently used commands are update +and install. + +Commands: + update - Retrieve new lists of packages + upgrade - Perform an upgrade + install - Install new packages (pkg is libc6 not libc6.deb) + remove - Remove packages + source - Download source archives + dist-upgrade - Distribution upgrade, see apt-get(8) + dselect-upgrade - Follow dselect selections + clean - Erase downloaded archive files + autoclean - Erase old downloaded archive files + check - Verify that there are no broken dependencies + +Options: + -h This help text. + -q Loggable output - no progress indicator + -qq No output except for errors + -d Download only - do NOT install or unpack archives + -s No-act. Perform ordering simulation + -y Assume Yes to all queries and do not prompt + -f Attempt to continue if the integrity check fails + -m Attempt to continue if archives are unlocatable + -u Show a list of upgraded packages as well + -b Build the source package after fetching it + -c=? Read this configuration file + -o=? Set an arbitary configuration option, eg -o dir::cache=/tmp +See the apt-get(8), sources.list(5) and apt.conf(5) manual +pages for more information and options. + + + + It has become a GNU convention to make this information + accessable with the -h and the + --help options. Most GNU/Linux users will expect + to be able to retrieve basic documentation these ways so if you + choose to use different method, be prepared for the flames and + for the fallout that may result. + + + + Files users will expect + + In addition to man pages and online help, there are certain files + where people will look to documentation, especially in any + package containing source code. In a source distribution, most of + these files can be stored in a the root directery of the source + distribution or in a subdirectory of the root called + doc or Documentation. These files include: + + + + + README or Readme + + + + A document containing all the basic installation, + compiliation, and even basic use instructions that make up + the bare minimum information needed to get the program up and + running. A README is not your chance to be verbose but needs + to be concise and effective. An ideal README is at least 30 + lines long and more no more than 250. + + + + + + INSTALL or Install + + + + The INSTALL file should be much shorter than the INSTALL file + and should quicly and concisely describe how to build and + install the program. Usually an install simply instructs the + user to run ./configure; make; make install and touches on + any unusual options that may be necessary. More advanced + users can usually avoid them but it's good practice to at + least glance at the file to understand what can be + expected. For most relatively standard install procedures and + for most programs, INSTALL files are as short as possible are + rarely over 100 lines. + + + + + + Changelog, ChangeLog, CHANGELOG, or changelog + + + + A changelog is a simple file that every well-managed free + software project should include. A changelog is simple the + file that, as its name would imply, logs or documents the + changes to a program. The most simple way to do a changelog + is to simply keep a file with teh source code for your + program and add a section to the top of the changelog with + each release describing what has been, changed, fixed, or + added to the program. It's a good idea to post the changelog + onto the website as well because it can help people decide + whether they want or need to upgrade to a newer version or + wait for a more signifigant upgrade. + + + + + + FAQ + + + + For those of you that don't already + know. FAQ stands for Frequently Asked + Questions and the file is a collection of exactly that. FAQs + are not difficult to make. Simply make a policy that if you + are asked a question or see a question on a mailing list two + or more times, add it the question (and its answer) to your + FAQs. FAQs are more optional than the files listed above but + they can save your time, increase useability, and decrease + headaches on all sides. + + + + + + + + + + Website + + It's only a sort of an issue of documentation but a good website + is quickly becoming an essential part of any free software + project. Your website should provide access to documentation (in + HTML if possible). It should also include a + section for news and events around your program and a section + that details the process of getting involved with development or + testing and creates an open invitation. It should also supply + links to any mailing lists, similar websites, and directly to all + the available ways of downloading your software. + + + + + Other documentation hints + + + It doesn't hurt to distribute any documentation for your program + from your website or anywhere else (FAQs etc) with the + program. Make a FAQ by cutting and posting common questions and + answers from a mailing list or your own email. Then, don't + hesitate through this in the programs tarball. If people don't + need it, they will delete it. I can repeat it over and over: + Too much documentation is not a sin. + + + + All your documentation should be in plaintext, or, in cases where + it is on your website primarily, in HTML. Everyone can cat a + file, everyone has a pager, (almost) everyone can render + HTML. You are welcome to distribute information in PDF, + PostScript, RTF, or any number of other widely used formats but + this information must also be available in plaintext or HTML or + people will be very angry at you. + + Other Presentation Issues - - + + Many of the remaining issues surrounding the creation of a new + free software program fall under what most people describe as + common sense actions. Still, they are worth noting briefly in + hopes that they may remind a developer of something they may have + forgotten. + + + + Package formats + + Package formats may differ depending on the system you are + developing for. For windows based software, Zip archives (.zip) + usually serve as the package format of choice. If you are + developing for GNU/Linux, *BSD, or any UN*X, make sure that your + source code is always available in tar'ed and gzip'ed format + (.tar.gz). UNIX compress (.Z) has gone out of style and + usefulness and faster computers have brought bzip2 (.bz2) into + the spotlit as a more effective compression medium. I now make + all my releases available in both gzip'ed and bzip2'ed formats. + + + + Binary packages are largely distribution specific. You can build + binary packages against a current version of a major + distribution, you will only make your users happy. Try to foster + relationships with users or developers of large distribution to + develop a system for consistent binary packages. It's often a + good idea to provide RedHat RPM's (.rpm), + Debian deb's (.deb) and source RPM's + SRPM's. Binary packages can also be compiled + against a specified system with specificed libraries and + distributed in tar.gz format as well. Remember: While + these binaries packages are nice, geting the source packaged and + released should always be your priority. Other can and will do + the the binary packages for you. + + + + + Useful tidbits and presentation hints + + + + + + + Make sure that your program can always be found in a + single location. Often this means that you have a + single directory accessable via FTP or + HTTP where the newest version will be + quickly recognized. One effective technique is a provide a + symlink called projectname-latest that is + always pointing to the most recent released or development + version of your free software project. + + + + + + Make sure that there is a consistent email address + for bug reports. It's usually a good idea to make + this something that is NOT your primary email address like + projectname@host or projectname-bugs@host. This way if you + ever decide to hand over maintainership or if your email + address changes, you simply need to change where this email + address forwards to. It also will allow for more than one + person to deal with the influx of mail that is created if your + project becomes as huge as you hope it will. + + + + + + + @@ -946,6 +1266,26 @@ for details. fswd!users + + + + Testing and Testers + + + + + + + Setting up a Support Infrastructure + + + + + + + Releasing Your Program + + @@ -954,12 +1294,7 @@ for details. - - - Testing and Testers - - -- 2.39.5