[RFC] ALFS team mini-manifesto

Kevin P. Fleming kpfleming at linuxfromscratch.org
Mon Jan 26 08:26:39 PST 2004

Please read and comment (on this list only please)... in a few days I 
will collect the comments, address any issues raised and get this 
forwarded to the website team for posting. Thanks!

--- 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
     - ensure the book's build instructions produce usable systems;
     - 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 mediums, 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 implement 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 alfs-discuss mailing list