Elsevier发表文章要求

Elsevier百科

Our mission:

   Elsevier is an integral partner with the scientific,technical and health communities,delivering superior information products and services that foster communication,build insights,and enable individual and collective advancement in scientific research and health care.
   Elsevier.Building insights.Breaking boundaries.
   爱思唯尔致力于为全球三千多万科学家、研究人员、学生、医学以及信息处理的专业人士提供一流的信息产品和革新性的工具。 我们很荣幸能在全球科技和医学学术团体中扮演一个不可或缺的角色并为这些领域的发展尽绵薄之力,帮助科研人员和专业人士提高生产力和效率,同时不断投入并努力创新来更好地满足全球学术社区的需要。
  Elsevier公司沿用了 Elzevir 书屋的名字,并将 Elzevir 改为更为现代的书写方式Elsevier。数百年沧桑,Elsevier 已从一家小小的致力于传播经典学术的 荷兰书店发展为一个向全球科技和医学学术群体提供超过20,000本的刊物和图书的国际化多媒体出版集团。
   公司标志:爱思唯尔公司的标志为一个长者手执缠绕于一棵大树的藤条。其中长者象征广大的科技工作者,大树象征已经获得的科学知识,而藤条则象征科学知识与科技工作者之间的联系。该标志的意义是爱思唯尔就是那根藤条,她致力于为广大的科技工作者构建通向人类现有科技知识殿堂的桥梁,从而推动科研工作的发展,使象征人类科学知识宝库的参天大树更加枝繁叶茂。
   CEO: Erik Engstrom
   历史:爱思唯尔的出版历史可追溯至1880年
   位置:公司总部位于荷兰阿姆斯特丹,在全球24个国家的70多个办公室中拥有7,000多名员工
   合作对象:同全球学术界的7,000名期刊编辑、70,000名编委会成员、200,000名审稿人和500,000名作者一起紧密协作,每年出 版2,000 多种期刊和2,200种新书
  爱思唯尔的产品与服务包括期刊、图书专著、教科书和参考书的纸版和电子版,出版领域涵盖医学、生命科学、自然科学和社会科学等。爱思唯尔的历史是人类为了实现科学的发展而共同努力的历史的一部分。从 儒勒.凡尔纳(Jules Verne)到 斯蒂芬.霍金(Stephen W. Hawking),许多科学界的传奇人物都曾与爱思唯尔 合作出版,而正是这种卓有成效的合作奠定了科技与医学出版的基础。同样重要的还有那些投身于传播和应用科学知识的有志之士所付出的共同努力,这些人中有:编辑、印刷人员、图书馆员、护士、医生、工程师、信息处理专家和学术出版领域的专业人士。
  爱思唯尔的成功离不开同其他同样出色的科技出版商之间的合作,其中包括 North Holland, Excerpta Medica, Pergamon, Mosby, W.B. Saunders, Churchill Livingstone 和academic Press。这些具有悠久历史的出版商现已成为Elsevier的一部分,而爱思唯尔的创立格言Non Solus(永不孤独)比以往任何时候都显得更为重要。 


发表SCI论文的人,恐怕没有人不知道Elsevier的吧,这个位于荷兰的出版社是世界上最大的科技期刊出版单位了。每年出版2,000 多种期刊和2,200种新书。例如青霉素的发现、伟哥的发明等等重大科学成果的发表,都是在Elsevier出版的。
发表外文和中文不太一样,感觉上外国人屁事挺多的,有些矫情。当然,也可以认为是人家编辑比较认真啦,商业规则很成熟,学术风气也比较正。所以想发表论文还是得按照人家的要求来办。
我想发篇论文,结果发现Elsevier的发表要求还是蛮复杂的。到网上看看有没有大侠翻译出来的中文版,结果没有找到合适的,有的人直接用翻译软件一翻 译就挂到了网上,结果中文都不通顺,这怎么行?看来还是自己动手,丰衣足食吧。花了一天时间,把在Elsevier上提交论文的基本要求翻译了一下。当 然,本着积德行善的宗旨,供自用,也供大家方便。当然,本人英文水平达不到专业级,翻译中难免有些错误,希望大侠给予指正。此外,Elsevier的每个 期刊的要求不太一样,但也是大同小异,使用时需要分辨一下。祝你发表论文顺利。

Ethics in Publishing 
 For information on Ethics in Publishing and Ethical guidelines for journal publication see 2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/publishingethics and 2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/ethicalguidelines.

出版物中的伦理问题:

有关出版中伦理道德的信息参见http://www.elsevier.com/publishingethicshttp://www.elsevier.com/ethicalguidelines中的伦理准则。


  Conflict of interest 
 All authors are requested to disclose any actual or potential conflict of interest including any financial, personal or other relationships with other people or organizations within three years of beginning the submitted work that could inappropriately influence, or be perceived to influence, their work. See also 2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/conflictsofinterest.

利益冲突:

所有的 投稿人 必须 披露 从其交稿前三年中可能产生不良影响的且与其工作相关的现实或潜在的 利益 纠纷 ,包括任何财务,个人或与其他人或其他组织的关系 参见 http://www.elsevier.com/conflictsofinterest


Submission declaration 
Submission of an article implies that the work described has not been published previously (except in the form of an abstract or as part of a published lecture or academic thesis), that it is not under consideration for publication elsewhere, that its publication is approved by all authors and tacitly or explicitly by the responsible authorities where the work was carried out, and that, if accepted, it will not be published elsewhere including electronically in the same form, in English or in any other language, without the written consent of the copyright-holder.

提交声明:

提交一篇文章意味着该文章所述工作尚未发布,(可以以摘要的形式发布,或作为学术演讲的形式发布),而且也没有考虑在其他地方出版。如果该文章被接受,它的出版需要得到所有作者和主管部门的同意。而且除非得到了版权持有人的书面同意,不能以其他形式出版(无论英文或其他语言,纸质还是电子版)。

Copyright 
Upon acceptance of an article, authors will be asked to complete a 'Journal Publishing Agreement' (for more information on this and copyright see 2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/copyright). Acceptance of the agreement will ensure the widest possible dissemination of information. An e-mail will be sent to the corresponding author confirming receipt of the manuscript together with a 'Journal Publishing Agreement' form or a link to the online version of this agreement. 
Subscribers may reproduce tables of contents or prepare lists of articles including abstracts for internal circulation within their institutions. Permission of the Publisher is required for resale or distribution outside the institution and for all other derivative works, including compilations and translations (please consult 2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/permissions). If excerpts from other copyrighted works are included, the author(s) must obtain written permission from the copyright owners and credit the source(s) in the article. Elsevier has preprinted forms for use by authors in these cases: please consult 2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/permissions.

版权:

