User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

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 prioritisation 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.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

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 histheir time between the request and histheir 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 <xref linkend="tool-bugzilla"/> tool.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

Core announces the election and selects an election manager. He who prepares the elections, and when ready, candidates can announce their candidacies through submitting their statements. The committers then vote. After the vote is over, the election results are announced and the new core team takes office.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

The difference when a contributor makes a code contribution is that they submits the code through the Bugzilla interface. This report is picked up by the maintainer who reviews the code and commits it.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

When a committer has written a piece of code and wants to commit it, they 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, they should consult the maintainer before proceeding. If the code is contributed by an outside vendor, the maintainer should create a patch that is sent back to the vendor. The code is then committed and then deployed by the users. Should they find problems with the code, this will be reported and the committer can go back to writing a patch. If a vendor is affected, they can choose to implement or ignore the patch.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

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 <quote>Merge From Current</quote> ("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 hithem to commit it to the -STABLE branch (and possibly security branches as well). Only security critical changes should be merged to security branches.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

When code is written by the developer that is non-trivial, they should seek a code review from the community. This is done by sending mail to the relevant list asking for review. Before submitting the code for review, they should ensure it compiles correctly with the entire tree and that all relevant tests run. This is called <quote>pre-commit test</quote>. When contributed code is received, it should be reviewed by the committer and tested the same way.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

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 <quote>committer</quote>. Committers commit either code written by themselves, code submitted to them, or code submitted through a <link linkend="model-pr">problem report</link>.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

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 and their account removed by the administrators.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

When a contributor sends a piece of code, the receiving committer may choose to recommend that the contributor is given commit privileges. If they recommends this to core, theycore will vote on this recommendation. If they vote is in favour, a mentor is assigned the new committer and the new committer has to email histheir details to the administrators for an account to be created. After this, the new committer is all set to make histheir first commit. By tradition, this is by adding histheir name to the committers list.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

When a contributor is given histheir commit bit, a <xref linkend="tool-pgp"/>-signed email is sent from either <xref linkend="role-core-secretary"/>, <xref linkend="role-ports-manager"/>, or nik@freebsd.org to both admins@freebsd.org, the assigned mentor, the new committer, and core confirming the approval of a new account. The mentor then gathers a password line, <xref linkend="tool-ssh2"/> public key, and PGP key from the new committer and sends them to <xref linkend="role-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.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

When a contributor is given committer status, the isy are assigned a mentor. The committer who recommended the new committer will, in the general case, take it upon hithemselfves to be the new committers mentor.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

A mentor is a committer who takes it upon him/herthem to introduce a new committer to the project, both in terms of ensuring the new committer's setup is valid, that the new committer knows the available tools required in his/their work, and that the new committer knows what is expected of him/herthem in terms of behavior.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

Hat held by: Tthe DocEng teamnations Liaison Office <email>docengnations@FreeBSD.org</email>. The <link xlink:href="https://www.freebsd.org/internal/doceng.html"> DocEngdonations/"> Donations Liaison Charter</link>.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

The task of the donations liaison officer is to match the developers with needs with people or organisations willing to make a donation. The Donations Liaison Charter is available <link xlink:href="https://www.freebsd.org/donations/">here</link>
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

The Bugmeister is responsible for ensuring that the maintenance database is in working order, that the entries are correctly categorised and that there are no invalid entries. They supervise bugbusters.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

The Source Repository Manager is the only one who is allowed to directly modify the repository without using the <xref linkend="tool-svn"/> tool. It is his/their responsibility to ensure that technical problems that arise in the repository are resolved quickly. The source repository manager has the authority to back out commits if this is necessary to resolve a SVN technical problem.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

The Postmaster is responsible for mail being correctly delivered to the committers' email address. He isThey are also responsible for ensuring that the mailing lists work and should take measures against possible disruptions of mail such as having troll-, spam- and virus-filters.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

<xref linkend="sub-project-documentation"/> architect is responsible for defining and following up documentation goals for the committers in the Documentation project, which they supervise.
3 months ago
User avatar None

Source string changed

FreeBSD Doc / books_dev-modelPortuguese (Brazil)

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 illustrationlist shows the responsibility lines. After this follow and gives a description of each hat, including who it is held by.
3 months ago

Search