1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
|
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//FreeBSD//DTD XHTML 1.0 Transitional-Based Extension//EN"
"http://www.FreeBSD.org/XML/doc/share/sgml/xhtml10-freebsd.dtd" [
<!ENTITY title "Policies of the Ports Management Team">
]>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>&title;</title>
<cvs:keyword xmlns:cvs="http://www.FreeBSD.org/XML/CVS">$FreeBSD$</cvs:keyword>
</head>
<body class="navinclude.about">
<p>In accordance with its <a href="charter.html">Charter</a>, the
Ports Management Team has adopted certain policies to try to meet
each of its goals.</p>
<p><a href="policies_eol.html">EOL Policies of Ports and Ports
Intrastructure</a></p>
<h3>Assure The Integrity Of The Ports Collection</h3>
<p>To help assure the integrity of the Ports Collection, portmgr
acts as sole committer for certain files that are integral to it,
such as <tt>bsd.port.mk</tt>. Since the ports tree is not
branched (unlike some of the other BSD projects), any fatal
error in these files will be quickly picked up by the many
users who run automated updates of their ports.</p>
<p>portmgr also runs periodic builds of proposed large changes to the
Ports Collection on a dedicated area of the automated
<a href="http://pointyhat.FreeBSD.org">ports building cluster</a>.
Examples of changes that should be tested here before committing
include:</p>
<ul>
<li><p>changes to <tt>bsd.port.mk</tt></p></li>
<li><p>changes to packages with many dependencies, including
X11 servers, GNOME, KDE, autotools, and so forth</p></li>
<li><p>changes that change the "accepted best practice" for
ports Makefiles, such as definitions or usage of common make
variables (or <tt>Makevar</tt>s). (e.g. consolidation of
various implementations of USE_*, WITH_*, and so forth)</p></li>
<li><p>large repocopies (such as when an existing port category
is divided up)</p></li>
</ul>
<p>Again, since the ports tree is not branched, any large-scale
failures that might be caused by any of the above need to be caught
first before a large number of user installations are affected.</p>
<p>At other times, especially during the preparations for a new release,
there are <a href="policies_committing.html">
other restrictions on when commits are allowed</a>.</p>
<p>portmgr reserves the right to act as final arbiter of other
commits in certain unusual cases, such as: commits that in their
opinion destabilize the Ports Collection; violate the
Principle Of Least Astonishment for FreeBSD's users; or in cases
of inter-committer disputes that can not be solved among the
committers themselves.</p>
<h3>Maintain The Automated <a href="http://pointyhat.FreeBSD.org">
Ports Building Cluster</a></h3>
<p>portmgr maintains a set of machines that automatically build
packages on combinations of FreeBSD source tree versus CPU
architecture (in our terminology, <tt>build environments</tt> or
<tt>buildenv</tt>s). Where license distribution permits, the
resulting packages are regularly uploaded to the main FTP mirror
as the "new latest package" so that they are available for download
by FreeBSD users. Port build failures are reported to the responsible
maintainers and/or committers for the appropriate corrective action.</p>
<p>In some cases ports may become broken by changes to the FreeBSD base
system (src/ tree). In such a case, the Ports Management Team expects
the responsible Source Committer to develop fixes to the affected ports,
in consultation with the relevant port maintainers.</p>
<h3>Work With The FreeBSD Security Team</h3>
<!-- nothing specific; the header is left to cross-reference the charter -->
<h3>Work with FreeBSD Ports and Documentation Committers</h3>
<p>portmgr will attempt to help keep the
<a href="&base;/doc/en_US.ISO8859-1/books/porters-handbook/index.html">
FreeBSD Porter's Handbook</a> up to date with what it believes to be
the "best practices" for individual ports.</p>
<p>(The intent is not just to lay down 'rules' but to say 'here is
why something that we advocate as The Right Thing in the ports
Makefiles is done.' In particular, there are a number of
"edge cases" that <tt>bsd.*.mk</tt> has some very convoluted
code to handle -- such as ensuring that ports can be installed
from CD-ROM, over NFS, and so forth -- and failing to understand
these issues can lead to maintainers using shortcuts that will
not work in these edge cases.)</p>
<p>portmgr is not the sole owner of the Porter's Handbook, as it is
actually in the <tt>doc/</tt> tree. We welcome PR submitters and
<tt>doc</tt> committers to work on it to add documentation that helps
to clarify existing practice. However, we would like to request,
as a courtesy, the right to review any changes that would seem to
change existing practice.</p>
<p>In addition, there has been recent discussion about creating a
"Rights And Responsibilities of FreeBSD Ports Maintainers and Committers"
document. portmgr supports this effort and looks forward to being
able to review any drafts.</p>
<p>portmgr also is responsible for certain other documentation such as the
<a href="&base;/doc/en_US.ISO8859-1/articles/committers-guide/ports.html">
ports-specific portions of the Committer's Guide</a> and the
<a href="&base;/doc/en_US.ISO8859-1/articles/contributing-ports/">
Contributing to the FreeBSD Ports Collection</a> article.</p>
<h3>Respect The Legal Rights Of Authors Whose Works Are Installed Via
The Ports Collection</h3>
<p>To the extent possible with a volunteer project, portmgr will work
to ensure that the legal rights of authors whose works are installed
via the Ports Collection are respected. This includes making sure that
the appropriate entries are made to <tt>ports/LEGAL</tt> and to
the <tt>makevars</tt> that control package building and thus automated
distribution of binaries.</p>
<p>In rare cases this may also require removing a port and all distfiles
and binaries if the original author demands it.</p>
<p>portmgr asks our volunteer committers to carefully consider authors'
licensing restrictions when committing new ports, since it is infeasible
for the members of portmgr to do so themselves due to the huge number
of ports.</p>
<h3>Act As Arbiter Of First Resort For Disputes Between FreeBSD
Community Members Such As Maintainers And Committers</h3>
<p>portmgr encourages members of the FreeBSD community to work
together in accordance with the principles set out in the
Committer's Guide. In case of disputes, it reserves the right
to abitrate, subject to review by the Core Team.</p>
<h3>Manage Commit Access To The Ports Tree</h3>
<p>The FreeBSD Core Team has delegated the responsibility to manage
commit access to the <tt>ports/</tt> tree to portmgr. Core
reviews granting and revocation of commit bits and has final
authority over all the entire FreeBSD repositories.</p>
<p>New Ports Committers are proposed by an existing Ports Committer
who wishes to act as a mentor. The proposals should include a brief
summary of the history of contributions made by the proposed new
committer such as number of PRs submitted, number of ports currently
maintained, and existing commit bits in other trees, if any.</p>
<p>In its votes the team will consider that history as well as any other
relevant factors. The results of the votes are made available to
the FreeBSD developer community.</p>
<p>In accordance with practice elsewhere in the project, inactive
Ports Committers are
<a href="policies_contributors.html#commit_privileges">
periodically contacted</a> to enquire about
their status and interest in continuing to work with the ports tree.
Committers who do not respond to such email, or who respond in the
negative, have their commit bits reclaimed for safekeeping.
Currrently, this period is one year.</p>
<p>In unusual cases it may become necessary to remove Ports Committers
for other reasons. This will only be done after serious deliberation,
and is subject to review by Core.</p>
<h3>Establish Guidelines And Policies Governing The Rights And
Responsibilities Of Ports Committers And Maintainers</h3>
<p>portmgr has the responsibility to establish guidelines and policies
governing the rights and responsibilities of Ports Committers and
maintainers, such as expected standards of maintainership, conditions
under which maintainers may be overridden or removed, and other
policies.</p>
<p>To ensure that ports Problem Reports are handled in a timely
manner, portmgr has established a guideline about how long a PR
assigned to a committer may remain open before being eligible for
being committed by another committer via a
<a href="policies_contributors.html#pr_timeout">"maintainer timeout"</a>.
This time period applies to such things as updates that do not require
a regression run; for other updates, please contact portmgr directly.
The time period does not count ports freezes and
generally recognized holidays.</p>
<p>In addition, to ensure that ports are maintained in a timely
fashion, portmgr has established a guideline about how long a port
maintainer may be inactive before
<a href="policies_contributors.html#maintainer_reset">
forfeiting maintainership</a>.
"inactive" is not interpreted strictly, but is intended to encompass
such things as unresolved open PRs, commits made by others via
maintainer timeouts, and unresolved build problems.</p>
<p>The intent of these policies is not to assign punishment or blame,
but to reflect the fact that the software installed by the Ports
Collection undergoes rapid development that is outside FreeBSD's
control. Part of the responsibility that a ports maintainer
accepts is to try to keep a port working and as up-to-date as
feasible. It is unfair to our users to let unfixed problems
languish and stale versions remain. However, we also recognize
that all of our maintainers and committers are volunteers just
as we are, and that as with any volunteer project, it is easy to
overcommit, or lose interest in a particular port.</p>
<p>Maintainers and committers who feel overcommitted or have lost
interest in any particular port should feel free to ask for new
volunteers and/or reassignment of the port back to the general
pool. Not only will this help keep the Ports Collection current,
but hopefully will help prevent volunteer burnout.</p>
<h3>Help Prioritize Future Directions For The Overall Ports Collection</h3>
<p>portmgr recognizes that the development and evolution of the Ports
Collection is primarily driven by the work of community members.
However, due to the unbranched nature of the Ports Collection,
it is sometimes necessary to coordinate, or even choose among, any
proposed changes.</p>
<p>To some extent this involves choosing which patches are adopted
for testing on the build cluster, but it also involves such issues
as working to build consensus over architectural decisions,
creating lists of "interesting projects", and so forth.</p>
</body>
</html>
|