一旦文章被接受,作者将被要求填写一份'杂志出版协议'(更多信息见http://www.elsevier.com/copyright)。接受该协议将确保该文章能够得到尽可能广泛地传播。一封电子邮件将被发送到通信作者,以确认该手稿被接受,并附带“杂志出版协议”的在线版本的链接。用户可以复制表的内容以及文章准备清单包括摘要,以供单位内部流通所需。如果需要将文章及其衍生品(包括翻译和汇编)转售或在本单位之外发布,必须得到出版商的同意(请咨询http://www.elsevier.com/permissions)。如果文章中包括其他受版权保护的作品,作者必须取得著作权人的书面许可。Elsevier公司已为该情况准备了预先印制的表单,供作者使用。详情请咨询http://www.elsevier.com/permissions。

Retained author rights 
As an author you (or your employer or institution) retain certain rights; for details you are referred to: 2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/authorsrights.

作者保有的权利:

作为作者(或作者的雇主、机构),您将保留一定的权利,详细情况请参见:http://www.elsevier.com/authorsrights。

Role of the funding source 
You are requested to identify who provided financial support for the conduct of the research and/or preparation of the article and to briefly describe the role of the sponsor(s), if any, in study design; in the collection, analysis and interpretation of data; in the writing of the report; and in the decision to submit the paper for publication. If the funding source(s) had no such involvement then this should be stated. Please see 2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/funding.

对资金来源的作用

请确定谁为研究提供金融支持,或为文章的准备工作提供帮助,并简要介绍赞助者在文章撰写工作中的作用,诸如研究方案设计、数据收集、分析和解释,报告的撰写,以及决定文章提交等等。请参阅http://www.elsevier.com/funding。


Language and language services 
Please write your text in good English (American or British usage is accepted, but not a mixture of these). Authors who require information about language editing and copyediting services pre- and post-submission please visit 2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/languageediting or our customer support site at http://epsupport.elsevier.com for more information.

语言和语言服务

请使用良好的英语进行写作(美国式或英国式的英语都可以被接受,但不是两种风格的混合物)。作者如果在提交稿件前后需要语言编辑和审稿服务请咨询http://epsupport.elsevier.com了解更多信息,请访问客户支援网站http://www.elsevier.com/languageediting。


Submission 
Submission to this journal proceeds totally online and you will be guided stepwise through the creation and uploading of your files. The system automatically converts source files to a single PDF file of the article, which is used in the peer-review process. Please note that even though manuscript source files are converted to PDF files at submission for the review process, these source files are needed for further processing after acceptance. All correspondence, including notification of the Editor's decision and requests for revision, takes place by e-mail removing the need for a paper trail.
稿件提交:

稿件的提交完全通过网络提交,您将得到逐步的引导并建立和上传您的文件。该系统将源文件自动转换为一个PDF格式的文件,该文件将用在同行审评过程中。请注意,即使稿件的源文件在提交审查的过程中被转换为PDF格式的文件,这些文件在被接受后仍需要作进一步处理。所有的联系,包括通知编辑的决定,关于修改的要求,都通过电子邮件来进行,这样省去了纸张的传递和处理。


Submit your article 
Please submit your article via 2010年07月21日 - woodncy - woodncy 的博客 http://ees.elsevier.com/ymssp/ 

提交您的文章:

请通过以下网址进行稿件提交:http://ees.elsevier.com/ymssp/ 

Referees 
Please submit, with the manuscript, the names, addresses and e-mail addresses of 3 potential referees. Note that the editor retains the sole right to decide whether or not the suggested reviewers are used.

审稿人:

请随稿件提交三个推荐审稿人名单,包括他们的名字,地址和电子邮件地址。请注意,编辑保留是否采用所建议的审稿人的权利。

Addtional Information 
Editorial process: 
The Editor is responsible for journal policy, in consultation with the members of the Editorial Board. Each paper submitted for publication will be normally subject to review and criticism by two informed, independent, anonymous referees, and authors will be provided with copies of these criticisms so that they can make revisions and improvements to their manuscripts before publication. Every effort will be made by the Editor and publishers to ensure prompt publication.

编辑过程:

编辑为刊物的取稿政策负责,与编辑委员会的成员进行咨询。通常每篇文章将受到两名独立的匿名审稿人的审查和评论,作者将收到这些评论的副本,使作者能够在出版前修订和改善他们的手稿。编辑和出版者将尽一切努力以确保文章的及时出版。


准备工作


Types of Paper 
Original research papers, state-of-the-art reviews, short communications, letters for quick publication (maximum length two pages), letters to the editor, news items, 'work in progress' (maximum length two pages), calendar inserts

论文的种类:

包括原始性研究论文,当前技术综述,短通讯,快速出版的信件(最多两页),给编辑的信,新闻,'工作进展'(最大长度2页),calendar inserts(这个calendar inserts不知道是什么意思,请大侠告诉我)。

Use of wordprocessing software 
It is important that the file be saved in the native format of the wordprocessor used. The text should be in single-column format. Keep the layout of the text as simple as possible. Most formatting codes will be removed and replaced on processing the article. In particular, do not use the wordprocessor's options to justify text or to hyphenate words. However, do use bold face, italics, subscripts, superscripts etc. Do not embed "graphically designed" equations or tables, but prepare these using the wordprocessor's facility. When preparing tables, if you are using a table grid, use only one grid for each individual table and not a grid for each row. If no grid is used, use tabs, not spaces, to align columns. The electronic text should be prepared in a way very similar to that of conventional manuscripts (see also the Guide to Publishing with Elsevier: 2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/guidepublication). Do not import the figures into the text file but, instead, indicate their approximate locations directly in the electronic text and on the manuscript. See also the section on Electronic illustrations. 
To avoid unnecessary errors you are strongly advised to use the "spell-check" and "grammar-check" functions of your wordprocessor

文字处理软件的使用:

使用文字处理软件时必须将文件保存问该软件自带格式。文本应为单栏格式。文本布局尽可能简单。在处理文章时,大多数处理软件的格式代码将被删除或被取代。不要使用文字处理软件的自带选项来调整文本或者断字功能(个人理解,就是对齐和换行的时候的设定问题)。不过,可以使用粗体,斜体,下标,上标等字体,不要嵌入“图形设计”方程或表格(个人理解就是不要把公式和表格做成图片格式放到文本中),而是使用文字处理软件的自带功能(诸如表格功能和公式编辑器)。当制表时,不要画竖线,每列只有一个横线隔断(个人理解就是我们常用的三横线表格)。如果没有使用网格,使用Tab而不是空格来对齐列。电子文本应准备的方式非常类似于传统的手稿(参见Elsevier:http://www.elsevier.com/guidepublication出版指南)。不要将图片导入到文本文件中,而是在文本中标明它的大致位置,参见电子插图部分的说明。为了避免文字和语法错误,强烈建议你使用文字处理软件的“拼写检查”和“语法检查”功能,以避免不必要的错误。.

Article structure 
Subdivision - numbered sections 
Divide your article into clearly defined and numbered sections. Subsections should be numbered 1.1 (then 1.1.1, 1.1.2, ...), 1.2, etc. (the abstract is not included in section numbering). Use this numbering also for internal cross-referencing: do not just refer to "the text". Any subsection may be given a brief heading. Each heading should appear on its own separate line.
文章的结构:

细分 - 请将你的文章划分成明确界定的几个部分并进行编号。主要部分的下层编号为1.1(其下分为1.1.1,1.1.2,...), 1.2等(摘要不编号)。文章内部引用时也采用这个编号。每个部分要给一个简短的标题。每个标题应出现在单独的一行。

以下是文章中应该包括哪些部分:
Introduction 
State the objectives of the work and provide an adequate background, avoiding a detailed literature survey or a summary of the results.

介绍:

介绍工作的目的和研究背景,不要写成文献综述或者总结。

Material and methods 
Provide sufficient detail to allow the work to be reproduced. Methods already published should be indicated by a reference: only relevant modifications should be described.
材料和方法:

提供足够的研究细节,使该工作可以被别人重复。已经出版的方法应加上参考标注:相关的修改,应加以说明。


Theory/calculation 
A Theory section should extend, not repeat, the background to the article already dealt with in the Introduction and lay the foundation for further work. In contrast, a Calculation section represents a practical development from a theoretical basis.

理论/计算:

理论部分应该为对已介绍的其他文章中理论进行进一步延伸和发展,而不是重复。并为要开展的工作奠定理论基础。计算部分为根据理论依据进行的实际发展。

Results 
Results should be clear and concise.

结果:

结果应该简明扼要。

Discussion 
This should explore the significance of the results of the work, not repeat them. A combined Results and Discussion section is often appropriate. Avoid extensive citations and discussion of published literature.

讨论:

应该探讨的工作结果的重要性,而不是讲述工作的结果。通常可以将结果和讨论部分合并。避免就已引用和发表的文献进行讨论。

Conclusions 
The main conclusions of the study may be presented in a short Conclusions section, which may stand alone or form a subsection of a Discussion or Results and Discussion section.
结论:

结论部分应该将研究的主要结论进行展示,该部分可以单独为文章的一个部分,也可以和讨论及结果部分合并。


Appendices 
If there is more than one appendix, they should be identified as A, B, etc. Formulae and equations in appendices should be given separate numbering: Eq. (A.1), Eq. (A.2), etc.; in a subsequent appendix, Eq. (B.1) and so on.

附录:

如果有一个以上的附件,应标识为A,B,...以此类推。附录中的公式和方程应单独编号:如Eq. (A.1), Eq. (A.2), 以此类推。


Essential title page information 
? Title. Concise and informative. Titles are often used in information-retrieval systems. Avoid abbreviations and formulae where possible.
? Author names and affiliations. Where the family name may be ambiguous (e.g., a double name), please indicate this clearly. Present the authors' affiliation addresses (where the actual work was done) below the names. Indicate all affiliations with a lower-case superscript letter immediately after the author's name and in front of the appropriate address. Provide the full postal address of each affiliation, including the country name, and, if available, the e-mail address of each author.
? Corresponding author. Clearly indicate who will handle correspondence at all stages of refereeing and publication, also post-publication. Ensure that telephone and fax numbers (with country and area code) are provided in addition to the e-mail address and the complete postal address. 
? Present/permanent address. If an author has moved since the work described in the article was done, or was visiting at the time, a "Present address" (or "Permanent address") may be indicated as a footnote to that author's name. The address at which the author actually did the work must be retained as the main, affiliation address. Superscript Arabic numerals are used for such footnotes.

基本信息:

标题:简明扼要。标题通常用于信息检索系统。在标题中应该尽可能避免缩写和公式。

作者姓名和联系方式:如果作者的姓是模糊的(例如,双姓),请注明清楚(老外就他妈的事多,很多外国人的姓有两个,甚至多个,大概是几个家族联姻造成的结果,为了防止歧义,需要进行标注。大概和我们国家的张曹氏,王李氏类似吧)。提交作者的单位地址(正在工作的那个单位)。如果几个作者的单位不同,在作者的名字后加一个小写的字母进行分类标识,并标在相应的单位地址的前面也写上这个小写的字母。提供完整的邮政地址,包括国家名称,如果有的话,提供每个作者的电子邮件地址。

通讯作者:标明哪位作者将处理出版过程中的各项任务。除了电子邮件地址和邮政地址,还要确保提供电话和传真号码,附带国家和地区代码。

现在/永久地址:如果作者完成了论文中所述研究工作后跳槽了,或者是外出访问,那么应该在作者的名字后脚注上作者的现在地址。作者完成论文所述工作的那个单位必须保留为主体和联系地址。这种脚注用阿拉伯数字进行标识。

Abstract 
A concise and factual abstract is required. The abstract should state briefly the purpose of the research, the principal results and major conclusions. An abstract is often presented separately from the article, so it must be able to stand alone. For this reason, References should be avoided, but if essential, then cite the author(s) and year(s). Also, non-standard or uncommon abbreviations should be avoided, but if essential they must be defined at their first mention in the abstract itself.

摘要:

摘要必须简明扼要。摘要应当简要说明研究的目的,主要成果和重要结论。摘要往往作为文章一个单独部分,所以它必须能够独立。基于这个原因,摘要中应该避免出现引用文献,但是如果必要,也可以引用文献作者和时间。此外,非标准或特殊缩写也应该避免,但是如果必要,缩写必须在文章中的第一次提到时给出定义。


Graphical abstract 
A Graphical abstract is optional and should summarize the contents of the paper in a concise, pictorial form designed to capture the attention of a wide readership online. Authors must provide images that clearly represent the work described in the paper. Graphical abstracts should be submitted as a separate file in the online submission system. Maximum image size: 400 × 600 pixels (h × w, recommended size 200 × 500 pixels). Preferred file types: TIFF, EPS, PDF or MS Office files. See 2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/graphicalabstracts for examples.

图片摘要:

图片摘要是可选的,应能够简要概括文章的内容,以吸引大量读者在线关注。作者必须提供能够清晰描述文章中的工作的图片。图片摘要应当作为独立文件在网上提交系统提交。最大图像尺寸:400 × 600像素(高×宽,建议大小200 × 500像素)。首选文件类型:TIFF格式,EPS,PDF和MS Office文件。参见http://www.elsevier.com/graphicalabstracts。

Research highlights 
Research highlights are a short collection of bullet points that convey the core findings of the article. Research highlights are optional and should be submitted in a separate file in the online submission system. Please use 'Research highlights' in the file name and include 3 to 5 bullet points (maximum 85 characters per bullet point including spaces). See 2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/researchhighlights for examples.
研究重点:

研究重点是文章主要发现和成果的集合,传达文章的核心结论。研究重点是可选项,应当作为单独文件在网上提交系统提交。请使用“Research highlights”作为文件名,包括3至5个要点(最多85个字符,包括空格)。例子参见http://www.elsevier.com/researchhighlights。


Keywords 
Immediately after the abstract, provide a maximum of 6 keywords, using American spelling and avoiding general and plural terms and multiple concepts (avoid, for example, "and", "of"). Be sparing with abbreviations: only abbreviations firmly established in the field may be eligible. These keywords will be used for indexing purposes.
关键词:

关键词放在摘要的后面,最多提供6个关键字,使用美式拼写、避免一般性的术语以及歧义(例如,应避免“and,“of)。只有当一个缩写在该领域被广泛接受时,才可以作为关键词。关键词主要用于检索目的。


Abbreviations 
Define abbreviations that are not standard in this field in a footnote to be placed on the first page of the article. Such abbreviations that are unavoidable in the abstract must be defined at their first mention there, as well as in the footnote. Ensure consistency of abbreviations throughout the article.
缩写:

如果一个缩写不是这个领域的标准,那么在文章的第一页放置一个脚注。如果摘要中必须要用到一个缩写,必须在该缩写第一次被提到时进行定义。确保缩写在整个文章中的一致性。
Acknowledgements 
Collate acknowledgements in a separate section at the end of the article before the references and do not, therefore, include them on the title page, as a footnote to the title or otherwise. List here those individuals who provided help during the research (e.g., providing language help, writing assistance or proof reading the article, etc.).

致谢:

致谢作为一个单独的部分放置在参考文献的前面,而不是放在第一页中,作为标题或以其他方式脚注。在致谢中列出在研究过程中提供帮助的人或单位(如提供语言帮助,写作援助或校对文章等)。

Units 
Follow internationally accepted rules and conventions: use the international system of units (SI). If other units are mentioned, please give their equivalent in SI.
单位:

按照国际公认的规则和惯例:使用国际单位制(SI)。如果提到其他单位,请给出他们和SI之间的当量关系。


Nomenclature 
Follow internationally accepted rules and conventions: use the international system of units (SI). If other quantities are mentioned, give their equivalent in SI. You are urged to consult IUPAC: Nomenclature of Organic Chemistry: 2010年07月21日 - woodncy - woodncy 的博客 http://www.iupac.org/ for further information.
All the 'parameters' cited in the text should be listed, in 'alphabetical order', in a seperate nomenckature section at the beginning of the paper, with their definitions and units. 'Greek symbols', 'subscripts' and 'subscripters' should be sepertly identified. Only 'ISO symbols'

命名:

遵循国际公认的规则和惯例:使用国际单位制(SI)。如果提到其他单位,请给出他们和SI之间的当量关系。您可以咨询IUPAC有关有机化学命名http://www.iupac.org/。所有文章中使用的'参数'应该按照'字母顺序,在文章开头的一个单独的部分中列写出来,包括这些参数的定义和单位。'希腊符号','下标''应分别定义。只使用ISO符号。

Math formulae 

Present simple formulae in the line of normal text where possible and use the solidus (/) instead of a horizontal line for small fractional terms, e.g., X/Y. In principle, variables are to be presented in italics. Powers of e are often more conveniently denoted by exp. Number consecutively any equations that have to be displayed separately from the text (if referred to explicitly in the text).

数学公式:

尽可能在正常文本中展示公式,并使用斜线/,而不是一个横线,来表示除法,如X /Y。原则上,变量应该采用斜体。指数e应采用exp表示。如果有的公式不能当成文本放置在文字中,应该作为单独一行列写,并进行编号。

Footnotes 

Footnotes should be used sparingly. Number them consecutively throughout the article, using superscript Arabic numbers. Many wordprocessors build footnotes into the text, and this feature may be used. Should this not be the case, indicate the position of footnotes in the text and present the footnotes themselves separately at the end of the article. Do not include footnotes in the Reference list. 
Table footnotes 
Indicate each footnote in a table with a superscript lowercase letter.

脚注:

脚注应谨慎使用。整篇文章的每一页使用大写阿拉伯数字连续进行标注,许多文字处理软件的脚注也是文本格式,这功能可以使用。(大概的意思是每页都要有页码吧,放在每页居中的下方)。如果不是这种情况,在文本中表明脚注的位置,在文章结尾处将脚注分别列写出来。参考文献中不要脚注。

表格中的脚注,每一个表的脚注上标有一个小写字母。

Artwork 
Electronic artwork 
General points 
? Make sure you use uniform lettering and sizing of your original artwork. 
? Save text in illustrations as "graphics" or enclose the font. 
? Only use the following fonts in your illustrations: Arial, Courier, Times, Symbol. 
? Number the illustrations according to their sequence in the text. 
? Use a logical naming convention for your artwork files. 
? Provide captions to illustrations separately. 
? Produce images near to the desired size of the printed version. 
? Submit each figure as a separate file. 
A detailed guide on electronic artwork is available on our website: 
2010年07月21日 - woodncy - woodncy 的博客 http://www.elsevier.com/artworkinstructions 
You are urged to visit this site; some excerpts from the detailed information are given here.

艺术作品(个人认为主要就是文章中的插图):

?请确保您的艺术作品使用统一的字体和大小。

?图片中的文字和图片一起存成图片格式。

在你的插图使用只适用以下字体:Arial,Courier, Times, Symbol.。

?根据插图其在文章中出现的序列进行编号。

?为您的插图文件给出一个符合逻辑的命名。

?为插图提供一个标题。

?插图的大小要接近的印刷版本所需要求。

?每个插图作为一个单独的文件进行提交

。网站上有一个详细的电子艺术作品指南:http://www.elsevier.com/artworkinstructions


Formats 
Regardless of the application used, when your electronic artwork is finalised, please "save as" or convert the images to one of the following formats (note the resolution requirements for line drawings, halftones, and line/halftone combinations given below): 
EPS: Vector drawings. Embed the font or save the text as "graphics". 
TIFF: color or grayscale photographs (halftones): always use a minimum of 300 dpi. 
TIFF: Bitmapped line drawings: use a minimum of 1000 dpi. 
TIFF: Combinations bitmapped line/half-tone (color or grayscale): a minimum of 500 dpi is required. 
DOC, XLS or PPT: If your electronic artwork is created in any of these Microsoft Office applications please supply "as is". 
Please do not: 
? Supply embedded graphics in your wordprocessor (spreadsheet, presentation) document; 
? Supply files that are optimised for screen use (like GIF, BMP, PICT, WPG); the resolution is too low; 
? Supply files that are too low in resolution; 
? Submit graphics that are disproportionately large for the content.

l 无论使用什么应用程序,当您的电子艺术品完成后,请“另存为”或转换图像为下列格式之一:

EPS:矢量图。嵌入的文字保存为“图形”。

l TIFF格式:彩色或灰度照片(半色调):分辨率要求最低300 dpi。

l TIFF格式:位图:分辨率要求最低1000 dpi。

l TIFF格式:点阵组合线/半色调(彩色或灰阶):分辨率要求最低500 dpi。

l DOC,XLS或PPT:如果您的电子艺术品是由Microsoft Office应用程序创建的,请直接存为该文件格式。

请不要进行如下操作:

l 在文字处理软件的文件中嵌入图片;

l 提供那些基于屏幕显示进行优化的文件如GIF,BMP,PICT,WPG,因为这些文件的分辨率太低

l 文件的分辨率太低

l 提交的图形大的不成比例。


Figure captions 
Ensure that each illustration has a caption. Supply captions separately, not attached to the figure. A caption should comprise a brief title (not on the figure itself) and a description of the illustration. Keep text in the illustrations themselves to a minimum but explain all symbols and abbreviations used.

图片标题:

确保每个插图有一个标题。标题和图片分开,而不是将标题放到图片中。标题应包括一个简短精确的名称以及图片的描述。将标题中的文字保持在最低限度,但需要解释标题中的所有的符号和缩写。


Tables 
Number tables consecutively in accordance with their appearance in the text. Place footnotes to tables below the table body and indicate them with superscript lowercase letters. Avoid vertical rules. Be sparing in the use of tables and ensure that the data presented in tables do not duplicate results described elsewhere in the article.

表格:

按照表格在文章中出现的次序进行编号。表格下面用小写字母加脚注对表格进行说明。避免文字垂直排列。尽量少用表格,并确保在表内显示的数据不会在文章中其他内容中被重复展示。

References 

Citation in text 
Please ensure that every reference cited in the text is also present in the reference list (and vice versa). Any references cited in the abstract must be given in full. Unpublished results and personal communications are not recommended in the reference list, but may be mentioned in the text. If these references are included in the reference list they should follow the standard reference style of the journal and should include a substitution of the publication date with either "Unpublished results" or "Personal communication" Citation of a reference as "in press" implies that the item has been accepted for publication.

参考文献:

在文中引用文章必须在文中进行标注,并在参考文献中列写出来。摘要中的参考文献必须全部列写出来。未公布的研究成果及个人通讯不建议在参考文献中列写出来,但可以在文中提及。参考文献应该遵循该刊物标准参考文献的风格,对尚未出版的文章或“个人通信”作为参考文献,标上“in press”意味着该文章已被接受等待发表。


Reference style 
Text: Indicate references by number(s) in square brackets in line with the text. The actual authors can be referred to, but the reference number(s) must always be given. 
Example: "..... as demonstrated [3,6]. Barnaby and Jones [8] obtained a different result ...." 
List: Number the references (numbers in square brackets) in the list in the order in which they appear in the text. 
Examples: 
Reference to a journal publication: 
[1] J. van der Geer, J.A.J. Hanraads, R.A. Lupton, The art of writing a scientific article, J. Sci. Commun. 163 (2000) 51–59. 
Reference to a book: 
[2] W. Strunk Jr., E.B. White, The Elements of Style, third ed., Macmillan, New York, 1979. 
Reference to a chapter in an edited book: 
[3] G.R. Mettam, L.B. Adams, How to prepare an electronic version of your article, in: B.S. Jones, R.Z. Smith (Eds.), Introduction to the Electronic Age, E-Publishing Inc., New York, 1999, pp. 281–304.
参考文献的样式:

注明引用的号码(与文章中方括号中的编号相对应)。实际作者可以在文章中提及,参考号码必须给出。例如:"..... as demonstrated [3,6]. Barnaby and Jones [8] obtained a different result ...." 
按照参考文献在文章中出现的顺序进行编号和排序。
例子:
引用期刊中的文章:
[1] J. van der Geer, J.A.J. Hanraads, R.A. Lupton, The art of writing a scientific article, J. Sci. Commun. 163 (2000) 51–59. 
引用书中的内容:
[2] W. Strunk Jr., E.B. White, The Elements of Style, third ed., Macmillan, New York, 1979. 
引用书中的某一章节:
[3] G.R. Mettam, L.B. Adams, How to prepare an electronic version of your article, in: B.S. Jones, R.Z. Smith (Eds.), Introduction to the Electronic Age, E-Publishing Inc., New York, 1999, pp. 281–304.

Submission checklist 
It is hoped that this list will be useful during the final checking of an article prior to sending it to the journal's Editor for review. Please consult this Guide for Authors for further details of any item.

提交的清单:

希望这个清单将是有益的,在该文章被投稿之前进行最后的检查。你可以咨询指南投稿的任何细节。 
Ensure that the following items are present: 
One Author designated as corresponding Author: 
? E-mail address 
? Full postal address 
? Telephone and fax numbers 
All necessary files have been uploaded 
? Keywords 
? All figure captions 
? All tables (including title, description, footnotes) 
Further considerations 
? Manuscript has been "spellchecked" and "grammar-checked" 
? References are in the correct format for this journal 
? All references mentioned in the Reference list are cited in the text, and vice versa 
? Permission has been obtained for use of copyrighted material from other sources (including the Web) 
? Color figures are clearly marked as being intended for color reproduction on the Web (free of charge) and in print or to be reproduced in color on the Web (free of charge) and in black-and-white in print 
? If only color on the Web is required, black and white versions of the figures are also supplied for printing purposes 
For any further information please visit our customer support site at http://epsupport.elsevier.com.

确保以下内容存在:

一个作者指定为通讯作者:

?E - mail地址

?完整的邮政地址

?电话和传真号码

?所有必需的文件已被上传

?关键词

?所有插图名称

?所有表(包括名称,描述,脚注)

进一步考虑

?手稿已被“拼写检查”和“语法检查”

?参考文献符合本期刊的正确格式

?在参考文献中中列写了文本中引用的所有文献,反之亦然

?已获得许可版权使用从其他来源(包括网上资料)

?彩色图片被表明被用于在网上(免费),并以在黑白格式印刷

请访问我们的客户支持站点http://epsupport.elsevier.com
  • 0
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
A project model for the FreeBSD Project Niklas Saers Copyright © 2002-2005 Niklas Saers [ Split HTML / Single HTML ] Table of Contents Foreword 1 Overview 2 Definitions 2.1. Activity 2.2. Process 2.3. Hat 2.4. Outcome 2.5. FreeBSD 3 Organisational structure 4 Methodology model 4.1. Development model 4.2. Release branches 4.3. Model summary 5 Hats 5.1. General Hats 5.1.1. Contributor 5.1.2. Committer 5.1.3. Core Team 5.1.4. Maintainership 5.2. Official Hats 5.2.1. Documentation project manager 5.2.2. CVSup Mirror Site Coordinator 5.2.3. Internationalisation 5.2.4. Postmaster 5.2.5. Quality Assurance 5.2.6. Release Coordination 5.2.7. Public Relations & Corporate Liaison 5.2.8. Security Officer 5.2.9. Source Repository Manager 5.2.10. Election Manager 5.2.11. Web site Management 5.2.12. Ports Manager 5.2.13. Standards 5.2.14. Core Secretary 5.2.15. GNATS Administrator 5.2.16. Bugmeister 5.2.17. Donations Liaison Officer 5.2.18. Admin 5.3. Process dependent hats 5.3.1. Report originator 5.3.2. Bugbuster 5.3.3. Mentor 5.3.4. Vendor 5.3.5. Reviewers 5.3.6. CVSup Mirror Site Admin 6 Processes 6.1. Adding new and removing old committers 6.2. Adding/Removing an official CVSup Mirror 6.3. Committing code 6.4. Core election 6.5. Development of new features 6.6. Maintenance 6.7. Problem reporting 6.8. Reacting to misbehaviour 6.9. Release engineering 7 Tools 7.1. Concurrent Versions System (CVS) 7.2. CVSup 7.3. GNATS 7.4. Mailman 7.5. Perforce 7.6. Pretty Good Privacy 7.7. Secure Shell 8 Sub-projects 8.1. The Ports Subproject 8.2. The FreeBSD Documentation Project References List of Figures 3-1. The FreeBSD Project's structure 3-2. The FreeBSD Project's structure with committers in categories 4-1. Jørgenssen's model for change integration 4-2. The FreeBSD release tree 4-3. The overall development model 5-1. Overview of official hats 6-1. Process summary: adding a new committer 6-2. Process summary: removing a committer 6-3. Process summary: adding a CVSup mirror 6-4. Process summary: A committer commits code 6-5. Process summary: A contributor commits code 6-6. Process summary: Core elections 6-7. Jørgenssen's model for change integration 6-8. Process summary: problem reporting 6-9. Process summary: release engineering 8-1. Number of ports added between 1996 and 2005 Foreword Up until now, the FreeBSD project has released a number of described techniques to do different parts of work. However, a project model summarising how the project is structured is needed because of the increasing amount of project members. [1] This paper will provide such a project model and is donated to the FreeBSD Documentation project where it can evolve together with the project so that it can at any point in time reflect the way the project works. It is based on [Saers, 2003]. I would like to thank the following people for taking the time to explain things that were unclear to me and for proofreading the document. Andrey A. Chernov <[email protected]> Bruce A. Mah <[email protected]> Dag-Erling Smørgrav <[email protected]> Giorgos Keramidas<[email protected]> Ingvil Hovig <[email protected]> Jesper Holck<[email protected]> John Baldwin <[email protected]> John Polstra <[email protected]> Kirk McKusick <[email protected]> Mark Linimon <[email protected]> Marleen Devos Niels Jørgenssen<[email protected]> Nik Clayton <[email protected]> Poul-Henning Kamp <[email protected]> Simon L. Nielsen <[email protected]> Chapter 1 Overview A project model is a means to reduce the communications overhead in a project. As shown by [Brooks, 1995], increasing the number of project participants increases the communication in the project exponentionally. FreeBSD has during the past few year increased both its mass of active users and committers, and the communication in the project has risen accordingly. This project model will serve to reduce this overhead by providing an up-to-date description of the project. During the Core elections in 2002, Mark Murray stated “I am opposed to a long rule-book, as that satisfies lawyer-tendencies, and is counter to the technocentricity that the project so badly needs.” [FreeBSD, 2002B]. This project model is not meant to be a tool to justify creating impositions for developers, but as a tool to facilitate coordination. It is meant as a description of the project, with an overview of how the different processes are executed. It is an introduction to how the FreeBSD project works. The FreeBSD project model will be described as of July 1st, 2004. It is based on the Niels Jørgensen's paper [Jørgensen, 2001], FreeBSD's official documents, discussions on FreeBSD mailing lists and interviews with developers. After providing definitions of terms used, this document will outline the organisational structure (including role descriptions and communication lines), discuss the methodology model and after presenting the tools used for process control, it will present the defined processes. Finally it will outline major sub-projects of the FreeBSD project. [FreeBSD, 2002A, Section 1.2 and 1.3] give the vision and the architectural guidelines for the project. The vision is “To produce the best UNIX-like operating system package possible, with due respect to the original software tools ideology as well as usability, performance and stability.” The architectural guidelines help determine whether a problem that someone wants to be solved is within the scope of the project Chapter 2 Definitions 2.1. Activity An “activity” is an element of work performed during the course of a project [PMI, 2000]. It has an output and leads towards an outcome. Such an output can either be an input to another activity or a part of the process' delivery. 2.2. Process A “process” is a series of activities that lead towards a particular outcome. A process can consist of one or more sub-processes. An example of a process is software design. 2.3. Hat A “hat” is synonymous with role. A hat has certain responsibilities in a process and for the process outcome. The hat executes activities. It is well defined what issues the hat should be contacted about by the project members and people outside the project. 2.4. Outcome An “outcome” is the final output of the process. This is synonymous with deliverable, that is defined as “any measurable, tangible, verifiable outcome, result or item that must be produced to complete a project or part of a project. Often used more narrowly in reference to an external deliverable, which is a deliverable that is subject to approval by the project sponsor or customer” by [PMI, 2000]. Examples of outcomes are a piece of software, a decision made or a report written. 2.5. FreeBSD When saying “FreeBSD” we will mean the BSD derivative UNIX-like operating system FreeBSD, whereas when saying “the FreeBSD Project” we will mean the project organisation. Chapter 3 Organisational structure While no-one takes ownership of FreeBSD, the FreeBSD organisation is divided into core, committers and contributors and is part of the FreeBSD community that lives around it. Figure 3-1. The FreeBSD Project's structure Number of committers has been determined by going through CVS logs from January 1st, 2004 to December 31st, 2004 and contributors by going through the list of contributions and problem reports. 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 contributors on the project. Committers are developers with the privilege of being able to commit changes. These are usually the most active developers who are willing to spend their time not only integrating their own code but integrating code submitted by the developers who do not have this privilege. They are also the developers who elect the core team, and they have access to closed discussions. The project can be grouped into four distinct separate parts, and most developers will focus their involvement in one part of FreeBSD. The four parts are kernel development, userland development, ports and documentation. When referring to the base system, both kernel and userland is meant. This split changes our triangle to look like this: Figure 3-2. The FreeBSD Project's structure with committers in categories Number of committers per area has been determined by going through CVS logs from January 1st, 2004 to December 31st, 2004. Note that many committers work in multiple areas, making the total number higher than the real number of committers. The total number of committers at that time was 269. Committers fall into three groups: committers who are only concerned with one area of the project (for instance file systems), committers who are involved only with one sub-project and committers who commit to different parts of the code, including sub-projects. Because some committers work on different parts, the total number in the committers section of the triangle is higher than in the above triangle. The kernel is the main building block of FreeBSD. While the userland applications are protected against faults in other userland applications, the entire system is vulnerable to errors in the kernel. This, combined with the vast amount of dependencies in the kernel and that it is not easy to see all the consequences of a kernel change, demands developers with a relative full understanding of the kernel. Multiple development efforts in the kernel also requires a closer coordination than userland applications do. The core utilities, known as userland, provide the interface that identifies FreeBSD, both user interface, shared libraries and external interfaces to connecting clients. Currently, 162 people are involved in userland development and maintenance, many being maintainers for their own part of the code. Maintainership will be discussed in the Maintainership section. Documentation is handled by The FreeBSD Documentation Project and includes all documents surrounding the FreeBSD project, including the web pages. There were during 2004 101 people making commits to the FreeBSD Documentation Project. Ports is the collection of meta-data that is needed to make software packages build correctly on FreeBSD. An example of a port is the port for the web-browser Mozilla. It contains information about where to fetch the source, what patches to apply and how, and how the package should be installed on the system. This allows automated tools to fetch, build and install the package. As of this writing, there are more than 12600 ports available. [2] , ranging from web servers to games, programming languages and most of the application types that are in use on modern computers. Ports will be discussed further in the section The Ports Subproject. Chapter 4 Methodology model 4.1. Development model There is no defined model for how people write code in FreeBSD. However, Niels Jørgenssen has suggested a model of how written code is integrated into the project. Figure 4-1. Jørgenssen's model for change integration The “development release” is the FreeBSD-CURRENT ("-CURRENT") branch and the “production release” is the FreeBSD-STABLE branch ("-STABLE") [Jørgensen, 2001]. This is a model for one change, and shows that after coding, developers seek community review and try integrating it with their own systems. After integrating the change into the development release, called FreeBSD-CURRENT, it is tested by many users and developers in the FreeBSD community. After it has gone through enough testing, it is merged into the production release, called FreeBSD-STABLE. Unless each stage is finished successfully, the developer needs to go back and make modifications in the code and restart the process. To integrate a change with either -CURRENT or -STABLE is called making a commit. Jørgensen found that most FreeBSD developers work individually, meaning that this model is used in parallel by many developers on the different ongoing development efforts. A developer can also be working on multiple changes, so that while he is waiting for review or people to test one or more of his changes, he may be writing another change. As each commit represents an increment, this is a massively incremental model. The commits are in fact so frequent that during one year [3] , 85427 commits were made, making a daily average of 233 commits. Within the “code” bracket in Jørgensen's figure, each programmer has his own working style and follows his own development models. The bracket could very well have been called “development” as it includes requirements gathering and analysis, system and detailed design, implementation and verification. However, the only output from these stages is the source code or system documentation. From a stepwise model's perspective (such as the waterfall model), the other brackets can be seen as further verification and system integration. This system integration is also important to see if a change is accepted by the community. Up until the code is committed, the developer is free to choose how much to communicate about it to the rest of the project. In order for -CURRENT to work as a buffer (so that bright ideas that had some undiscovered drawbacks can be backed out) the minimum time a commit should be in -CURRENT before merging it to -STABLE is 3 days. Such a merge is referred to as an MFC (Merge From Current). It is important to notice the word “change”. Most commits do not contain radical new features, but are maintenance updates. The only exceptions from this model are security fixes and changes to features that are deprecated in the -CURRENT branch. In these cases, changes can be committed directly to the -STABLE branch. In addition to many people working on the project, there are many related projects to the FreeBSD Project. These are either projects developing brand new features, sub-projects or projects whose outcome is incorporated into FreeBSD [4]. These projects fit into the FreeBSD Project just like regular development efforts: they produce code that is integrated with the FreeBSD Project. However, some of them (like Ports and Documentation) have the privilege of being applicable to both branches or commit directly to both -CURRENT and -STABLE. There is no standards to how design should be done, nor is design collected in a centralised repository. The main design is that of 4.4BSD. [5] As design is a part of the “Code” bracket in Jørgenssen's model, it is up to every developer or sub-project how this should be done. Even if the design should be stored in a central repository, the output from the design stages would be of limited use as the differences of methodologies would make them poorly if at all interoperable. For the overall design of the project, the project relies on the sub-projects to negotiate fit interfaces between each other rather than to dictate interfacing. 4.2. Release branches The releases of FreeBSD is best illustrated by a tree with many branches where each major branch represents a major version. Minor versions are represented by branches of the major branches. In the following release tree, arrows that follow one-another in a particular direction represent a branch. Boxes with full lines and diamonds represent official releases. Boxes with dotted lines represent the development branch at that time. Security branches are represented by ovals. Diamonds differ from boxes in that they represent a fork, meaning a place where a branch splits into two branches where one of the branches becomes a sub-branch. For example, at 4.0-RELEASE the 4.0-CURRENT branch split into 4-STABLE and 5.0-CURRENT. At 4.5-RELEASE, the branch forked off a security branch called RELENG_4_5. Figure 4-2. The FreeBSD release tree The latest -CURRENT version is always referred to as -CURRENT, while the latest -STABLE release is always referred to as -STABLE. In this figure, -STABLE refers to 4-STABLE while -CURRENT refers to 5.0-CURRENT following 5.0-RELEASE. [FreeBSD, 2002E] A “major release” is always made from the -CURRENT branch. However, the -CURRENT branch does not need to fork at that point in time, but can focus on stabilising. An example of this is that following 3.0-RELEASE, 3.1-RELEASE was also a continuation of the -CURRENT-branch, and -CURRENT did not become a true development branch until this version was released and the 3-STABLE branch was forked. When -CURRENT returns to becoming a development branch, it can only be followed by a major release. 5-STABLE is predicted to be forked off 5.0-CURRENT at around 5.3-RELEASE. It is not until 5-STABLE is forked that the development branch will be branded 6.0-CURRENT. A “minor release” is made from the -CURRENT branch following a major release, or from the -STABLE branch. Following and including, 4.3-RELEASE[6], when a minor release has been made, it becomes a “security branch”. This is meant for organisations that do not want to follow the -STABLE branch and the potential new/changed features it offers, but instead require an absolutely stable environment, only updating to implement security updates. [7] Each update to a security branch is called a “patchlevel”. For every security enhancement that is done, the patchlevel number is increased, making it easy for people tracking the branch to see what security enhancements they have implemented. In cases where there have been especially serious security flaws, an entire new release can be made from a security branch. An example of this is 4.6.2-RELEASE. 4.3. Model summary To summarise, the development model of FreeBSD can be seen as the following tree: Figure 4-3. The overall development model The tree of the FreeBSD development with ongoing development efforts and continuous integration. The tree symbolises the release versions with major versions spawning new main branches and minor versions being versions of the main branch. The top branch is the -CURRENT branch where all new development is integrated, and the -STABLE branch is the branch directly below it. Clouds of development efforts hang over the project where developers use the development models they see fit. The product of their work is then integrated into -CURRENT where it undergoes parallel debugging and is finally merged from -CURRENT into -STABLE. Security fixes are merged from -STABLE to the security branches. Chapter 5 Hats Many committers have a special area of responsibility. These roles are called hats [Losh, 2002]. These hats can be either project roles, such as public relations officer, or maintainer for a certain area of the code. Because this is a project where people give voluntarily of their spare time, people with assigned hats are not always available. They must therefore appoint a deputy that can perform the hat's role in his or her absence. The other option is to have the role held by a group. Many of these hats are not formalised. Formalised hats have a charter stating the exact purpose of the hat along with its privileges and responsibilities. The writing of such charters is a new part of the project, and has thus yet to be completed for all hats. These hat descriptions are not such a formalisation, rather a summary of the role with links to the charter where available and contact addresses, 5.1. General Hats 5.1.1. Contributor A Contributor contributes to the FreeBSD project either as a developer, as an author, by sending problem reports, or in other ways contributing to the progress of the project. A contributor has no special privileges in the FreeBSD project. [FreeBSD, 2002F] 5.1.2. Committer A person who has the required privileges to add his code or documentation to the repository. A committer has made a commit within the past 12 months. [FreeBSD, 2000A] An active committer is a committer who has made an average of one commit per month during that time. It is worth noting that there are no technical barriers to prevent someone, once having gained commit privileges to the main- or a sub-project, to make commits in parts of that project's source the committer did not specifically get permission to modify. However, when wanting to make modifications to parts a committer has not been involved in before, he/she should read the logs to see what has happened in this area before, and also read the MAINTAINER file to see if the maintainer of this part has any special requests on how changes in the code should be made 5.1.3. Core Team The core team is elected by the committers from the pool of committers and serves as the board of directors of the FreeBSD project. It promotes active contributors to committers, assigns people to 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. Elections are held every two years. 5.1.4. Maintainership Maintainership means that that person is responsible for what is allowed to go into that area of the code and has the final say should disagreements over the code occur. This involves involves proactive work aimed at stimulating contributions and reactive work in reviewing commits. With the FreeBSD source comes the MAINTAINERS file that contains a one-line summary of how each maintainer would like contributions to be made. Having this notice and contact information enables developers to focus on the development effort rather than being stuck in a slow correspondence should the maintainer be unavailable for some time. If the maintainer is unavailable for an unreasonably long period of time, and other people do a significant amount of work, maintainership may be switched without the maintainer's approval. This is based on the stance that maintainership should be demonstrated, not declared. Maintainership of a particular piece of code is a hat that is not held as a group. 5.2. Official Hats 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 a description of each hat, including who it is held by. Figure 5-1. 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. 5.2.1. Documentation project manager The FreeBSD Documentation Project architect is responsible for defining and following up documentation goals for the committers in the Documentation project. Hat held by: The DocEng team <[email protected]>. The DocEng Charter. 5.2.2. CVSup Mirror Site Coordinator The CVSup Mirror Site Coordinator coordinates all the CVSup Mirror Site Admins to ensure that they are distributing current versions of the software, that they have the capacity to update themselves when major updates are in progress, and making it easy for the general public to find their closest CVSup mirror. Hat currently held by: John Polstra <[email protected]>. 5.2.3. Internationalisation The Internationalisation hat is responsible for coordinating the localisation efforts of the FreeBSD kernel and userland utilities. The translation effort are coordinated by The FreeBSD Documentation Project. The Internationalisation hat should suggest and promote standards and guidelines for writing and maintaining the software in a fashion that makes it easier to translate. Hat currently available. 5.2.4. Postmaster The Postmaster is responsible for mail being correctly delivered to the committers' email address. He is 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. Hat currently held by: David Wolfskill <[email protected]>. 5.2.5. Quality Assurance The responsibilities of this role are to manage the quality assurance measures. Hat currently held by: Robert Watson <[email protected]>. 5.2.6. Release Coordination The responsibilities of the Release Engineering Team are Setting, publishing and following a release schedule for official releases Documenting and formalising release engineering procedures Creation and maintenance of code branches Coordinating with the Ports and Documentation teams to have an updated set of packages and documentation released with the new releases Coordinating with the Security team so that pending releases are not affected by recently disclosed vulnerabilities. Further information about the development process is available in the release engineering section. Hat held by: the Release Engineering team <[email protected]>, currently headed by Murray Stokely <[email protected]>. The Release Engineering Charter. 5.2.7. Public Relations & Corporate Liaison The Public Relations & Corporate Liaison's responsibilities are: Making press statements when happenings that are important to the FreeBSD Project happen. Being the official contact person for corporations that are working close with the FreeBSD Project. Take steps to promote FreeBSD within both the Open Source community and the corporate world. Handle the “freebsd-advocacy” mailing list. This hat is currently not occupied. 5.2.8. Security Officer The Security Officer's main responsibility is to coordinate information exchange with others in the security community and in the FreeBSD project. The Security Officer is also responsible for taking action when security problems are reported and promoting proactive development behaviour when it comes to security. Because of the fear that information about vulnerabilities may leak out to people with malicious intent before a patch is available, only the Security Officer, consisting of an officer, a deputy and two Core team members, receive sensitive information about security issues. However, to create or implement a patch, the Security Officer has the Security Officer Team <[email protected]> to help do the work. Hat held by: the Security Officer <[email protected]>, currently headed by Colin Percival <[email protected]>. The Security Officer and The Security Officer Team's charter. 5.2.9. Source Repository Manager The Source Repository Manager is the only one who is allowed to directly modify the repository without using the CVS tool. It is his/her 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 necessary to resolve a CVS technical problem. Hat held by: the Source Repository Manager <[email protected]>, currently headed by Peter Wemm <[email protected]>. 5.2.10. Election Manager The Election Manager is responsible for the Core election process. The manager is responsible for running and maintaining the election system, and is the final authority should minor unforseen events happen in the election process. Major unforseen events have to be discussed with the Core team Hat held only during elections. 5.2.11. Web site Management The Web site Management hat is responsible for coordinating the rollout of updated web pages on mirrors around the world, for the overall structure of the primary web site and the system it is running upon. The management needs to coordinate the content with The FreeBSD Documentation Project and acts as maintainer for the “www” tree. Hat held by: the FreeBSD Webmasters <[email protected]>. 5.2.12. Ports Manager The Ports Manager acts as a liaison between The Ports Subproject and the core project, and all requests from the project should go to the ports manager. Hat held by: the Ports Management Team <[email protected]>, 5.2.13. Standards The Standards hat is responsible for ensuring that FreeBSD complies with the standards it is committed to , keeping up to date on the development of these standards and notifying FreeBSD developers of important changes that allows them to take a proactive role and decrease the time between a standards update and FreeBSD's compliancy. Hat currently held by: Garrett Wollman <[email protected]>. 5.2.14. Core Secretary The Core Secretary's main responsibility is to write drafts to and publish the final Core Reports. The secretary also keeps the core agenda, thus ensuring that no balls are dropped unresolved. Hat currently held by: Joel Dahl <[email protected]>. 5.2.15. GNATS Administrator The GNATS Administrator 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. Hat currently held by: Ceri Davies <[email protected]> and Mark Linimon <[email protected]>. 5.2.16. Bugmeister The Bugmeister is the person in charge of the problem report group. Hat currently held by: Ceri Davies <[email protected]> and Mark Linimon <[email protected]>. 5.2.17. Donations Liaison Officer The task of the donations liason officer is to match the developers with needs with people or organisations willing to make a donation. The Donations Liason Charter is available here Hat held by: the Donations Liaison Office <[email protected]>, currently headed by Michael W. Lucas <[email protected]>. 5.2.18. Admin (Also called “FreeBSD Cluster Admin”) The admin team consists of the people responsible for administrating the computers that the project relies on for its distributed work and communication to be synchronised. It consists mainly of those people who have physical access to the servers. Hat held by: the Admin team <[email protected]>, currently headed by Mark Murray <[email protected]> 5.3. Process dependent hats 5.3.1. Report originator The person originally responsible for filing a Problem Report. 5.3.2. Bugbuster A person who will either find the right person to solve the problem, or close the PR if it is a duplicate or otherwise not an interesting one. 5.3.3. Mentor A mentor is a committer who takes it upon him/her to introduce a new committer to the project, both in terms of ensuring the new committers 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 behaviour. 5.3.4. Vendor The person(s) or organisation whom external code comes from and whom patches are sent to. 5.3.5. Reviewers People on the mailing list where the request for review is posted. 5.3.6. CVSup Mirror Site Admin A CVSup Mirror Site Admin has accesses to a server that he/she uses to mirror the CVS repository. The admin works with the CVSup Mirror Site Coordinator to ensure the site remains up-to-date and is following the general policy of official mirror sites. Chapter 6 Processes The following section will describe the defined project processes. Issues that are not handled by these processes happen on an ad-hoc basis based on what has been customary to do in similar cases. 6.1. Adding new and removing old committers The Core team has the responsibility of giving and removing commit privileges to contributors. This can only be done through a vote on the core mailing list. The ports and documentation sub-projects can give commit privileges to people working on these projects, but have to date not removed such privileges. Normally a contributor is recommended to core by a committer. For contributors or outsiders to contact core asking to be a committer is not well thought of and is usually rejected. If the area of particular interest for the developer potentially overlaps with other committers' area of maintainership, the opinion of those maintainers is sought. However, it is frequently this committer that recommends the developer. When a contributor is given committer status, he is 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. When a contributor is given his commit bit, a PGP-signed email is sent from either Core Secretary, Ports Manager or [email protected] to both [email protected], the assigned mentor, the new committer and core confirming the approval of a new account. The mentor then gathers a password line, SSH 2 public key and PGP key from the new committer and sends them to Admin. When the new account is created, the mentor activates the commit bit and guides the new committer through the rest of the initial process. Figure 6-1. Process summary: adding a new committer 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 favour, a mentor is assigned the new committer and the new committer has to email his 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. Recall that a committer is considered to be someone who has committed code during the past 12 months. However, it is not until after 18 months of inactivity have passed that commit privileges are eligible to be revoked. [FreeBSD, 2002H] There are, however, no automatic procedures for doing this. For reactions concerning commit privileges not triggered by time, see section 1.5.8. Figure 6-2. Process summary: removing a committer 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. It is also possible for committers to request that their commit bit be retired if for some reason they are no longer going to be actively committing to the project. In this case, it can also be restored at a later time by core, should the committer ask. Roles in this process: Core team Contributor Committer Maintainership Mentor [FreeBSD, 2000A] [FreeBSD, 2002H] [FreeBSD, 2002I] 6.2. Adding/Removing an official CVSup Mirror A CVSup mirror is a replica of the official CVSup master that contains all the up-to-date source code for all the branches in the FreeBSD project, ports and documentation. Adding an official CVSup mirror starts with the potential CVSup Mirror Site Admin installing the “cvsup-mirror” package. Having done this and updated the source code with a mirror site, he now runs a fairly recent unofficial CVSup mirror. Deciding he has a stable environment, the processing power, the network capacity and the storage capacity to run an official mirror, he mails the CVSup Mirror Site Coordinator who decides whether the mirror should become an official mirror or not. In making this decision, the CVSup Mirror Site Coordinator has to determine whether that geographical area needs another mirror site, if the mirror administrator has the skills to run it reliably, if the network bandwidth is adequate and if the master server has the capacity to server another mirror. If CVSup Mirror Site Coordinator decides that the mirror should become an official mirror, he obtains an authentication key from the mirror admin that he installs so the mirror admin can update the mirror from the master server. Figure 6-3. Process summary: adding a CVSup mirror When a CVSup mirror administrator of an unofficial mirror offers to become an official mirror site, the CVSup coordinator decides if another mirror is needed and if there is sufficient capacity to accommodate it. If so, an authorisation key is requested and the mirror is given access to the main distribution site and added to the list of official mirrors. Tools used in this process: CVSup SSH 2 Hats involved in this process: CVSup Mirror Site Coordinator CVSup Mirror Site Admin 6.3. Committing code The committing of new or modified code is one of the most 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 submitted through a problem report. When code is written by the developer that is non-trivial, he 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 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 reviewed by the committer and tested the same way. When a change is committed to a part of the source that has been contributed from an outside Vendor, the maintainer should ensure that the patch is contributed back to the vendor. This is in line with the open source philosophy and makes it easier to stay in sync with outside projects as the patches do not have to be reapplied every time a new release is made. After the code has been available for review and no further changes are necessary, the code is committed into the development branch, -CURRENT. If the change applies for the -STABLE branch or the other branches as well, a “Merge From Current” ("MFC") countdown is 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 branch (and possibly security branches as well). Only security critical changes should be merged to security branches. Delaying the commit to -STABLE and other branches allows for “parallel debugging” where the committed code is tested on a wide range of configurations. This makes changes to -STABLE to contain fewer faults and thus giving the branch its name. Figure 6-4. Process summary: A committer commits code When a committer has written a piece of code and wants to commit it, he first needs 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 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 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 implement or ignore the patch. Figure 6-5. Process summary: A contributor commits code The difference when a contributor makes a code contribution is that he submits the code through the send-pr program. This report is picked up by the maintainer who reviews the code and commits it. Hats included in this process are: Committer Contributor Vendor Reviewer [FreeBSD, 2001] [Jørgensen, 2001] 6.4. Core election Core elections are held at least every two years. [8] Nine core members are elected. New elections are held if the number of core members drops below seven. New elections can also be held should at least 1/3 of the active committers demand this. When an election is to take place, core announces this at least 6 weeks in advance, and appoints an election manager to run the elections. Only committers can be elected into core. The candidates need to submit their candidacy at least one week before the election starts, but can refine their statements until the voting starts. They are presented in the candidates list. When writing their election statements, the candidates must answer a few standard questions submitted by the election manager. During elections, the rule that a committer must have committed during the 12 past months is followed strictly. Only these committers are eligible to vote. When voting, the committer may vote once in support of up to nine nominees. The voting is done over a period of four weeks with reminders being posted on “developers” mailing list that is available to all committers. The election results are released one week after the election ends, and the new core team takes office one week after the results have been posted. Should there be a voting tie, this will be resolved by the new, unambiguously elected core members. Votes and candidate statements are archived, but the archives are not publicly available. Figure 6-6. Process summary: Core elections Core announces the election and selects an election manager. He 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 announced and the new core team takes office. Hats in core elections are: Core team Committer Election Manager [FreeBSD, 2000A] [FreeBSD, 2002B] [FreeBSD, 2002G] 6.5. Development of new features Within the project there are sub-projects that are working on new features. These projects are generally done by one person [Jørgensen, 2001]. Every project is free to organise development as it sees fit. However, when the project is merged to the -CURRENT branch it must follow the project guidelines. When the code has been well tested in the -CURRENT branch and deemed stable enough and relevant to the -STABLE branch, it is merged to the -STABLE branch. The requirements of the project are given by developer wishes, requests from the community in terms of direct 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 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 requests, their distribution and follow-up are handled by the GNATS tool. Requirements analysis happens in two ways. The requests that come in are discussed on mailing lists, both within the main project and in the sub-project that the request belongs to or is spawned by the request. Furthermore, individual developers on the sub-project will evaluate the feasibility of the requests and determine the prioritisation between them. Other than archives of the discussions that have taken place, no outcome is created by this phase that is merged into the main project. As the requests are prioritised by the individual developers on the basis of doing what they find interesting, necessary or are funded to do, there is no overall strategy or priorisation of what requests to regard as requirements and following up their correct implementation. However, most developers have some shared vision of what issues are more important, and they can ask for guidelines from the release engineering team. The verification phase of the project is two-fold. Before committing code to the current-branch, developers request their code to be reviewed by their peers. This review is for the most part done by functional testing, but also code review is important. When the code is committed to the branch, a broader functional testing will happen, that may trigger further code review and debugging should the code not behave as expected. This second verification form may be regarded as structural verification. Although the sub-projects themselves may write formal tests such as unit tests, these are usually not collected by the main project and are usually removed before the code is committed to the current branch. [9] 6.6. Maintenance It is an advantage to the project to for each area of the source have at least one person that knows this area well. Some parts of the code have designated maintainers. Others have de-facto maintainers, and some parts of the system do not have maintainers. The maintainer is usually a person from the sub-project that wrote and integrated the code, or someone who has ported it from the platform it was written for. [10] The maintainer's job is to make sure the code is in sync with the project the code comes from if it is contributed code, and apply patches submitted by the community or write fixes to issues that are discovered. The main bulk of work that is put into the FreeBSD project is maintenance. [Jørgensen, 2001] has made a figure showing the life cycle of changes. Figure 6-7. Jørgenssen's model for change integration Here “development release” refers to the -CURRENT branch while “production release” refers to the -STABLE branch. The “pre-commit test” is the functional testing by peer developers when asked to do so or trying out the code to determine the status of the sub-project. “Parallel debugging” is the functional testing that can trigger more review, and debugging when the code is included in the -CURRENT branch. As of this writing, there were 269 committers in the project. When they commit a change to a branch, that constitutes a new release. It is very common for users in the community to track a particular branch. The immediate existence of a new release makes the changes widely available right away and allows for rapid feedback from the community. This also gives the community the response time they expect on issues that are of importance to them. This makes the community more engaged, and thus allows for more and better feedback that again spurs more maintenance and ultimately should create a better product. Before making changes to code in parts of the tree that has a history unknown to the committer, the committer is required to read the commit logs to see why certain features are implemented the way they are in order not to make mistakes that have previously either been thought through or resolved. 6.7. Problem reporting FreeBSD comes with a problem reporting tool called “send-pr” that is a part of the GNATS package. All users and developers are encouraged to use this tool for reporting problems in software they do not maintain. Problems include bug reports, feature requests, features that should be enhanced and notices of new versions of external software that is included in the project. Problem reports are sent to an email address where it is inserted into the GNATS maintenance database. A Bugbuster classifies the problem and sends it to the correct group or maintainer within the project. After someone has taken responsibility for the report, the report is being analysed. This analysis includes verifying the problem and thinking out a solution for the problem. Often feedback is required from the report originator or even from the FreeBSD community. Once a patch for the problem is made, the originator may be asked to try it out. Finally, the working patch is integrated into the project, and documented if applicable. It there goes through the regular maintenance cycle as described in section maintenance. These are the states a problem report can be in: open, analyzed, feedback, patched, suspended and closed. The suspended state is for when further progress is not possible due to the lack of information or for when the task would require so much work that nobody is working on it at the moment. Figure 6-8. Process summary: problem reporting 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 information to create a working patch. This patch is then committed and the problem report is closed. The roles included in this process are: Report originator Maintainership Bugbuster [FreeBSD, 2002C]. [FreeBSD, 2002D] 6.8. Reacting to misbehaviour [FreeBSD, 2001] has a 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 misbehaviour. They specify what actions will result in how long a suspension the committer's commit privileges. Committing during code freezes without the approval of the Release Engineering team - 2 days Committing to a security branch without approval - 2 days Commit wars - 5 days to all participating parties Impolite or inappropriate behaviour - 5 days [Lehey, 2002] For the suspensions to be efficient, any single core member can implement a suspension before discussing it on the “core” 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 suspensions are posted to the “developers” mailing list, a list available to committers only. It is important that you cannot be suspended for making technical errors. All penalties come from breaking social etiquette. Hats involved in this process: Core team Committer 6.9. Release engineering The FreeBSD project has a Release Engineering team with a principal release engineer that is responsible for creating releases of FreeBSD that can be brought out to the user community via the net or sold in retail outlets. Since FreeBSD is available on multiple platforms and releases for the different architectures are made available at the same time, the team has one person in charge of each architecture. Also, there are roles in the team responsible for coordinating quality assurance efforts, building a package set and for having an updated set of documents. When referring to the release engineer, a representative for the release engineering team is meant. When a release is coming, the FreeBSD project changes shape somewhat. A release schedule is made containing feature- and code-freezes, release of interim releases and the final release. A feature-freeze means no new features are allowed to 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 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 are not suitable to be included in the release. There are three different kinds of releases: .0 releases are the first release of a major version. These are branched of the -CURRENT branch and have a significantly longer release engineering cycle due to the unstable nature of the -CURRENT branch .X releases are releases of the -STABLE branch. They are scheduled to come out every 4 months. .X.Y releases are security releases that follow the .X branch. These come out only when sufficient security fixes have been merged since the last release on that branch. New features are rarely included, and the security team is far more involved in these than in regular releases. For releases of the -STABLE-branch, the release process starts 45 days before the anticipated release date. During the first phase, the first 15 days, the developers merge what changes they have had in -CURRENT that they want to have in the release to the release branch. When this period is over, the code enters a 15 day code freeze in which only bug fixes, documentation updates, security-related fixes and minor device driver changes are allowed. These changes must be approved by the release engineer in advance. At the beginning of the last 15 day period a release candidate is created for widespread testing. Updates are less likely to be allowed during this period, except for important bug fixes and security updates. In this final period, all 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 considered "really released" until a PGP-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 subject to change before the PGP-signed message is sent. [11]. The releases of the -CURRENT-branch (that is, all releases that end with “.0”) are very similar, but with twice as long timeframe. It starts 8 weeks prior to the release with announcement of the release time line. Two weeks into the release process, the feature freeze is initiated and performance tweaks should be kept to a minimum. Four weeks prior to the release, an official beta version is made available. Two weeks prior to release, the code is officially branched into a new version. This version is given release candidate status, and as with the release engineering of -STABLE, the code freeze of the release candidate is hardened. However, development on the main development branch can continue. Other than these differences, the release engineering processes are alike. .0 releases go into their own branch and are aimed mainly at early adopters. The branch then goes through a period of stabilisation, and it is not until the Release Engineering Team> decides the demands to stability have been satisfied that the branch becomes -STABLE and -CURRENT targets the next major version. While this for the majority has been with .1 versions, this is not a demand. Most releases are made when a given date that has been deemed a long enough time since the previous release comes. A target is set for having major releases every 18 months and minor releases every 4 months. The user community has made it very clear that security and stability cannot be sacrificed by self-imposed deadlines and target release dates. For slips of time not to become too long with regards to security and stability issues, extra discipline is required when committing changes to -STABLE. Figure 6-9. Process summary: release engineering 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. [FreeBSD, 2002E] Chapter 7 Tools The major support tools for supporting the development process are CVS, CVSup, Perforce, GNATS, Mailman and OpenSSH. Except for CVSup, these are externally developed tools. These tools are commonly used in the open source world. 7.1. Concurrent Versions System (CVS) Concurrent Versions System or simply “CVS” is a system to handle multiple versions of text files and tracking who committed what changes and why. A project lives within a “repository” and different versions are considered different “branches”. 7.2. CVSup CVSup is a software package for distributing and updating collections of files across a network. It consists of a client program, cvsup, and a server program, cvsupd. The package is tailored specifically for distributing CVS repositories, and by taking advantage of CVS' properties, it performs updates much faster than traditional systems. 7.3. GNATS GNATS is a maintenance database consisting of a set of tools to track bugs at a central site. It supports the bug tracking process for sending and handling bugs as well as querying and updating the database and editing bug reports. The project uses one of its many client interfaces, “send-pr”, to send “Problem Reports” by email to the projects central GNATS server. The committers have also web and command-line clients available. 7.4. Mailman 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 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 development of specific areas of interest, and closed lists are for internal communication not intended for the general public. The majority of all the communication in the project goes through these 85 lists [FreeBSD, 2003A, Appendix C]. 7.5. Perforce Perforce is a commercial software configuration management system developed by Perforce Systems that is available on over 50 operating systems. It is a collection of clients built around the Perforce server that contains the central file repository and tracks the operations done upon it. The clients are both clients for accessing the repository and administration of its configuration. 7.6. Pretty Good Privacy Pretty Good Privacy, better known as PGP, is a cryptosystem 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 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 claims to have written it, and not altered in transit. 7.7. Secure Shell Secure Shell is a standard for securely logging into a remote system and for executing commands on the remote system. It allows other connections, called tunnels, to be established and protected between the two involved systems. This standard exists in two primary versions, and only version two is used for the FreeBSD Project. The most common implementation of the standard is OpenSSH that is a part of the project's main distribution. Since its source is updated more often than FreeBSD releases, the latest version is also available in the ports tree. Chapter 8 Sub-projects Sub-projects are formed to reduce the amount of communication needed to coordinate the group of developers. When a problem area is sufficiently isolated, most communication would be within the group focusing on the problem, requiring less communication with the groups they communicate with than were the group not isolated. 8.1. The Ports Subproject 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 at a tremendous rate, as shown by the following figure. Figure 8-1. Number of ports added between 1996 and 2005 Figure 8-1 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 linerly. As the external software described by the port often is under continued development, the amount of work required to maintain the ports is already large, and increasing. This has led to the ports part of the FreeBSD project gaining a more empowered structure, and is more and more becoming a sub-project of the FreeBSD project. Ports has its own core team with the Ports Manager as its leader, and this team can appoint committers without FreeBSD Core's approval. Unlike in the FreeBSD Project, where a lot of maintenance frequently is rewarded with a commit bit, the ports sub-project contains many active maintainers that are not committers. Unlike the main project, the ports tree is not branched. Every release of FreeBSD follows the current ports collection and has thus available updated information on where to find programs and how to build them. This, however, means that a port that makes dependencies on the system may need to have variations depending on what version of FreeBSD it runs on. With an unbranched ports repository it is not possible to guarantee that any port will run on anything other than -CURRENT and -STABLE, in particular older, minor releases. There is neither the infrastructure nor volunteer time needed to guarantee this. For efficiency of communication, teams depending on Ports, such as the release engineering team, have their own ports liaisons. 8.2. The FreeBSD Documentation Project The FreeBSD Documentation project was started January 1995. From the initial group of a project leader, four team leaders and 16 members, they are now a total of 44 committers. The documentation mailing list has just under 300 members, indicating that there is quite a large community around it. The goal of the Documentation project is to provide good and useful documentation of the FreeBSD project, thus making it easier for new users to get familiar with the system and detailing advanced features for the users. The main tasks in the Documentation project are to work on current projects in the “FreeBSD Documentation Set”, and translate the documentation to other languages. Like the FreeBSD Project, documentation is split in the same branches. This is done so that there is always an updated version of the documentation for each version. Only documentation errors are corrected in the security branches. Like the ports sub-project, the Documentation project can appoint documentation committers without FreeBSD Core's approval. [FreeBSD, 2003B]. 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. References [Brooks, 1995] Frederick P. Brooks, 1975, 1995, 0201835959, Addison-Wesley Pub Co, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition). [Saers, 2003] Niklas Saers, 2003, A project model for the FreeBSD Project: Candidatus Scientiarum thesis. [Jørgensen, 2001] Niels Jørgensen, 2001, Putting it All in the Trunk: Incremental Software Development in the FreeBSD Open Source Project. [PMI, 2000] Project Management Institute, 1996, 2000, 1-880410-23-0, Project Management Institute, Pennsylvania, PMBOK Guide: A Guide to the Project Management Body of Knowledge, 2000 Edition. [FreeBSD, 2000A] 2002, Core Bylaws. [FreeBSD, 2002A] 2002, FreeBSD Developer's Handbook. [FreeBSD, 2002B] 2002, Core team election 2002. [Losh, 2002] Warner Losh, 2002, Working with Hats. [FreeBSD, 2002C] Dag-Erling Smørgrav and Hiten Pandya, 2002, The FreeBSD Documentation Project, Problem Report Handling Guidelines. [FreeBSD, 2002D] Dag-Erling Smørgrav, 2002, The FreeBSD Documentation Project, Writing FreeBSD Problem Reports. [FreeBSD, 2001] 2001, The FreeBSD Documentation Project, Committers Guide. [FreeBSD, 2002E] Murray Stokely, 2002, The FreeBSD Documentation Project, FreeBSD Release Engineering. [FreeBSD, 2003A] The FreeBSD Documentation Project, FreeBSD Handbook. [FreeBSD, 2002F] 2002, The FreeBSD Documentation Project, Contributors to FreeBSD. [FreeBSD, 2002G] 2002, The FreeBSD Project, Core team elections 2002. [FreeBSD, 2002H] 2002, The FreeBSD Project, Commit Bit Expiration Policy: 2002/04/06 15:35:30. [FreeBSD, 2002I] 2002, The FreeBSD Project, New Account Creation Procedure: 2002/08/19 17:11:27. [FreeBSD, 2003B] 2002, The FreeBSD Documentation Project, FreeBSD DocEng Team Charter: 2003/03/16 12:17. [Lehey, 2002] Greg Lehey, 2002, Greg Lehey, Two years in the trenches: The evolution of a software project. Notes [1] This goes hand-in-hand with Brooks' law that “adding another person to a late project will make it later” since it will increase the communication needs Brooks, 1995. A project model is a tool to reduce the communication needs. [2] Statistics are generated by counting the number of entries in the file fetched by portsdb by April 1st, 2005. portsdb is a part of the port sysutils/portupgrade. [3] The period from January 1st, 2004 to December 31st, 2004 was examined to find this number. [4] For instance, the development of the Bluetooth stack started as a sub-project until it was deemed stable enough to be merged into the -CURRENT branch. Now it is a part of the core FreeBSD system. [5] According to Kirk McKusick, after 20 years of developing UNIX operating systems, the interfaces are for the most part figured out. There is therefore no need for much design. However, new applications of the system and new hardware leads to some implementations being more beneficial than those that used to be preferred. One example is the introduction of web browsing that made the normal TCP/IP connection a short burst of data rather than a steady stream over a longer period of time. [6] The first release this actually happened for was 4.5-RELEASE, but security branches were at the same time created for 4.3-RELEASE and 4.4-RELEASE. [7] There is a terminology overlap with respect to the word "stable", which leads to some confusion. The -STABLE branch is still a development branch, whose goal is to be useful for most people. If it is never acceptable for a system to get changes that are not announced at the time it is deployed, that system should run a security branch. [8] The first Core election was held September 2000 [9] More and more tests are however performed when building the system &

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值