'\" t
.\"	aegis - project change supervisor
.\"	Copyright (C) 1991-1993, 1995, 1996, 1998, 1999, 2001 Peter Miller;
.\"	All rights reserved.
.\"
.\"	This program is free software; you can redistribute it and/or modify
.\"	it under the terms of the GNU General Public License as published by
.\"	the Free Software Foundation; either version 2 of the License, or
.\"	(at your option) any later version.
.\"
.\"	This program is distributed in the hope that it will be useful,
.\"	but WITHOUT ANY WARRANTY; without even the implied warranty of
.\"	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
.\"	GNU General Public License for more details.
.\"
.\"	You should have received a copy of the GNU General Public License
.\"	along with this program; if not, write to the Free Software
.\"	Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111, USA.
.\"
.\" MANIFEST: description of aegis project attribute file format
.\"
.so z_name.so
.TH aepattr 5 \*(N) "Reference Manual"
.SH NAME
aepattr - project attribute file
.XX "aepattr(5)" "project attribute file format"
.SH DESCRIPTION
The
project attribute
file is used to store modifiable information about a project.
.SH CONTENTS
.TP 8n
description = string;
This field contains
a description of the project.
Large amounts of prose are not required;
a single line is sufficient.
.TP 8n
developer_may_review = boolean;
.RS
If this field is true, then a developer may review her own change.
This is probably only a good idea for projects of less than 3 people.
The idea is for as many people as possible to critically examine a change.
.PP
Note that the \fIdevelop_\%end_\%action\fP field may not contradict
the \fIdeveloper_\%may_\%review\fP field.  If developers may not review
their own work, then their changes may not goto directly to the \fIbeing
integrated\fP state (as this means much the same thing).
.RE
.TP 8n
developer_may_integrate = boolean;
If this field is true, then a developer may integrate her own change.
This is probably only a good idea for projects of less than 3 people.
The idea is for as many people as possible to critically examine a change.
.TP 8n
reviewer_may_integrate = boolean;
If this field is true, then a reviewer may integrate a change she reviewed.
This is probably only a good idea for projects of less than 3 people.
The idea is for as many people as possible to critically examine a change.
.TP 8n
developers_may_create_changes = boolean;
This field is true if developers may created changes,
in addition to administrators.
This tends to be a very useful thing,
since developers find most of the bugs.
.TP 8n
forced_develop_begin_notify_command = string;
.RS
This command is used to notify a developer
that a change requires developing;
it is issued when a project administrator uses an
.I "aedb -User"
command to force development of a change by a specific user.
All of the substitutions described in
.IR aesub (5)
are available.
This field is optional.
.PP
Executed as: the new developer.
Current directory: the development directory of the change
for the new developer.
Exit status: ignored.
.RE
.TP 8n
develop_end_notify_command = string;
.RS
This command is used to
notify that a change is ready for review.
It will probably use mail,
or it could be an in-house bulletin board.
This field is optional,
if not present no notification will be given.
This command could also be used to notify other management systems,
such as progress and defect tracking.
All of the substitutions described by
.IR aesub (5)
are available.
.PP
Executed as: the developer.
Current directory: the development directory of the change.
Exit status: ignored.
.RE
.TP 8n
develop_end_undo_notify_command = string;
.RS
This command is used to
notify that a change had been withdrawn from review
for further development.
It will probably use mail,
or it could be an in-house bulletin board.
This field is optional,
if not present no notification will be given.
This command could also be used to notify other management systems,
such as progress and defect tracking.
All of the substitutions described by
.IR aesub (5)
are available.
.PP
Executed as: the developer.
Current directory: the development directory of the change.
Exit status: ignored.
.RE
.TP 8n
review_begin_notify_command = string;
.RS
This command is used to
notify that a review has begun.
It will probably use mail,
or it could be an in-house bulletin board.
This field is optional,
if not present no notification will be given.
This command could also be used to notify other management systems,
such as progress and defect tracking.
All of the substitutions described by
.IR aesub (5)
are available.
.PP
Executed as: the reviewer.
Current directory: the development directory of the change.
Exit status: ignored.
.RE
.TP 8n
review_begin_undo_notify_command = string;
.RS
This command is used to
notify that a review is no longer in progress, the reviewer has withdrawn.
It will probably use mail,
or it could be an in-house bulletin board.
This field is optional,
if not present no notification will be given.
This command could also be used to notify other management systems,
such as progress and defect tracking.
All of the substitutions described by
.IR aesub (5)
are available.
.PP
Executed as: the reviewer.
Current directory: the development directory of the change.
Exit status: ignored.
.RE
.TP 8n
review_pass_notify_command = string;
.RS
This command is used to
notify that a review has passed.
It will probably use mail,
or it could be an in-house bulletin board.
This field is optional,
if not present no notification will be given.
This command could also be used to notify other management systems,
such as progress and defect tracking.
All of the substitutions described by
.IR aesub (5)
are available.
.PP
Executed as: the reviewer.
Current directory: the development directory of the change.
Exit status: ignored.
.RE
.TP 8n
review_pass_undo_notify_command = string;
.RS
This command is used to
notify that a review has passed.
It will probably use mail,
or it could be an in-house bulletin board.
This field is optional,
if not present no notification will be given.
This command could also be used to notify other management systems,
such as progress and defect tracking.
Defaults to the same action as the \fIdevelop_end_notify_command\fP field.
All of the substitutions described by
.IR aesub (5)
are available.
.PP
Executed as: the reviewer.
Current directory: the development directory of the change.
Exit status: ignored.
.RE
.TP 8n
review_fail_notify_command = string;
.RS
This command is used to
notify that a review has failed.
It will probably use mail,
or it could be an in-house bulletin board.
This field is optional,
if not present no notification will be given.
This command could also be used to notify other management systems,
such as progress and defect tracking.
All of the substitutions described by
.IR aesub (5)
are available.
.PP
Executed as: the reviewer.
Current directory: the development directory of the change.
Exit status: ignored.
.RE
.TP 8n
integrate_pass_notify_command = string;
.RS
This command is used to
notify that an integration has passed.
It will probably use mail,
or it could be an in-house bulletin board.
This field is optional,
if not present no notification will be given.
This command could also be used to notify other management systems,
such as progress and defect tracking.
All of the substitutions described by
.IR aesub (5)
are available.
.PP
Executed as: the project owner.
Current directory: the new project baseline.
Exit status: ignored.
.RE
.TP 8n
integrate_fail_notify_command = string;
.RS
This command is used to
notify that an integration has failed.
It will probably use mail,
or it could be an in-house bulletin board.
This field is optional,
if not present no notification will be given.
This command could also be used to notify other management systems,
such as progress and defect tracking.
All of the substitutions described by
.IR aesub (5)
are available.
.PP
Executed as: the integrator.
Current directory: the development directory of the change.
Exit status: ignored.
.RE
.TP 8n
default_development_directory = string;
The pathname of where to place new development directories.
The pathname must be absolute.
This field is only consulted if
the field of the same name in the user configuration file is not set.
.TP 8n
umask = integer;
.br
File permission mode mask.
See
.IR umask (2)
for more information.
This value will always be OR'ed with 022,
because
.I aegis
is paranoid.
.TP 8n
default_test_exemption = boolean;
.br
This field contains what to do when a change is created with
no test exemption specified.
.TP 8n
minimum_change_number = integer;
The minimum change number for
.IR aenc(1),
if no change number is specified.
This allows the low-numbered change numbers to be
used for branches later in the project.
.TP 8n
reuse_change_numbers = boolean; 
This controls whether the automatically selected
.IR aenc (1)
change numbers ``fill in'' any gaps.
Defaults to true if not set.
.TP 8n
minimum_branch_number = integer;
The minimum branch number for
.IR aenbr(1),
if no branch number is specified.
Defaults to 1 if not set.
.TP 8n
skip_unlucky = boolean;
This field may be set to true if you want to skip various unlucky
numbers for changes, branches and tests.  Various traditions are
avoided, both Eastern and Western.  Defaults to false if not set.
.TP 8n
compress_database = boolean;
.RS
This field may be set to true if you want to compress the database on
writing.  (It is always uncompressed on reading if necessary.)  Defaults to
false if not set.
.PP
Unless you have an exceptionally large project, coupled with fast CPUs
and high network latency, there is probably very little benefit in
using this feature.  (The database is usually less than 5% of the size
of the repository.)  On slow networks, however, this can improve the
preformance of file-related commands.
.RE
.TP 8n
develop_end_action = ( ...);
.RS
This field controls the state the change enters after a successful
\fIaede\fP(1) action.
.TP 8n
.I goto_being_reviewed
This means that the change goes from the \fIbeing_\%developed\fP state
to the \fIbeing_\%reviewed\fP state.  The \fIaerb\fP(1) command only
sends informative email.
.TP
.I goto_awaiting_review
This means that the change goes from the \fIbeing_\%developed\fP state
to the \fIawaiting_\%review\fP state.  The \fIaerb\fP(1) command is
now mandatory.
.TP 8n
.I goto_awaiting_integration
This means that the change goes from the \fIbeing_\%developed\fP
state into the \fIawaiting_\%integration\fP state.  Code review is
skipped entirely.
If the \fIdeveloper_\%may_\%review\fP is false, it is not possible to
use this setting.
.PP
Note that the \fIdevelop_\%end_\%action\fP field may not contradict
the \fIdeveloper_\%may_\%review\fP field.  If developers may not review
their own work, then their changes may not goto directly to the \fIbeing
integrated\fP state (as this means much the same thing).
A contradictory setting will be replaced with \fIgoto_\%being_\%reviewed\fP.
.RE
.SH SEE ALSO
.TP 8n
.IR aepa (1)
modify the attributes of a project
.TP 8n
.IR aegis (5)
\*(n) file format syntax
.TP 8n
.IR aecattr (5)
change attributes file format
.TP 8n
.IR aecstate (5)
change state file format, particularly as branches
are used to remember most project state
.TP 8n
.IR aepstate (5)
project state file format
.so ../man1/z_cr.so