280592133a
policies.sgml gathers together the various policies that portmgr has promulgated in the past to try to assure the integrity of the Ports Collection. It is indexed more-or-less in order of the responsibilities listed in charter.sgml. qa.sgml explains the work that portmgr does for Quality Assurance (QA) for the ports collection, both during and between release cycles, to help increase the visibility of its role. The portmgr team requests that they be allowed a courtesy review of any proposed changes to these files.
189 lines
6.8 KiB
Text
189 lines
6.8 KiB
Text
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
|
|
<!ENTITY base CDATA "..">
|
|
<!ENTITY date "$FreeBSD$">
|
|
<!ENTITY title "Quality Assurance Tasks for the Ports Management Team">
|
|
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
|
]>
|
|
|
|
<html>
|
|
&header;
|
|
|
|
<p>There are a number of tasks that the Ports Management Team undertakes
|
|
to try to improve the quality of the Ports Collection. These fall into
|
|
two main categories:
|
|
<a href="#qa-before-release">activities during a release cycle</a> and
|
|
<a href="#qa-between-releases">activities between release cycles</a>.
|
|
</p>
|
|
|
|
<h3><a name="qa-before-release">Activities During a Release Cycle</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>Work with the
|
|
<a href="../releng/index.html">Release Engineering Team</a>
|
|
to coordinate the release schedule.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Work with the RE team to determine which pre-built packages
|
|
can be included on the default install ISOs.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Manage commits to the CVS tree for package builds via the
|
|
following steps:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>Institute a freeze and produce packages for all the
|
|
appropriate architectures. Often this process has to be
|
|
repeated because either bugs are identified in various ports,
|
|
or changes to the src tree create a risk that the packages
|
|
that have already been built would not work with those
|
|
changes.</p>
|
|
|
|
<p>Although the freeze is advisory (not enforced through
|
|
CVS), committers are asked to respect the freeze so that
|
|
the package builds can be consistent and correct, and
|
|
instead clear all proposed changes through portmgr. The
|
|
changes that are generally approved are:</p>
|
|
|
|
<ul>
|
|
<li><p>fixes to make a package build at all;</p></li>
|
|
<li><p>security fixes to critical packages;</p></li>
|
|
<li><p>problems that are noticed with licensing issues.</p></li>
|
|
</ul>
|
|
|
|
<p>Unfortunately, due to the sheer size of the Ports Collection
|
|
and the speed that applications are developed, it is
|
|
impossible to fix every single problem for a release.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The tree is then locked for all commits and a CVS tag is laid
|
|
down.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The tree is then unlocked and a <tt>slush</tt> is
|
|
announced. The intent of this state is to allow routine
|
|
changes to be made to the Ports Collection, but with the note
|
|
that these changes will not ship on the release ISOs. Commits
|
|
that should be avoided are such things as:</p>
|
|
|
|
<ul>
|
|
<li><p>updates to ports with many dependencies, such as X11
|
|
servers, KDE, and GNOME;</p><li>
|
|
|
|
<li><p>repocopies involving multiple ports;</p><li>
|
|
|
|
<li><p>and so forth.</p><li>
|
|
</ul>
|
|
|
|
<p>The reason we want to avoid these commits is if some kind
|
|
of show-stopper problem is found (either security- or license-
|
|
related) such that we need to make a change that can go on
|
|
the release ISOs, we will need to slip the CVS tag on the
|
|
changed file(s). By allowing unlimited commits, the risk is
|
|
high that any such change would involve having to recreate all
|
|
the packages all over again, resulting in an endless release
|
|
cycle.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Only once the RE team and portmgr are happy with the final
|
|
state of the release ISOs is the ports tree completely available
|
|
for commits again.</p>
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
<h3><a name="qa-between-releases">Activities Between Release Cycles</a></h3>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>Manage the <a href="http://pointyhat.FreeBSD.org">Ports Build
|
|
Cluster</a> machines. These machines continually build packages
|
|
on all possible combinations of OS release and CPU architecture
|
|
(in our terminology, <tt>build environments</tt>.)</p>
|
|
|
|
<p>These builds also produce error logs for packages that do not
|
|
build correctly (see the above URL). Periodically, the team
|
|
marks these ports as BROKEN so that maintainers may be notified.
|
|
(See below.)</p>
|
|
|
|
<p>Successfully built packages (at least, the ones that are freely
|
|
redistributable) are also copied to the master FTP server and thus
|
|
become the default "latest package" for installations
|
|
that use packages rather than ports.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Notify the FreeBSD community of problems within the Ports
|
|
Collection so that problems do not get overlooked. To do this,
|
|
there are a number of emailed reports. Ones marked
|
|
<tt>public</tt> are posted to freebsd-ports.</p>
|
|
|
|
<ul>
|
|
|
|
<li><p>a public list of all ports to be removed due to security
|
|
problems, build failures, or general obsolescence, unless they
|
|
are fixed first.</p></li>
|
|
|
|
<li><p>private email to all maintainers of the affected ports
|
|
(including ports dependent on the above).</p></li>
|
|
|
|
<li><p>private email to all maintainers of ports that are already
|
|
marked BROKEN and/or FORBIDDEN.</p></li>
|
|
|
|
<li><p>private email to maintainers who are not committers, who have
|
|
PRs filed against their ports (to flag PRs that might never have
|
|
been Cc:ed to them).</p></li>
|
|
|
|
<li><p>public email about port commits that break building of
|
|
INDEX.</p></li>
|
|
|
|
<li><p>public email about port commits that send the revision
|
|
metadata backwards (and thus confuse tools like portupgrade).</p></li>
|
|
|
|
<li><p>a public list of all ports that have at least one file
|
|
that fails to fetch from any non-FreeBSD mastersite. For the
|
|
complete list of results for all files versus all mastersites,
|
|
see <a href="http://people.FreeBSD.org/~fenner/portsurvey/">
|
|
Bill Fenner's port survey</a>.</p></li>
|
|
|
|
<li><p>private email to an affected port maintainer when a port
|
|
is about to be marked BROKEN, Cc:ed to the last committer to
|
|
the port. (This email is not automated but it should be sent
|
|
as a courtesy.)</p></li>
|
|
|
|
<li><p>a list of ports that do not set NO_LATEST_LINK. (Ports
|
|
that have a stable version, and a development version, will
|
|
generally have the development version set to a later revision.
|
|
If it is desireable that users should install the stable version
|
|
from packages, rather than the development version, this flag
|
|
should be set; otherwise, users will get the latest version by
|
|
default.)</p></li>
|
|
|
|
</ul>
|
|
|
|
</li>
|
|
|
|
<li>
|
|
<p>Remove expired ports. Ports that have been marked BROKEN for
|
|
some time are marked DEPRECATED (with an EXPIRATION_DATE) and then
|
|
are removed if no one has fixed them by that time. The intent of
|
|
this this process is to try to insure that if a user installs a port,
|
|
there is the best possible change that it can be made to work.</p>
|
|
|
|
<p>In other cases, ports are marked DEPRECATED when they have been
|
|
replaced by a newer version and the older version is no longer
|
|
maintained by the authors. The EXPIRATION_DATE should generally
|
|
be set at least two months in the future to allow everyone sufficient
|
|
time to upgrade.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
&footer;
|
|
</body>
|
|
</html>
|