X-Git-Url: https://projects.mako.cc/source/fspm_howto/blobdiff_plain/467f7b3941c33772dff1f24e02b7f7041bad1579..44fb1663e93995abba200e89e1982e189194010b:/FreeSoftwareProjectManagementHOWTO.sgml?ds=inline diff --git a/FreeSoftwareProjectManagementHOWTO.sgml b/FreeSoftwareProjectManagementHOWTO.sgml index a04bac6..ad8e78f 100644 --- a/FreeSoftwareProjectManagementHOWTO.sgml +++ b/FreeSoftwareProjectManagementHOWTO.sgml @@ -10,7 +10,7 @@ Benjamin Mako - Hill + Hill
mako@debian.org @@ -22,7 +22,7 @@ v0.01 - 1 January 2001 + 25 March 2001 bch Initial Release @@ -118,11 +118,9 @@ Copyright Information - This document is copyrighted (c) 2000 Stein Gjoen and is + This document is copyrighted (c) 2000 Benjamin (Mako) Hill and is distributed under the terms of the Linux Documentation Project - (LDP) license, stated below. Replace with your name, - or supply a new license, when you use this skeleton for a new - HOWTO. + (LDP) license, stated below. @@ -208,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. @@ -253,6 +251,7 @@ + @@ -320,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. @@ -340,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. @@ -356,1096 +354,1477 @@ fswd!starting + + With very little argument, starting a project is most difficult + part of successful free software development. Laying a firm + foundation for your project will determine whether your project + flourishes or withers away and dies. It is also the subject that is + of most immediate interest to anyone reading this document as a + tutorial. + + + + Starting a project also involves a dilemna that you as a developer + must try and deal with. No potential user for your program will be + interested by a program that doesn't work. Simultaneously, the + development process that you want to employ holds involvement of + users as essential to the process of the development that will + realize this working software. + + + + It is in these dangerous initial moments that anyone working to + start a free software project must strike a balance. One of the + most important ways that omeone trying to start a project can work + towards this balance is by establishing a framework for the + development process through some of the ways mentioned in this + section. + Choosing a Project - - + + If you are reading this document, there's a good chance you + already have an idea for a project in mind. Chances are pretty + good, it fills a gap by doing something that no other free + software process does or or does it in a way that is unique + enought to necessitate a seperate project. + - - Deciding on a License - + + 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 + reading for any free softare development. You can find it online + . + - + + In "The Cathedral and Bazaar," Raymond tells us that: + Every good work of software starts by scratching a + developers itch. Raymond now widely accepted + hypothesis is that new free software programs are written, first + and foremost, to solve a specific problem facing the developer. + - - Choosing a Method of Version Numbering - + + If you have an idea for a program in mind, chances are good that + it it is targetting a specific problem or itch you want to see + scratched. This idea is the project. Articulate it + clearly. Write it out. Describe the problem you will attack in + detail. The success of your project in tackling a particular + problem will be tied to your ability to identify that problem + early on. Find out exactly what it is that you want your project + to do. + + - + + Evaluate your idea - - Documentation - + + In evaluating your idea, you need to ask yourself questions. + Before you move any further into this HOWTO, you need to + determine if the free software development model really is the + right one for your project. Obviously, since the program + scratches your itch, you are definately interested in seeing it + implemented in code. But, because one hacker coding alone fails + to qualify as a free software development effort, you need to ask + yourself the question: Is anybody else + interested? + - + + Sometimes the answer is no. If you want to + write a set of scripts to sort your MP3 + collection on your machine, maybe the free software development + model is not the best one to choose. However, if you want to + write a set of scripts to sort anyone's + MP3s, a free software project might fill a useful gap. + - - Other Presentation Issues - + + Luckily, The Internet is a place so big and diverse that, chances + are, there is someone, somewhere, who shares your interests and + how feels the same itch. It is the fact that there are so many + people with so many similar needs and desires that introduces the + second major question: Has somebody already had your + idea or a reasonably similar one? + + + + Finding Similar Projects + + + There are places you can go on the web to try and answer this + question. If you have experience with the free software + community, you are probably already familiar with all of these + sites. All of the resources listed bellow offer searching of + their databases: + + + + + + freshmeat.net: + + freshmeat + describes itself as, the Web's largest index of Linux + and Open Source software and its reputation along + these lines remains unquestioned. If you can't find it on + freshmeat, its doubtful that you'll find it indexed anywhere + else. + + + + + Slashdot: + + Slashdot + provides News for Nerds: Stuff that Matters, + which usually includes discussion of free software, open + source, technology, and geek culture new and events. It is + not unusual for an particularly sexy develpment effort to be + announced here so it definately worth checking. + + + + + SourceForge: + + SourceForge + houses and facilitates a growning number of open source and + free software projects, SourceForge is quickly becoming a + nexus and an necessary stop for free software + developers. SourceForge's software + map and new + releases pages. should be necessary stops before + embarking on a new free software project. SourceForge also + provides a at Code Snippet + Library which contains useful reusuable chunks of + code in an array of langauges which can come in useful in any + project. + + + + + Google and Google's Linux Search: + + Google and + Google's Linux + Search, provide powwerful web searches that may + reveal people working on similar projects. It is not a + catalog of software or news like freshmeat or Slashdot, but + it is worth checking before you begin pouring your effort + into a redundant project. + + + + + + + + + Deciding to Proceed + + Once you have successfull charted the terrain and have an idea + bout what kinds of similar free software projects exist, every + developer needs to decide whether to proceed with their own + project. It is rare that a new project seeks to accomplish a + goal that is not similar to related to the goal of another + project. Anyone starting a new project needs to ask themselves: + Will the new project be duplicating work done by + another project? Will the new project be competing for + developers with an existing project? Can the goals of the new + project be accomplished by adding functionality to an existing + project? + - + + If the answer to any of these questions is yes, try to contact + the developer of the existing project in question and see if he + or she might be willing to collaborate with you. + + + + This may be the single most difficult aspect of free software + development for many developers but it is essential. It is easy + to become fired up by and idea and be caught up in the momentum + and excitement of a new project. It is often extremely difficult + but it is important that any free software developer rememeber + that the best interests of the of the free software community + and the quickest way to accomplish ones own project's goals and + the goals of similar project can often be accomplished by + not starting a new project. + - - Nuturing Future Development + + - + - + + Licensing your Software + + + On one level, the difference between a piece of free software and + a piece of propriety software is the license. A license helps both + you as the developer by protecting your legal rights to your + software and helps demonstrate to those who wish to help you or + your project that they are encouraged to join. + + + + Choosing a license - + + Any discussion of licenses is also sure to generate at least a + small flamewar as there are strong feelings that some free + software licenses are better than other free software + licenses. This discussion also brings up the question of + Open Source Software and the debate around + Open Source Software and Free + Software. However, because I've written the Free Software + Development HOWTO and not the Open Source Development HOWTO, my + own allegiences in this argument are out in the open. + - - Maintaining a Project: Interacting with Developers + + In attempting to reach a middle ground, I recommend picking any + license that conforms to the Debian Free Software + Guidlines. Examples of these licenses are the + GPL, the BSD, and the + Artistic License. Conforming to the definition of Free Software + offered by Richard Stallman in The Free + Software Definition, any of these licenses will + uphold, users' freedom to run, copy, distribute, study, + change and improve the software. There are other licenses + as well but sticking with a more common license will offer the + advantage of immediate recognition and undestanding. + - - fswd!developers - + + In attempting a more in-depth analysis, I agree with Karl Fogel's + description of licenses as falling into two groups: those that + are the GPL and those that are not the + GPL. + - + + Personally, I license all my software under the + GPL. Created and protected by the Free + Software Foundation and the GNU Project, the + GPL is the license for the Linux kernel, + GNOME, Emacs, and the majority of Linux software. Its an easy + choice but I believe it is a good one. However, there + is a viral aspect to the GPLthat prevents the + mixture of GPL'ed code with + non-GPL'ed code. To many people (myself + included), this is a benefit, but to some, it is a major + drawback. + - - Delegating Work - + + The three major license can be found at the following locations: + - + + + + The GNU + General Public License + + + The + BSD License + + + The Artistic + License + + + - - Stable and Development Branches - + + In all cases, please read through any license before + your release your software. As the developer, you can't afford + any license surprises. + + - + + The mechanics of licensing - - Freezing - + + The text of the GPL offers a good + description of mechanics of applying a license to a piece + of software. A checklist for applying a license would include: + - + + + - - Avoiding the Code Cram Effect - + If at all possible, attach and distribute a full copy of + the license with the source and binary in a seperate + file. - + + - - Accepting and Rejecting Patches - - + At the top of each source file in your program, attach a + notice of copyright and information on where the full license + can be found. The GPL recommends that each + file begin with: - + +one line to give the program's name and an idea of what it does. +Copyright (C) yyyy name of author - - Maintaining a Project: Interacting with Users +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. - - fswd!users - +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + - + + The GPL goes on to recommend attaching + information on contacting you (the author) via email or + physical mail. + - - Announcing Your Project - + + - + + The GPL continues and suggests that if your + program runs in an interactive mode, you should have the + program output a notice each time it enters interactive mode + that includes a message like this one that points to more + information about the programs licensing: + - - Testing and Testers - - + +Gnomovision version 69, Copyright (C) year name of author +Gnomovision comes with ABSOLUTELY NO WARRANTY; for details +type `show w'. This is free software, and you are welcome +to redistribute it under certain conditions; type `show c' +for details. + + + + + Finally, it might be helpful to include a + copyright disclaimer with the program from an + employer or a school if you work as a programmer or if it seems + like your employer or school might be able to make an argument + for ownership of your code. + - + + + - - Samples + + Final license warning - - This section gives some simple SGML examples you could - use. Read the SGML source to see how it was done. - + + Please, please, please, place your software under some + license. It may not seem important, and to you, it may not be, + but licenses are important. For a piece of software to be + included in the Debian GNU/Linux distrobution, it must have a + license that fits the Debian Free Software + Guidelines. If you have no license, your program can be + distributed in part of Debian until you rerelease it under a free + license. Please save yourself and others trouble by releasing the + first version of your software with a clear license. + - - Further information and examples can be obtained from the publication - DocBook: The Definitive - Guide. Written by Norman Walsh - and Leonard Muellner; 1st Edition, October 1999. - - - + - - Lists + + + + + Choosing a Method of Version Numbering - Lists are used frequently, and are available in a number - of formats shown below. + The most important thing about a system of numbering is + that there is one. It may seem pedantic to emphasize + this point but you'd be surprised at the number of scripts and + small programs that pop up without any version number. - A list in which each entry is marked with a bullet or other dingbat: + The second most important thing about a system of + numbering is that the numbers always go up. Automatic + versioning systems and people's sense of order in the universe + will fall apart if version numbers don't rise. It doesn't + really matter if 2.1 is a big jump and + 2.0.005 is a small jump but it does matter that 2.1 is more recent + than 2.0.005. - + Follow these two rules and you will not go wrong. Still there are + several versioning system that are well known, useful, and that + might be worth looking into before you release your first version. + + + + Linux kernel version numbering: - Apples - + The Linux kernel uses a versioning system where the any + minor odd minor version number refers to an development or + testing release and any even minor version number refers to a + stable version. Under this system, 2.1 and 2.3 kernels were and + always will be development and testing kernels and 2.0, 2.2. and + 2.4 kernels are all production code with a higher degree of + stability. + - - Oranges - + + 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. + - - Bananas + + + Wine version numbering: + + Because of the unusual nature of wine's development where + it constantly improving but not working towards any immediately + achievable goal, wine is released every three weeks. Wine does + this by versioning their releases in Year Month Day format where + each release might be labeled wine-XXXXXXXX where + the version from Janurary 04, 2000 would be + wine-20000104. For certain projects, Year Month + Day format can make a lot of sense. + - - + + + + Mozilla milestones: + + When one considers Netscape 6 and verdor versions, the + mozilla's project development structure is one of the most + complex free software model available. Their version numbering + has reflected the unique situation in which it is + developed. + - - A list in which each entry is composed of a set of one or more - terms and an associated description: - + + Mozilla's development structure has historically been made up + of milestones. From teh beginning of the mozilla project, the + goals of the project in the order and degree to which they were + to be achieved were charted out on a series of road + maps. Major points and achievements along this roadmaps + were marked as milestones. Therefore, mozilla was built and + distributed nightly as "nightly builds" but on a day when the + goals of a milestone on the roadmap had been reached, that + particular build was marked as a milstone release. + - - + + While I haven't seen this method employed in any other projects + to date, I like the idea and think that it might have value in + any testing or development branch of a large free application + under heavy development. + - - Fruits - - such as apples, oranges, and more. - - + + + + - - Nuts - - Don't eat too many; you are what you eat. - - + - - Vegetables - - Potatos are spelled with care. - - + + 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. - A list in which each entry is marked with a sequentially - incremented label: + 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: + - - Step one - + + Man pages - - Step two - + 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. + + - - Links + + Command line accessable documentation - - Links can be used within your documents to refer to - different sections and chapters or to refer to documents external - to yours. - + + 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: + - - Internal links + +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. + - Click on the link to jump to the top of - this chapter. Note the anchor at the section tag. + 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. + + + + + - - External links - + + Website - Click on this link - to jump to the LDP site. Note you can use http, ftp, news and - other protocols in the locator if required. + 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. + - - Images + + 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. + + + - - Avoid diagrams if possible as this cannot be rendered - in the ASCII outputs which are still needed by many around the - world. - + + + Other Presentation Issues -
- Graphics Test Image - -
+ 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. - - Here is another variation which allows for ALT text: - + + 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 - - - ALT text to be used: Green Ball - - + + - + - Caption for the graphic goes here: This is a Green Ball. + 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. + + - + + + + + - + - - Structure + - - A quick overview on how all parts fit together in the overall - structure. An example from the Multi Disk HOWTO is used. - + + Maintaining a Project: Interacting with Developers + + fswd!developers + - As this type of document is supposed to be as much for learning as - a technical reference document I have rearranged the structure to - this end. For the designer of a system it is more useful to have - the information presented in terms of the goals of this exercise - than from the point of view of the logical layer structure of the - devices themselves. Nevertheless this document would not be - complete without such a layer structure the computer field is so - full of, so I will include it here as an introduction to how it - works. + Once you have gotten the project started, you have gotten over the + most difficult hurdles in the development process of your + program. Laying a firm foundation is essential, but the development + process itself is equally important and provides an equal number of + opportunities for failure. In the next two sections, I will and + cover running a project by discussing how to maintain a project + rhough interactions with developers and with users. - - - - Logical structure - - - disk!structure, I/O subsystem - - - - This is based on how each layer access each other, traditionally - with the application on top and the physical layer on the bottom. - It is quite useful to show the interrelationship between each of - the layers used in controlling drives. - - - ___________________________________________________________ - |__ File structure ( /usr /tmp etc) __| - |__ File system (ext2fs, vfat etc) __| - |__ Volume management (AFS) __| - |__ RAID, concatenation (md) __| - |__ Device driver (SCSI, IDE etc) __| - |__ Controller (chip, card) __| - |__ Connection (cable, network) __| - |__ Drive (magnetic, optical etc) __| - ----------------------------------------------------------- - - + + In releasing your program, your program becomes free software. This + transition is more than just a larger user base. By releasing your + program as free software, your software + becomes the free software community's + software. The direction of your software's development will be + reshaped, redirected, and fully determined by your users and, to a + larger extent, by other developers in the community. + - - In the above diagram both volume management and RAID and - concatenation are optional layers. The 3 lower layers are in - hardware. All parts are discussed at length later on in this - document. - - + + The major difference between free software development and propriety + software development is the developer base. As the leader of a free + software project, you need to attract and keep developers in a way + that leaders of proprietary software projects sipmly don't have to + worry about. As the person leading development of a free + software project, you must harness the work of fellow developers by + making responsible decisions and by and by choosing not to make + decisions responsibly. You have to direct developers without being + overbearing or bossy. You need to strive to earn respect and never + forget to give it. + - + - - Document structure + + Delegating Work - Most users start out with a given set of hardware and some plans - on what they wish to achieve and how big the system should be. - This is the point of view I will adopt in this document in - presenting the material, starting out with hardware, continuing - with design constraints before detailing the design strategy that - I have found to work well. I have used this both for my own - personal computer at home, a multi purpose server at work and - found it worked quite well. In addition my Japanese co-worker in - this project have applied the same strategy on a server in an - academic setting with similar success. + By now, you've hypothetically followed me through the early + writing of a piece of software, the creation of a website and + system of documentation and and we've gone ahead and (as will be + discussed in ) released it to the rest + of the world. Times passes, and if things go well, people become + interested and want to help. The patches begin flowing in. - Finally at the end I have detailed some configuration tables for - use in your own design. If you have any comments regarding this - or notes from your own design work I would like to hear from you - so this document can be upgraded. + Like the parent of any child who grows up, it's now time + to wince and smile and do most difficult thing in any parents + life: It's time to let go. - - - - - - Reading plan - As you go beyond 50 pages or so there will be a lot of - text that experts and even the experienced do not need to read. - Keeping in mind that we wish to care for all kinds of people in - the Linux world we might have to make a reading plan. Again, - an example follows from the Multi Disk HOWTO. + Delegation is the politcal way of describing this process of + letting go. It is the process of handing some of + the responsibility and power over your project to other reponsible + and involved developers. It is difficult for anyone who has + invested a large deal of time and energy into a project but it + essential for the growth of any free software project. One person + can only do so much. A free software project is nothing + without the involvement of a group of developers. A group of + developers can only be maintained through respectful and + responsible leadership and delegation. - Although not the biggest HOWTO it is nevertheless rather big - already and I have been requested to make a reading plan to make - it possible to cut down on the volume. + As your project progresses, you will notice people who are putting + signfigant amounts of time and effort into your project. These + will be the people submitting the most patches, posting most on + the mailing lists, engaging in long email discussions. It is your + responsiblity to contact these people and to try and shift some of + the power and responsiblity of your position as the project's + maintainer onto them (if they want it). There are several easy + weays you can do this: - - - - - Expert - - - (aka the elite). If you are familiar with Linux as well as - disk drive technologies you will find most of what you need in - the appendices. Additionally you are recommended to read the - FAQ and the chapter. - - - - - - Experienced - - - (aka Competent). If you are familiar with computers in - general you can go straight to the chapters on - and continue from there on. - - - - - - Newbie - - - (mostly harmless). You just have to read the whole thing. - Sorry. In addition you are also recommended to read all the - other disk related HOWTOs. - - - - - - - - - - - - - - - - - Technologies - - - (your index root)!technologies - - - - Introduction of technology for the newbie with a few - references to detailed works. Remember that not everyone has - Internet access so you have to explain in sufficient details so - even the newbie can get by. - - - - - - - - - - - Implementation - - - (your index root)!implementation - - - - Now your readers should have a sufficient knowledge of - what this is about and now we come to the hands on of implementing - your clever scheme. - - - - - - - - - - - Maintenance - - - (your index root)!maintenance - - - - Few systems and designs are maintenance free, here you - explain how to keep the system running. - - - - - - - - - - - Advanced Issues + + How to delegate + + + Like anything, its easier to see how others delegate than to do + it yourself. You may find that other developers seem even more + experienced or knowledgeable than you. Your job as a maintainer + does not mean you have to have to be the best or the + brightest. It means you need are responsible for showing good + judgement and for recognizing solutions that are maintainable and + are not. In a sentance: Keep an eye out for other + qualified developers who show an interest and sustained + involvement with your project and try and shift responsibility + towards them. The following ideas might be good places + to start or good sources of inspiriation: + + + + Allow a larger group of people write access to your CVS + reponsitory and make real efforts towards rule by a + committee - - (your index root)!advanced topics - + + Apache is an + example of a project that is run by small group of developers + who vote on major technical issues and the admission of new + members and all have write access to the main source + repository. Their process is detailed online. + - - You can get most things up and running in a quick and - dirty fashion, useful for testing and getting used to how things - work. For more serious use you would need to be a little more - advanced. This is the place to explain it all, if applicable. - + + The Debian Project + is an extreme example of rule by committee. At current count, + more than 700 developers have full responsibility for certain + aspects of the projects. All these developers can upload into + the main ftp servers, and vote on major issues. Direction for + the project is determined by the project social + contract and a constitution. To + facilitate this system, there are special teams (i.e. the + install team, the Japanese language team) and a technical + committee and a project lead. There is a project lead as well + but the lead's main responsiblity is to, Appoint + Delegates or delegate decisions to the Technical + Committee. + - + + While both of these projects operate on a scale that your + project will not (at least initially), their example is + helpful. Debian's idea of a project who lead who can do + nothing but delegate can serve as a + charicature of how a project can involve and empower a huge + number of developers and grow to a huge size. + - + + + Publicly appoint someone as the release manager for a + specific release. - + + A relase manager is usually responsible for coordinating + testing, encforcing a code freeze, being responsible for + stability and quality control, packaging up the software, and + placing it in the approrpriate places to be downloaded. + - - Further Information + + This use of the release manager is a good way to give yourself a + break and to shift the responsibility for accepting and + rejecting patches to somenoe else. It is a good way of very + clearly defining a chunk of work on the project as belonging to + a certain person and its a great way of giving yourself a break. + + - - (your index root)!information resources - + + Delegate control of an entire branch. + + If your project chooses to have branches (as described in ), it might be a good idea to appoint someone + else to be the the head of a branch. If you like focusing your + energy on development releases and the implementation of new + features, had total control over the stable releases to a + well-suiteded developer. + - - A HOWTO cannot describe everything, some times the user - has to venture out on th enet to get more information or just - updates. Here is the place to tell where and how. Again examples - from the Multi Disk HOWTO, replace as needed. There is wealth - of information one should go through when setting up a major system, - for instance for a news or general Internet service provider. The - FAQs in the following groups are useful: - + + The author of linux, Linus Torvalds, came out and crowned Alan + Cox as the man for stable kernels. All patches + for stable kernels go to Alan and, if Linus were to be taken + away from work on linux for any reason, Alan Cox would be more + than suited to fill his role as the acknowledged heir to the + linux maintainership. + + + + - + - - News groups + + Accepting and Rejecting Patches + + This HOWTO has already touched on the fact that as the maintainer + of a free software project, one of primary and most important + responsibilities will be accepting and rejecting patches submitted + to you by other developers. + - - disk!information resources!news groups - + + Technical judgement - Some of the most interesting news groups are: + + In Open Source Development with CVS, Karl + Fogel makes a convincing argument that the most important things + to keep in mind are a firm knowledge of the scope of your program + (that's the idea I talked about in ) and the ability to recognize, + facilitate, and direct evolution of a free + software program so that the program can grow and change and + incorporate functionatlity that was orignally unforseen but avoid + digressions that might expand the scope of the program too much + and result and push the project towards an early death under its + own weight and unweildiness. These are the criteria that you as a + project mainatiner should take into account each time you recieve + a patch. + - + + Fogel elaborates on this again and states the the + questions to ask yourself when considering whether to implement + (or approve) a change are: + - - - Storage. - - + + - - - PC storage. - - + + Will it benefit a significant percentage of the program's + user community? + - - - AFS. - - + + Does it fit within the program's domain or within a + natural, intuitive extension of that domain? + - - - SCSI. - - + + - - - Linux setup. - - + + The answers to these questions are never straighforward and its + very possible (and even likely) that the person who submitted the + patch may feel differently about the answer to those questions + than you do. However, if you feel that that the answer to either + of those questions is no, it is your responsiblity + to reject the change. If you fail to do this, the project will + become unweildy and unmaintainable and will ultimately fail. + + - - + + Rejecting patches - - Most newsgroups have their own FAQ that are designed to answer most - of your questions, as the name Frequently Asked Questions indicate. - Fresh versions should be posted regularly to the relevant newsgroups. - If you cannot find it in your news spool you could go directly to the - FAQ main archive FTP site. - The WWW versions can be browsed at the - FAQ - main archive WWW site. - + + Rejecting patches is probably the most difficult and the most + sesnative job that the maintainer of any free software project + has to face. But sometimes it has to be done. I mentioned earlier + (in and in ) that any developer needs to try and + balance your responsibility and power to make what you think are + the best technical decisions with the fact that you will lose + support from other developers if you seem like you are on a + powertrip or being overly bossy or possesive of a community-based + project. I recommend that you keep three major facts in mind when + rejecting patches (or other changes): + - - Some FAQs have their own home site, of particular interest: + + Bring it to the community + + One of the best ways of justifying a decision to reject a patch + and working to not seem like you keep an iron grip on your + project is by not making the decision alone at all. It might + make sense to turn over larger proposed changes or more + difficult decisions to a development mailing list where they can + be discussed. There will be some patches (bug fixes, etc.) which + will definately be accepted and some that you feel are so off + base that they do not even merit further discussion. It is those + that fall into the grey area between these two groups that might + merit a quick forward to a mailing list. + - + + I recommend this process wholeheartedly. As the project + maintainer you are worried about making the best decision for + the project, for the project's users and developers, and for + yourself as a responsible project leader. Turning things over to + an email list will demonstrate your own responsible and + responsive leadership as it tests and serves the interests of + your software's community. + + - - - SCSI FAQ - and - - + + Technical issues is not always good justification + + Especially towards the beginning, you will find that many + changes are difficult to implement, introduce new bugs, or have + other techincal problems. Try to see past these. Especially with + added functionality, good ideas do not always come from good + coders. Technical merit is a valid reason to postpone the + application of a patch but it is not always a good reason to + reject a change outright. Even small changes are worth the + effort of working with the submittor to iron out bugs and + incorporate the change if you thing you think it seems like a + good addition to your project. The effort on your part will work + to make your project a community project and it will pull a new + or less experienced developer onto your project and even teach + them something that might help them in their next patch. + + - - - comp.arch.storage FAQ. - - + + Common courtesy + + It should go without saying but, above all and in all + cases, just be nice. If someone has an idea and cares + about it enough to write some code and submit a patch, they + care, they are motivated, and they are already involved. Your + goal as the maintainer is make sure they submit again. They may + have thrown you a dud this time but next time may be the idea or + feature that revolutionizes your project. + - - + + It is your responsibility to first justify your action to not + incorporate their change clearly and concisely. Then thank + them. Let them know that you a appreciate their help and feel + horrible that you can't incorproate their change. Let them know + that you look forward to their staying involved and you hope + that the next patch or idea meshes better with your project + because you appreciate their work and want to see it in the + project. If you have ever had a patch rejected that put a large + deal of time, thought, and energy into, you remember how it + feels and it feels bad. Keep this in mind when you have to let + someone down. It's never easy but you need to do everything you + have to make it as not-unpleasant as possible. + + + - - - - Mailing Lists - - - disk!information resources!mailing lists - + - - These are low-noise channels mainly for developers. Think twice - before asking questions there as noise delays the development. - Some relevant lists are linux-raid, - linux-scsi and linux-ext2fs. Many - of the most useful mailing lists run on the vger.rutgers.edu server but this is - notoriously overloaded, so try to find a mirror. There are some - lists mirrored at The Redhat - Home Page. Many lists are also accessible at linuxhq, and the - rest of the web site contains useful information as well. - + + Stable and Development Branches - If you want to find out more about the lists available you can send - a message with the line lists to the list server - at majordomo@vger.rutgers.edu. - If you need help on how to use the mail server just send the line - help to the same address. Due to the - popularity of this server it is likely it takes a bit to time before - you get a reply or even get messages after you send a - subscribe command. + The idea of stable and development branches has already been + described briefly in and in + . These alluses attest to the fact + to some of the ways that multiple branches can affect your + software. Branches can let you avoid (to some extent) some of the + problems around rejecting patches (as described in ) by allowing you to temporarily compromise the + stability of your project without affected those users who need + that stability. - There is also a number of other majordomo list servers that can - be of interest such as the EATA driver list - (linux-eata@mail.uni-mainz.de) - and the Intelligent IO list linux-i2o@dpt.com. + The most common way of branching your project is to have one + branch that is stable and one that is development. This is the + model followed by the Linux kernel that is described in . In this model, there is always one + branch that is stable and always one that is in + development. Before any new release, the development branch goes + into a feature freeze where major changes and added + features are rejected or put on hold under the development kernel + is released as the new stable branch and major development begins + again on the development branch. Bug fixes and small changes that + are unlikely to have any large negative reprocussion are + incorporated into the stable branch also to the development + branch. - Mailing lists are in a state of flux but you can find links to a - number of interesting lists from the - Linux Documentation - Homepage. + Linux's model is an extreme one. On many projects, there is no + need to have two versions always available. It may make sense ot + have two versions only near a release. The Debian project has + historically made both a stable and an unstable distribution + available but has expanded to this to include: stable, unstable, + testing, experimental, and (around release time) a frozen + distribution that only incorporates bug fixes during the + transition from unstable to stable. There are few projects whose + size would necessitate a system like Debian but their use of + branches helps demonstrate how they can be used to balance + consitent and effective development with the need to make regular + and useable releases. - - - - - - HOWTO - - - disk!information resources!HOWTOs - - These are intended as the primary starting points to get the - background information as well as show you how to solve a - specific problem. Some relevant HOWTOs are - Bootdisk, - Installation, - SCSI and - UMSDOS. The main site for these is the - LDP archiveat - Metalab (formerly known as Sunsite). + In trying to set up a development tree for yourself, there are + several things that might be useful to keep in mind: - There is a a new HOWTO out that deals with setting up a DPT RAID - system, check out the - DPT RAID - HOWTO homepage. - - - - + - - Local Resources + + Minimize the number of branches + + + Debian may be able to make good use of four or five branches + but it contains gigabytes of software in over 5000 packages + compiled for a 5-6 different architectures. Two is a good + number. Too many branches will confuse your users (I can't + count how many times I had to describe debian's system when it + only had 2 and sometimes 3 branches!), potential developers + and even yourself. Branches can help but they come at a cost + so use them very sparingly. + + + - - disk!information resources!local - + + Make sure that all your different branches are explained + + + As I mentioned in the preceeding paragraph, different branches + will confuse your users. Do everything + you can to avoid this by clearly explaining the different + branches in a promenant page on your website and in a Readme + file in the FTP or HTTP + directory. + - - In most distributions of Linux there is a document directory - installed, have a look in the /usr/doc - directory. where most packages store their main documentation and - README files etc. Also you will here find the HOWTO archive - (/usr/doc/HOWTO) of ready formatted HOWTOs - and also the mini-HOWTO archive - (/usr/doc/HOWTO/mini) of plain text - documents. - + + I might also recommend against a mistake that I think Debian + has made. The terms unstable, + testing, and experimental are + vague and difficult to rank in order of stability (or + instability as the case may be). Try explaining to someone + that stable actually means ultra + stable and that unstable doesn't + actually include any unstable software but is really stable + software that is untested as a distribution. + - - Many of the configuration files mentioned earlier can be found in - the /etc directory. In particular you will - want to work with the /etc/fstab file that - sets up the mounting of partitions and possibly also - /etc/raidtab file that is used for the - md system to set up RAID. - + + If you are going to do branches, especially early on, keep in + mind that people are conditioned to understand the terms + stable and development and you + probaly can't go wrong with this simple and common division of + branches. + + + - - The kernel source in /usr/src/linux is, of - course, the ultimate documentation. In other words, use - the source, Luke. It should also be pointed out that the - kernel comes not only with source code which is even commented - (well, partially at least) but also an informative - /usr/src/linux/Documentation. If you are - about to ask any questions about the kernel you should read this - first, it will save you and many others a lot of time and - possibly embarrassment. - + + Make sure all your branches are always available + + + Like a lot of document, this should probably should go without + saying but experience has taught me that it's not always + obvious to people. It's a good idea to physicall split up + different branches in different directories or directory trees + on your FTP or HTTP + site. Linux accomplishes this by having all the v2.2 and a + v2.3 subdirectory where it is immediately obvious (after you + know their version numbering scheme) which directory is the + most recent stable and the current development + releases. Debian accomplishes this by naming all their + distribution by name and then changing symlinks named + stable, unstable and + frozen to point to which ever distribution (by + name) is in whatever stage. Both methods work and their are + others. In any case, it is important that different branches + are always available, are accessable from consistent + locations, and that different branches are clearly + distinguished from each other so your users know exactly what + they want to be downloading and where to get it. + + + - - Also have a look in your system log file - (/var/log/messages) to see what is going on - and in particular how the booting went if too much scrolled off - your screen. Using tail -f /var/log/messages - in a separate window or screen will give you a continuous update - of what is going on in your system. + - - You can also take advantage of the /proc - file system that is a window into the inner workings of your - system. Use cat rather than - more to view the files as they are reported as - being zero length. Reports are that less works - well here. - - - - - Web Sites - - - disk!information resources!WWW - - - disk!information resources!web pages - - - - There are a huge number of informative web sites available. By - their very nature they change quickly so do not be surprised - if these links become quickly outdated. - - - - A good starting point is of course the - Linux Documentation - Project home page, an information central for - documentation, project pages and much more. - + + + Other Development issues - Please let me know if you have any other leads that can be - of interest. + There are more issues around surrounding interaction with + developers in a free software project that I can touch on in great + detail in a HOWTO of this size. Please don't hesitate to contact + me if you see any major omissions. Other smaller issues that are + worth mentioning are: - - - - - - - - - - - Getting Help - - - (your index root)!assistance, obtaining - - - - In the end you might find yourself unable to solve your problems - and need help from someone else. The most efficient way is either - to ask someone local or in your nearest Linux user group, search - the web for the nearest one. - - - - Another possibility is to ask on Usenet News in one of the many, - many newsgroups available. The problem is that these have such a - high volume and noise (called low signal-to-noise ratio) that your - question can easily fall through unanswered. - - - - No matter where you ask it is important to ask well or you will - not be taken seriously. Saying just my disk - does not work is not going to help you and instead the - noise level is increased even further and if you are lucky someone - will ask you to clarify. - - - - Instead describe your problems in some detail that will enable - people to help you. The problem could lie somewhere you did not - expect. Therefore you are advised to list the following information - about your system: - - - - - - - Hardware - - - - - Processor - - - - DMA - - - - IRQ - - - - Chip set (LX, BX etc) - - - - Bus (ISA, VESA, PCI etc) - - - - - Expansion cards used (Disk controllers, video, IO - etc.) - - - - - - - - - - Software - - - - - - BIOS (On motherboard and possibly SCSI host adapters) - - - - LILO, if used - - - - - Linux kernel version as well as possible modifications - and patches - - - - - Kernel parameters, if any - - - - - Software that shows the error (with version number - or date) - - - - - - - - - - - Peripherals - - - - - - - Type of disk drives with manufacturer name, version and type - - - - - Other relevant peripherals - - - - - - - - - - - Remember that booting text is logged to - /var/log/messages which can answer most of - the questions above. Obviously if the drives fail you might not be - able to get the log saved to disk but you can at least scroll - back up the screen using the SHIFT and - PAGE UP keys. It may also be useful to include - part of this in your request for help but do not go overboard, - keep it brief as a complete log file dumped - to Usenet News is more than a little annoying. - - - - - + + Freezing + + For those projects that choose to adopt a split development model + (), freezing is a concept that is worth + becoming familiar with. + + + Freeze come in two major forms. A feature freeze + is a period when no signifigant functionality is added to a + program. It is a period where established functionality (even + skeletons of barely working functionality) can be improved and + perfected. It is a period where bugs are fixed. This type of + freeze is usually applied some period (a month or two) before a + release. It is easy to push a release back as you wait for + one more feature and a freeze helps to avoid this + situation by drawing the much neede line in the sand. It gives + developers room they need to get a program ready for release. + - + + The second type of freeze is a code freeze which + is much more like a released piece of software. Once a piece of + software has entered a code freeze, all changes to the code are + frowned upon and only changes that fix known bugs are + permitted. This type of freeze usually follows a feature + freeze and directly preceeds a release. Most released + software is in what could be interpreted as a sort of high + levelcode freeze. + - - Concluding Remarks + + Even you do not choose to appoint a release manager (), you will have an easier time + justifying the rejection or postponement of patches ( before a release with a publicly stated + freeze in effect. + + - - (your index root)!conclusion - + + Forking + + Forks are the most extreme interpretation of a branch. A fork is + when a group of developers takes code from a free software + project and actually starts a brand new free software + project. The most famous example of a fork is Emacs and + XEmacs. Both emacsen are based on an almost identical codebase + but for technical, political, and philisophical reasons, + development was split into two projects which now compete with + each other. + - - Just summing up... Also a place for general - recommendations. - + + The short version of the fork section is, don't do + them. Forks force developers to choose one project to + work with, cause nasty political divisions, redundancy of work. + Luckily, usually the threat of the fork is enough to scare the + maintainer or maintainers of a project into changing the way they + run their project to avoid it. + + + In his chapter on The Open Source Process, Karl + Fogel describes how to do a fork if you absolutely must. If you + have determined that is absolutely necessary and that the + differences between you and the people threatening to fork are + absolutely unresolvable, I recommend Fogel's book as a good place + to start. + + + - - - - - - - Questions and Answers - - - (your index root)!FAQ - - - (your index root)!frequently asked questions - - - - Check the newsgroups and try to determine some frequent - problems and cover them here. Again an example from the Multi Disk - HOWTO. - + - - This is just a collection of what I believe are the most common - questions people might have. Give me more feedback and I will turn - this section into a proper FAQ. - + + Maintaining a Project: Interacting with Users + + fswd!users + - - - - Q:How many physical disk drives (spindles) does a Linux system need? - - - - A: Linux can run just fine on one drive (spindle). Having - enough RAM (around 32 MB, and up to 64 MB) to support swapping - is a better price/performance choice than getting a second - disk. (E)IDE disk is usually cheaper (but a little slower) than - SCSI. - - - - - - Q: Are there any disadvantages in this scheme? - - - - A: There is only a minor snag: if even a single partition - overflows the system might stop working properly. The severity - depends of course on what partition is affected. Still this is - not hard to monitor, the command df gives - you a good overview of the situation. Also check the swap - partition(s) using free to make sure you are - not about to run out of virtual memory. - - - - - - Q: OK, so should I split the system into as many partitions as - possible for a single drive? - - - - A: No, there are several disadvantages to that. First of all - maintenance becomes needlessly complex and you gain very little - in this. In fact if your partitions are too big you will seek - across larger areas than needed. This is a balance and - dependent on the number of physical drives you have. - - - - - - - Greg Leblanc: Depending on how big this FAQ gets, perhaps it - would be worthwhile to have, say, the 5 most FAQ, and put the - rest into an external FAQ. Dunno. Comments? - - - (rest deleted.) + If you've worked your way up to here, congratuatlions, you are + nearing the end of this document. This final section touches upon - - - + - - - - Bits and Pieces - - - disk!miscellaneous - - - - This is basically a section where I stuff all the bits I have not - yet decided where should go, yet that I feel is worth knowing - about. It is a kind of transient area. - - - + + Testing and Testers + + - + + + Setting up a Support Infrastructure + + - + - - Examples + + Releasing Your Program + + - - (your index root)!examples - + - - Example designs and sample configuration files and other - relevant details is always handy - + + Announcing Your Project + + - - + @@ -1465,4 +1844,4 @@ sgml-exposed-tags:nil sgml-local-catalogs:nil sgml-local-ecat-files:nil End: ---> +--> \ No newline at end of file