Index: en_US.ISO8859-1/books/dev-model/Makefile =================================================================== --- en_US.ISO8859-1/books/dev-model/Makefile (revision 53567) +++ en_US.ISO8859-1/books/dev-model/Makefile (working copy) @@ -15,10 +15,6 @@ IMAGES_EN= branches.png IMAGES_EN+= freebsd-code-model.png -IMAGES_EN+= hats-overview.png -IMAGES_EN+= maintenance.png -IMAGES_EN+= orghierarchy.png -IMAGES_EN+= orghierarchy2.png IMAGES_EN+= portsstatus.png IMAGES_EN+= proc-add-committer.png IMAGES_EN+= proc-commit.png @@ -25,7 +21,6 @@ IMAGES_EN+= proc-contrib.png IMAGES_EN+= proc-elections.png IMAGES_EN+= proc-pr.png -IMAGES_EN+= proc-releng.png IMAGES_EN+= proc-rm-committer.png DOC_PREFIX?= ${.CURDIR}/../../.. Index: en_US.ISO8859-1/books/dev-model/book.xml =================================================================== --- en_US.ISO8859-1/books/dev-model/book.xml (revision 53567) +++ en_US.ISO8859-1/books/dev-model/book.xml (working copy) @@ -41,6 +41,12 @@ + 1.6 + November, 2019 + Style revisions, accessibility enhancements, + and statistics updates throughout the book. + + 1.5 October, 2014 Remove mention of GNATS which is no longer @@ -289,10 +295,34 @@ -
- The FreeBSD Project's structure - -
+ The FreeBSD Project's structure (in order of descending authority) + + + + + Group + Number of people + + + + + + Core members + 9 + + + + Committers + 269 + + + + Contributors + ~3000 + + + + @@ -306,7 +336,7 @@ The main resource in the FreeBSD community is its developers: the committers and contributors. It is with their contributions that the project can move forward. Regular developers are referred to as contributors. - As by January 1st, 2003, there are an estimated 5500 + As of January 1st, 2003, there are an estimated 5500 contributors on the project. @@ -809,7 +1005,7 @@ well-defined hats, and is the final arbiter of decisions involving which way the project should be heading. - As by July 1st, 2004, core consisted of 9 members. + As of July 1st, 2004, core consisted of 9 members. Elections are held every two years. @@ -862,26 +1058,12 @@ The official hats in the FreeBSD Project are hats that are more or less formalised and mainly administrative roles. They have the authority and responsibility for their area. The following - illustration shows the responsibility lines. After this follows + list shows the responsibility lines and gives a description of each hat, including who it is held by. - -
- Overview of official hats - -
- - - All boxes consist of groups of committers, except for the - dotted boxes where the holders are not necessarily committers. The - flattened circles are sub-projects and consist of both - committers and non-committers of the main project. - - -
Documentation project manager @@ -888,7 +1070,8 @@ architect is responsible for defining and following up documentation goals for the - committers in the Documentation project. + committers in the Documentation project, which they + supervise. @@ -904,7 +1087,7 @@ Postmaster The Postmaster is responsible for mail being correctly - delivered to the committers' email address. He is also + delivered to the committers' email address. They are also responsible for ensuring that the mailing lists work and should take measures against possible disruptions of mail such as having troll-, spam- and virus-filters. @@ -1014,7 +1197,7 @@ The Source Repository Manager is the only one who is allowed to directly modify the repository without using the tool. - It is his/her + It is their responsibility to ensure that technical problems that arise in the repository are resolved quickly. The source repository manager has the authority to back out commits if this is @@ -1114,7 +1297,7 @@ The Bugmeister is responsible for ensuring that the maintenance database is in working order, that the entries - are correctly categorised and that there are no invalid entries. + are correctly categorised and that there are no invalid entries. They supervise bugbusters. Hat currently held by: @@ -1129,13 +1312,14 @@ the donations liaison officer is to match the developers with needs with people or organisations willing to make a - donation. The Donations Liaison Charter is - available - here + donation. Hat held by: the Donations Liaison Office donations@FreeBSD.org. + The + + Donations Liaison Charter.
@@ -1191,12 +1375,12 @@
Mentor - A mentor is a committer who takes it upon him/her to + A mentor is a committer who takes it upon them to introduce a new committer to the project, both in terms of - ensuring the new committers setup is valid, + ensuring the new committer's setup is valid, that the new committer knows the available tools required in - his/her work and that the - new committer knows what is expected of him/her in terms of + their work, and that the + new committer knows what is expected of them in terms of behavior.
@@ -1260,20 +1444,20 @@ - When a contributor is given committer status, he is + When a contributor is given committer status, they are assigned a mentor. The committer who recommended the new committer will, in the general case, take it upon - himself to be the new committers mentor. + themselves to be the new committers mentor. - When a contributor is given his commit bit, a -signed email is sent + When a contributor is given their commit bit, a -signed email is sent from either , - or nik@freebsd.org to both - admins@freebsd.org, the assigned mentor, the new committer and + , or nik@freebsd.org to both + admins@freebsd.org, the assigned mentor, the new committer, and core confirming the approval of a new account. The mentor then - gathers a password line, public key and PGP key from the + gathers a password line, public key, and PGP key from the new committer and sends them to . When the new account is created, the mentor activates the commit bit and guides the new committer through the rest of the initial process. @@ -1281,7 +1465,9 @@
- Process summary: adding a new committer + Process summary: adding a new committer (refer + to paragraph below for a screenreader-friendly + version)
@@ -1289,13 +1475,13 @@ When a contributor sends a piece of code, the receiving committer may choose to recommend that the contributor is - given commit privileges. If he recommends this to core, - they will vote on this recommendation. If they vote in + given commit privileges. If they recommend this to core, + core will vote on this recommendation. If the vote is in favour, a mentor is assigned the new committer and the new - committer has to email his details to the administrators + committer has to email their details to the administrators for an account to be created. After this, the new - committer is all set to make his first commit. By - tradition, this is by adding his name to the committers list. + committer is all set to make their first commit. By + tradition, this is by adding their name to the committers list. @@ -1313,7 +1499,9 @@
- Process summary: removing a committer + Process summary: removing a committer (refer to + paragraph below for a screenreader-friendly + version)
@@ -1322,7 +1510,8 @@ When Core decides to clean up the committers list, they check who has not made a commit for the past 18 months. Committers who have not done so have their commit - bits revoked. + bits revoked and their account removed by the + administrators. @@ -1370,16 +1559,16 @@ frequent processes in the FreeBSD project and will usually happen many times a day. Committing of code can only be done by a committer. Committers commit either code - written by themselves, code submitted to them or code + written by themselves, code submitted to them, or code submitted through a problem report. - When code is written by the developer that is non-trivial, he + When code is written by the developer that is non-trivial, they should seek a code review from the community. This is done by sending mail to the relevant list asking for - review. Before submitting the code for review, he should + review. Before submitting the code for review, they should ensure it compiles correctly with the entire tree and that all relevant tests run. This is called pre-commit test. When contributed code is received, it should be @@ -1409,7 +1598,7 @@ set by the committer. After the number of days the committer chose when setting the MFC have passed, an email will automatically be - sent to the committer reminding him to commit it to the -STABLE + sent to the committer reminding them to commit it to the -STABLE branch (and possibly security branches as well). Only security critical changes should be merged to security branches. @@ -1424,7 +1613,9 @@
- Process summary: A committer commits code + Process summary: A committer commits code (refer + to paragraph below for a screenreader-friendly + version)
@@ -1431,24 +1622,26 @@ When a committer has written a piece of code and - wants to commit it, he first needs to determine if it is + wants to commit it, they first need to determine if it is trivial enough to go in without prior review or if it should first be reviewed by the developer community. If the code is trivial or has been reviewed and the committer is not the - maintainer, he should consult the maintainer before + maintainer, they should consult the maintainer before proceeding. If the code is contributed by an outside vendor, the maintainer should create a patch that is sent back to the - vendor. The code is then committed and the deployed by + vendor. The code is then committed and then deployed by the users. Should they find problems with the code, this will be reported and the committer can go back to writing - a patch. If a vendor is affected, he can choose to + a patch. If a vendor is affected, they can choose to implement or ignore the patch.
- Process summary: A contributor commits code + Process summary: A contributor commits code + (refer to paragraphs below and above for a + screenreader-friendly version)
@@ -1455,7 +1648,7 @@ The difference when a contributor makes a code contribution is - that he submits the code through the Bugzilla + that they submit the code through the Bugzilla interface. This report is picked up by the maintainer who reviews the code and commits it. @@ -1547,7 +1740,9 @@
- Process summary: Core elections + Process summary: Core elections (refer to + paragraph below for a screenreader-friendly + version)
@@ -1554,7 +1749,7 @@ Core announces the election and selects an election - manager. He prepares the elections, and when ready, + manager who prepares the elections, and when ready, candidates can announce their candidacies through submitting their statements. The committers then vote. After the vote is over, the election results are @@ -1607,8 +1802,8 @@ requests by mail, Problem Reports, commercial funding for the development of features, or contributions by the scientific community. The wishes that come within the responsibility of a developer - are given to that developer who prioritises his time between - the request and his wishes. A common way to do this is maintain + are given to that developer who prioritises their time between + the request and their wishes. A common way to do this is maintain a TODO-list maintained by the project. Items that do not come within someone's responsibility are collected on TODO-lists unless someone volunteers to take the responsibility. All @@ -1629,7 +1824,7 @@ As the requests are prioritised by the individual developers on - the basis of doing what they find interesting, necessary or are + the basis of doing what they find interesting, necessary, or are funded to do, there is no overall strategy or prioritisation of what requests to regard as requirements and following up their correct implementation. However, most developers have some @@ -1707,10 +1902,55 @@ -
- Jørgenssen's model for change integration - -
+ Jørgenssen's model for change integration + + + + + Stage + Next if successful + Next if unsuccessful + + + + + code + review + + + + + review + pre-commit test + code + + + + pre-commit test + development release + code + + + + development release + parallel debugging + code + + + + parallel debugging + production release + code + + + + production release + + code + + + + @@ -1788,7 +2028,9 @@
- Process summary: problem reporting + Process summary: problem reporting (refer to + paragraph below for a screenreader-friendly + version)
@@ -1796,8 +2038,8 @@ A problem is reported by the report originator. It is then classified by a bugbuster and handed to the correct - maintainer. He verifies the problem and discusses the - problem with the originator until he has enough + maintainer. They verify the problem and discuss the + problem with the originator until they have enough information to create a working patch. This patch is then committed and the problem report is closed. @@ -1833,7 +2075,7 @@ number of rules that committers should follow. However, it happens that these rules are broken. The following rules exist in order to be able to react to misbehavior. They specify what - actions will result in how long a suspension the committer's + actions will result in how long a suspension of the committer's commit privileges. @@ -1861,7 +2103,7 @@ mailing list. Repeat offenders can, with a 2/3 vote by core, receive harsher penalties, including permanent removal of commit privileges. (However, the latter is always viewed as a last - resort, due to its inherent tendency to create controversy). All + resort, due to its inherent tendency to create controversy.) All suspensions are posted to the developers mailing list, a list available to committers only. @@ -1912,10 +2154,10 @@ be committed to the branch without the release engineers' explicit consent. Code-freeze means no changes to the code (like bugs-fixes) are allowed to be committed without the release - engineers explicit consent. This feature- and code-freeze is + engineers' explicit consent. This feature- and code-freeze is known as stabilising. During the release process, the release engineer has the full authority to revert to older versions of - code and thus "back out" changes should he find that the changes + code and thus "back out" changes should they find that the changes are not suitable to be included in the release. @@ -1962,7 +2204,7 @@ releases are considered release candidates. At the end of the release process, a release is created with the new version number, including binary distributions on web sites and the - creation of a CD-ROM images. However, the release is not + creation of CD-ROM images. However, the release is not considered "really released" until a -signed message stating exactly that, is sent to the mailing list freebsd-announce; anything labelled as a "release" before that may well be in-process and @@ -2024,19 +2266,24 @@ -
- Process summary: release engineering - -
+ + Make release schedule + Feature freeze + Code freeze + Make branch + Release candidate + Stabilize release (loop back to + previous step as many times as necessary; when + release is considered stable, proceed with next + step) + + Build packages + Warn mirrors + Publish release + - - These are the stages in the release engineering - process. Multiple release candidates may be created until - the release is deemed stable enough to be released. - - @@ -2077,7 +2324,7 @@ and editing bug reports. The project uses its web interface to send Problem Reports to the - projects central Bugzilla server. The committers also have web and + project's central Bugzilla server. The committers also have web and command-line clients. @@ -2088,7 +2335,7 @@ Mailman is a program that automates the management of mailing lists. The FreeBSD Project uses it to run 16 general lists, 60 technical lists, 4 limited lists and 5 lists - with CVS commit logs. It is + with SVN commit logs. It is also used for many mailing lists set up and used by other people and projects in the FreeBSD community. General lists are lists for the general public, technical lists are mainly for the @@ -2108,7 +2355,7 @@ using a public key architecture to allow people to digitally sign and/or encrypt information in order to ensure secure communication between two parties. A signature is used when - sending information out many recipients, enabling them to verify + sending information out to many recipients, enabling them to verify that the information has not been tampered with before they received it. In the FreeBSD Project this is the primary means of ensuring that information has been written by the person who @@ -2152,25 +2399,182 @@ A port is a set of meta-data and patches that are needed to fetch, compile and install correctly an external piece of - software on a FreeBSD system. The amount of ports have grown + software on a FreeBSD system. The amount of ports has grown at a tremendous rate, as shown by the following figure.
- Number of ports added between 1996 and 2005 + Number of ports added between 1996 and 2008 + (refer to tables below for a screenreader-friendly + version)
- is taken from - - the FreeBSD web site. It shows the number of ports - available to FreeBSD in the period 1995 to 2005. It looks - like the curve has first grown exponentionally, and then - since the middle of 2001 grown linearly. + + shows the number of ports + available to FreeBSD in the period 1995 to 2008. It looks + like the curve has first grown exponentially, and then + from the middle of 2001 to the middle of 2007 grown + linearly at a rate of about 2000 ports/year, before its + growth rate gets lower. + + Approximate dates each multiple of 1000 ports is reached + + + + + Number of ports + Approximate date + + + + + 1000 + Late 1997 + + + 2000 + Late 1998 + + + 3000 + Early 2000 + + + 4000 + Late 2000 + + + 5000 + Mid 2001 + + + 6000 + 4th quarter of 2001 + + + 7000 + Mid 2002 + + + 8000 + 4th quarter of 2002 + + + 9000 + Mid 2003 + + + 10000 + End of 2003 + + + 11000 + Mid 2004 + + + 12000 + End of 2004 + + + 13000 + Mid 2005 + + + 14000 + Early 2006 + + + 15000 + Mid 2006 + + + 16000 + 3rd quarter 2006 + + + 17000 + 2nd quarter 2007 + + + + + + + Approximate number of ports at the start of each year + + + + + Year + Approximate number of ports + + + + + 1995 + 100 + + + 1996 + 300 + + + 1997 + 700 + + + 1998 + 1200 + + + 1999 + 2000 + + + 2000 + 2900 + + + 2001 + 4300 + + + 2002 + 6200 + + + 2003 + 8100 + + + 2004 + 10050 + + + 2005 + 12100 + + + 2006 + 14000 + + + 2007 + 16200 + + + 2008 + 17900 + + + + + As the external software described by the port often is under @@ -2256,9 +2660,9 @@ - The Documentation project has a primer. This is used both to + The Documentation project has a primer. This is used both to introduce new project members to the standard tools and - syntaxes and acts as a reference when working on the project. + syntaxes and to act as a reference when working on the project. Index: share/images/books/dev-model/portsstatus.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = image/png