ALFS team mini-manifesto
Kevin P. Fleming
kpfleming at linuxfromscratch.org
Sat Jan 31 16:08:39 PST 2004
Has been read approved by the team members and other interested parties.
--- snip ---
Function: The team provides an automated system building tool (nALFS)
and official build profiles for certain LFS-related projects.
Scope: The team supports
- development of functionality needed in the nALFS code-base to
fully support "official" profile needs;
- development of "official" profiles that use the code-base, for
support of LFS-based products;
- automated builds of "standard" LFS-based systems by both end-users
and the LFS testing team using the supported "official" profiles.
Bounds: the team makes no commitment to support profiles or code-base
functionality that is not required by the supported LFS project
books, although reasonable efforts to support "non-standard" needs
may be considered.
Goals: The team's major objectives for the product are to
- provide an up-to-date LFS official profile at all times;
- address reported bugs in a timely manner;
- support nALFS users with resolution of problems and questions;
- produce a tool that enables easy, consistent and reliable builds;
- ensure "official" profiles track book development as closely as
Strategy: The ALFS team uses many tools to help accomplish its goals,
including the LFS Bugzilla system and the alfs-discuss mailing list.
Use of these tools allows for effective and timely communication
between the team members, and between the team and the ALFS user
community. We try to ensure that all team communications are done
using public media, so that all interested parties can participate.
The team produces the end-product using two internal groups to
develop the two major portions of ALFS. One group maintains the
code-base, providing functionality needed in the profiles, and the
other develops the profiles, which use that code-base, that are
available to build LFS-based systems.
The nALFS source tree will be kept in the LFS CVS system and all
developers will ensure that the CVS HEAD branch is kept in
compilable and usable state.
The official LFS profile is also kept in the LFS CVS system, and
should also always be kept in a usable state.
Logistics: The team's strategy is implemented as follows.
The profile developers:
- respond to problem reports from any source;
- communicate amongst themselves to ensure that each LFS book
update is handled expediently without duplication of effort;
- use the alfs-discuss mailing list to conduct discussions related
to handling of major book updates (which may create a need for
changes to the profile outside the commands and instructions
contained in the book) so that the users of the profile can be
aware of the pending changes and voice their opinions and concerns
before a final decision is made.
The code-base developers:
- manage activities by effective use of Bugzilla to track to-do
- check Bugzilla to ensure no one else is already working on an item
before beginning work on it;
- assign the item to themselves so others can see the item is being
worked on when they check Bugzilla;
- notify other developers, in advance via the alfs-discuss mailing
list (so that any conflicts can be resolved before time is lost),
a) when the changes to nALFS will affect a large portion of the
source tree, or b) would negatively impact other developers by
forcing them to re-do their work (or suffer through a complicated
The team will:
- thoroughly test all check-ins on the developer's system,
- post an RFC (request for comments) patch to the alfs-discuss
mailing list so that others can test it prior to CVS commit, if
the developer has concerns that their changes may have negative
effects (due to size of changes or for any reason) on the
state of CVS (e.g. incorrect results if HEAD is used);
- update the Bugzilla entry with the appropriate resolution (i.e.
"change committed to CVS", "change incorporated with entry #xxx",
etc.) and change its status to FIXED when a developer thinks that
they have completed the work to resolve a Bugzilla entry;
- have another developer change the status of the entry to VERIFIED
when he has confirmed that the problem/enhancement has been
successfully dealt with;
- change status to CLOSED when an official nALFS release
incorporating the changes is produced.
- the ALFS profile maintenance team has the final decision making
authority regarding profile content and construction;
- profiles must always match the LFS book as closely as possible,
even if that means producing an ALFS profile that is less
efficient or effective than it could be;
- nALFS will not become a complete distribution maintenance tool,
nor take on any other significant administrative functions
- beta releases will be made available and announced whenever a
major change to the code-base, profiles or LFS book occurs.
More information about the website