diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository.ent b/Documentation/Models/Docbook/Tcar-ug/Repository.ent
index 8e7526f..d47213b 100644
--- a/Documentation/Models/Docbook/Tcar-ug/Repository.ent
+++ b/Documentation/Models/Docbook/Tcar-ug/Repository.ent
@@ -1,16 +1,15 @@
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions.docbook
deleted file mode 100644
index 71f68f8..0000000
--- a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions.docbook
+++ /dev/null
@@ -1,16 +0,0 @@
-
-
- Repository Convenctions
-
- &repo-convs-mission;
- &repo-convs-layout;
- &repo-convs-worklines;
- &repo-convs-filenames;
- &repo-convs-relbdirs;
- &repo-convs-syncpaths;
- &repo-convs-extending;
- &repo-convs-publishing;
- &repo-convs-authoring;
- &repo-convs-copying;
-
-
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/authoring.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/authoring.docbook
deleted file mode 100755
index 06a4394..0000000
--- a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/authoring.docbook
+++ /dev/null
@@ -1,30 +0,0 @@
-
-
- Repository Authoring
-
-
- The content produced inside &TCAR; is copyright of &TCP;.
- This is something you, as author, should be aware of because
- you are contributing your creation's rights to someone else;
- &TCP; in this case. This way, your work is distributed using
- &TCP; as copyright holder, not your name (even
- you remain as natural author of the work). Because &TCP; is
- the copyright holder, is the license chosen by &TCP; the one
- applied to your work, so it is the one you need to agree with
- before making a creation inside &TCAR;.
-
-
-
- &TCP; is a community project controlled by its own community
- of users. Inside the community, The CentOS Administrators
- group is the higher authority and the only one able to set
- core desition like the kind of license used inside the project
- and subprojects like &TCAR;.
-
-
-
- The redistribution conditions of &TCAR; are described in .
-
-
-
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/copying.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/copying.docbook
deleted file mode 100755
index 6ecabc2..0000000
--- a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/copying.docbook
+++ /dev/null
@@ -1,60 +0,0 @@
-
-
- Repository Copying Conditions
-
-
- &TCP; uses &TCAR; to produce &TCP; corporate visual identity.
-
-
-
- The &TCAR; is not in the public domain; it is copyrighted and
- there are restrictions on their distribution, but these
- restrictions are designed to permit everything that a good
- cooperating citizen would want to do. What is not allowed is
- to try to prevent others from further sharing any version of
- this work that they might get from you.
-
-
-
- Specifically, we want to make sure that you have the right to
- give away copies of &TCAR;, that you receive source code or
- else can get it if you want it, that you can change this work
- or use pieces of it in new free works, and that you know you
- can do these things.
-
-
-
- To make sure that everyone has such rights, we have to forbid
- you to deprive anyone else of these rights. For example, if
- you distribute copies of the &TCAR;, you must give the
- recipients all the rights that you have. You must make sure
- that they, too, receive or can get the source code. And you
- must tell them their rights.
-
-
-
- Also, for our own protection, we must make certain that
- everyone finds out that there is no warranty for the &TCAR;.
- If this work is modified by someone else and passed on, we
- want their recipients to know that what they have is not what
- we distributed, so that any problems introduced by others will
- not reflect on our reputation.
-
-
-
- The &TCAR; is released as a GPL work. Individual packages
- used by &TCAR; include their own licenses and the &TCAR;
- license applies to all packages that it does not clash with.
- If there is a clash between the &TCAR; license and individual
- package licenses, the individual package license applies
- instead.
-
-
-
- The precise conditions of the license for the &TCAR; are found
- in . This manual specifically
- is covered by the conditions found in .
-
-
-
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/extending.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/extending.docbook
deleted file mode 100644
index a270e5a..0000000
--- a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/extending.docbook
+++ /dev/null
@@ -1,44 +0,0 @@
-
-
- Extending Repository Layout
-
-
- Occasionly, you may find that new components of &TCPCVI; need
- to be added to the repository in order to work them out. If
- that is the case, the first question we need to ask ourselves,
- before starting to create directories blindly all over, is:
- What is the right place to store it?
-
-
-
- To build a directory structure inside the repository you need
- to define the concept behind it first. Later you need to
- create a new directory inside the repository, remembering that
- there are locations inside the repository that already define
- concepts you probably would prefer to reuse. For example, the
- Identity/Images/Themes
- directory stores artistic motifs of different themes, the
- Identity/Models/Themes
- directory stores design models for themes, the Manuals directory stores
- documentation, the Locales stores translation
- messages, and the Scripts stores automation
- scripts.
-
-
-
- The best suggestion we can probably give you would be to send
- a mail with your questions to the CentOS developers mailing
- list (centos-devel@centos.org).
- This is the place where development of &TCAR; takes place and
- surely, in community, it will be possible to find a place for
- your new component inside the repository.
-
-
-
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/filenames.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/filenames.docbook
deleted file mode 100644
index c43fada..0000000
--- a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/filenames.docbook
+++ /dev/null
@@ -1,185 +0,0 @@
-
-
- Repository File Names
-
-
- Regular Files
-
-
- Inside &TCAR;, file names are always written in lowercase.
- Digits (e.g., 0, 1, 2), hyphen (-), dot
- (.) and low line (_)
- characters are also accepted. In case you use hyphen and dot
- characters, don't use them as first character in the file
- name.
-
-
-
- Files Written Correctly
-
- The following file names are written correctly:
-
-
-
-
- 01-welcome.png
-
-
-
-
- splash.png
-
-
-
-
- anaconda_header.png
-
-
-
-
-
-
- Files Written Incorrectly
-
- The following file names are written incorrectly:
-
-
-
-
- 01-Welcome.png
-
-
-
-
- -welcome.png
-
-
-
-
- Splash.png
-
-
-
-
- AnacondaHeader.png
-
-
-
-
-
-
- Exceptions
-
- When you name files, consider the following exceptions:
-
-
-
-
- In the very specific case of repository documentation entries
- written in Texinfo format, file names follow the directory
- structure naming convenction. This is because they are
- documenting directories and that is something
- we want to remark. So, to better describe what we are
- documenting, files related to documentation entries follow the
- name convenction used by the item they document.
-
-
-
-
-
-
-
-
-
- Symbolic Links
-
- Inside &TCAR;, symbolic link names follow the same
- convenctions described in .
-
-
-
-
- Directories
-
- Inside &TCAR;, directory names are all written capitalized and
- sometimes in cammel case. Digits (e.g., 0, 1, 2), hyphen
- (-), dot (.) and low line
- (_) characters are also accepted. In case you
- use hyphen and dot characters, don't use them as first
- character in the directory name.
-
-
-
- Directories Written Correctly
-
- The following directory names are written correctly:
-
-
-
-
- Identity,
- Themes,
- Motifs,
- TreeFlower
-
-
-
-
- Tcar-ug
-
-
-
-
- 0.0.1, 0.0.1-35
-
-
-
-
-
-
- Directories Written Incorrectly
-
- The following directory names are written incorrectly:
-
-
-
-
- identitY,
- theMes,
- MOTIFS,
- treeFlower
-
-
-
-
- tcar-ug
-
-
-
-
- .0.1, .0.1-35
-
-
-
-
-
-
- Exceptions
-
- When you name directories, consider the following exceptions:
-
-
-
-
- No one so far.
-
-
-
-
-
-
-
-
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/layout.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/layout.docbook
deleted file mode 100644
index e651a73..0000000
--- a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/layout.docbook
+++ /dev/null
@@ -1,69 +0,0 @@
-
-
- Repository Layout
-
-
- &TCAR; is made of one central repository and
- many working copies of that central repository.
- The working copies are independent one another, can be
- distributed all around the world and provide a local place for
- designers, documenters, translators and programmers to perform
- their work in a decentralized way. The central repository, on
- the other hand, provides a common place for all independent
- working copies to interchange data in the community.
-
-
-
- The current infrastructure that holds &TCAR; is supported by
- Subversion,
- a version control system which allows you to keep old versions
- of files and directories (usually source code), keep a log of
- who, when, and why changes occurred, etc., like CVS, RCS or
- SCCS and Trac,
- a web-based software project management and bug/issue tracking
- system emphasizing ease of use and low ceremony.
-
-
-
- In addition to current Subversion infrastructure, we are
- working on a Git infrastructure with the intention of
- migrating the central repository to it, progressively. Here we
- use Gitolite to manage Git repositories, Gitweb to make
- changes browsable through the web and Mantis to track
- repository issues. The main reason for this migration is to
- take advantage of distributed version control system inside
- &TCAR;. It also let people to commit changes locally, without
- any network access, and later push local commits up to central
- repository, when the network access be re-established. This
- could be very useful in very different kind of situations.
-
-
-
- Subversion
-
-
- In this layout, the first level of directories inside &TCAR;
- provides the Subversion's standard trunk-branches-tags layout.
- The second level of directories provides organization for
- different work lines, as described in . All other subsequent
- directory levels from second level
- on exist to organize specific concepts related to the work
- line they belong to.
-
-
-
-
-
- Git
-
- In this layout, the first level of directories provides
- organization for different work lines, as described in . All other subsequent
- directory levels from second level on exist to organize
- specific concepts related to the work line they belong to.
-
-
-
-
-
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/mission.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/mission.docbook
deleted file mode 100755
index 32c6a9d..0000000
--- a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/mission.docbook
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
- Repository Mission
-
-
- &TCAR; exists to produce &TCP; corporate visual identity.
-
-
-
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/publishing.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/publishing.docbook
deleted file mode 100755
index 71bcd14..0000000
--- a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/publishing.docbook
+++ /dev/null
@@ -1,59 +0,0 @@
-
-
- Repository Publishing
-
-
- When you perform changes inside your working copy, those
- changes are local to your working copy only. In order for you
- to share your changes with others, you need to commit them up
- to the central repository the working copy you are using was
- initially downloaded from. To commit your changes up to the
- central repository you use the commit
- command from the Subversion's client you've installed in your
- workstation.
-
-
-
- Initially, when you get registered inside &TCAR;, you won't be
- able to publish your changes to &TCAR; immediatly. It is
- necessary that you prove your interest in contributing first
- sending a mail to the CentOS
- Developers mailing list (centos-devel@centos.org),
- preferably in conjunction with a description of the changes
- you pretend to commit. This restriction is necessary in order
- to protect the source repository from spammers.
-
-
-
- Once you've received access to publish your changes, they will
- remain valid to you and there is no need for you to request
- permission to publish new changes as long as you behave as a
- good cooperating citizen.
-
-
-
- As a good cooperating citizen one understand of a person who
- respects the work already done by others and share ideas with
- authors before changing relevant parts of their work,
- specially in situations when the access required to realize
- the changes has been granted already. Of course, there is a
- time when conversation has taken place, the paths has been
- traced and changing the work is so obvious that there is no
- need for you to talk about it; that's because you already did,
- you already built the trust to keep going. As complement, the
- mailing list mentioned above is available for sharing ideas in
- a way that good relationship between community citizens could
- be constantly balanced.
-
-
-
- The relationship between community citizens is monitored by
- repository administrators. Repository administrators are
- responsible of granting that everything goes the way it needs
- to go in order for &TCAR; to accomplish its mission (see ).
-
-
-
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/relbdirs.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/relbdirs.docbook
deleted file mode 100644
index 835f241..0000000
--- a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/relbdirs.docbook
+++ /dev/null
@@ -1,157 +0,0 @@
-
-
- Repository Path Relations
-
-
- In order for automation scripts to produce content inside a
- working copy of &TCAR;, it is required that all work lines be
- related somehow. The automation scripts take the relation
- between work lines as reference to determine the place the
- information they will work with will be retrieve from (e.g.,
- scalable vector graphics, documentation, translations, etc.),
- as well as the place where it will store the final files
- produced as result of automation process (e.g., portable
- network graphics, documentation ready for printing and reading
- online, etc.).
-
-
- In order to implement the relation between work lines it is
- required to establish a path name convenction, so we can
- conceptually organize different components and relate them one
- another using predictable path constructions in a scalable
- way. Based on this need, we identify three different path
- types inside &TCAR;. These path types are: Output
- Paths, Input Paths, and
- Auxiliary Paths.
-
-
-
- Output Paths
-
-
- The output paths point to directories inside the working copy
- which contain files produced from files inside the input
- paths. For example, the following paths are consider as output
- paths:
-
-
-
-
-
- Identity/Images/Brands/
-
-
-
-
- Documentation/Manuals/Tcar-ug/
-
-
-
-
- Identity/Images/Themes/Modern/2/Distro/5/Anaconda/
-
-
-
-
-
- Output paths are also known as Render-able
- Directories because they are the type of
- path you should provide as argument to functionality so as to
- produce content through it.
-
-
-
-
-
- Input Paths
-
- The input paths point to a directories inside the working copy
- which contain files used to produce files inside output paths.
- For example, the following paths are considered as input
- paths:
-
-
-
-
-
- Identity/Models/Brands/
-
-
-
-
- Documentation/Models/Tcar-ug/
-
-
-
-
- Identity/Models/Themes/Default/Distro/5/Anaconda/
-
-
-
-
-
-
- Auxiliary Paths
-
-
- The auxiliary paths point to directories inside the working
- copy which contain files used to create modified instances of
- inside input paths which are use in turn to produce files
- inside output paths. For example, the following paths are
- considered as auxiliary paths:
-
-
-
-
-
- Identity/Images/Brands/
-
-
-
-
- Locales/Documentation/Models/Docbook/Tcar-ug/es_ES/
-
-
-
-
- Locales/Identity/Models/Themes/Default/Distro/5/Anaconda/es_ES/
-
-
-
-
-
- The relationship between input, output and auxiliary paths is
- created by combining the first directory level of input paths
- with the first directory level in the repository directory
- layout. In the repository directory layout, the first level
- includes the Identity,
- Documentation and
- Scripts directories.
- These directories are always used to create input and output
- paths. The Locales
- directory, on the other hand, is always used to create
- auxiliary paths only for input paths available under Identity, Documentation and Scripts directories.
-
-
-
- For example, if the LANG environment
- variable is set to es_ES.UTF-8 and you execute
- the functionality of
- centos-art.sh script with the Documentation/Manuals/Docbook/Tcar-ug/
- input path as argument, it will produce &TCARUG; in Spanish
- language using translation messages from
- Locales/Documentation/Models/Docbook/Tcar-ug/es_ES/
- auxiliary path and would save final documentation files under
- Documentation/Manuals/Docbook/Tcar-ug/es_ES/
- output path.
-
-
-
-
-
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/syncpaths.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/syncpaths.docbook
deleted file mode 100644
index d8e353d..0000000
--- a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/syncpaths.docbook
+++ /dev/null
@@ -1,99 +0,0 @@
-
-
- Syncronizing Repository Paths
-
-
- Once both master and auxiliar paths have been related in the
- repository, they shouldn't be changed except you absolutly
- need to do so. In this cases, when you need to change master
- or auxiliar paths, it is required that you also change the
- relation between them so as to retain their bond. This
- process of keeping master and auxiliar paths
- connected between themselves is known as
- path syncronization.
-
-
-
- Path syncronization is required for automation scripts to know
- where to store final output, where to retrive translation
- messages from, and whatever information you might need to
- count with. If the relation between master paths and auxiliar
- paths is lost, there is no way for automation scripts to know
- where to retrive the information they need to work with or
- where to store the output information produced from it.
- Through path syncronization we organize and extend the content
- production inside the repository.
-
-
-
- Path syncronization affects both movement of files and
- replacement of content inside files. Movement of files is
- related to actions like renaming files and directories inside
- the repository. Replacement of content inside files is
- related to actions like replacing information (e.g., paths
- information) inside files in order to keep file contents and
- file locations consistent one another after a file has been
- moved.
-
-
-
- The order followed to syncronize path information is very
- important because the versioned nature of the files we are
- working with. When a renaming action needs to be performed
- inside the repository, we avoid making replacements inside
- files first and file movements later. This would demand two
- commit actions: one for the files' internal changes and
- another for the file movement itself. Instead, we prefer to
- perform file movements first and files' internal replacements
- later. This way it is possible to commit both changes as if
- they were just one.
-
-
-
-
- There is no support for URLs actions inside
- centos-art.sh script. The
- centos-art.sh script is designed to work
- with local files inside the working copy only. If you need to
- perform URL actions directly, use Subversion's commands
- instead.
-
-
-
-
- At this moment there isn't full implementation of path
- syncronization inside centos-art.sh script
- and that is somthing we need to do oursleves. However, the
- texinfo backend inside the
- help functionality does provide a restricted
- implementation of path syncronization to documentation area
- through the ,
- and options. You can read this
- implementation and use it as reference to implement path
- syncronization in other areas.
-
-
-
- The plan for a full implementation of path syncronization
- inside centos-art.sh script would be to
- create individual restricted implementations like the one in
- texinfo backend for other areas that demand it
- and then, create a higher implmentation that combines them all
- as needed. This way, if we try to rename a repository
- directory, the higher action can know which are all the
- restricted actions that should be performed in order
- to make the full path syncronization.
-
-
-
- For example, if the directory we are renaming is a master
- path, it is required to syncronize the related output and
- localization auxiliar paths. On the other hand, if the
- directory we are renaming through full path syncronization is
- an auxiliar path, it is required to determine first what is
- the related master path and later, perform the syncronization
- from master path to auxiliar paths as if the path provided
- would be the master path not the auxiliar path.
-
-
-
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/worklines.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/worklines.docbook
deleted file mode 100644
index 094f1bd..0000000
--- a/Documentation/Models/Docbook/Tcar-ug/Repository/Convenctions/worklines.docbook
+++ /dev/null
@@ -1,183 +0,0 @@
-
-
- Repository Work Lines
-
-
- The content production inside &TCAR; has been divided into
- individual work lines that relate one another based on the
- idea of doing one thing well. In this model, the content
- produced individually by each work line is combined one
- another later to achieve higher purposes (e.g., corporate
- identity for &TCP;). The repository work lines, as conceived
- here, provide a relaible environment for people to work
- syncronized and descentralized.
-
-
-
- The action of combining work lines inside &TCAR; is known as
- the corporate identity production cycle. The rest of this
- section describes the work lines available in the repository
- and how they fit inside the corporate identity production
- cycle.
-
-
-
-
- Visual Identity
-
-
- The visual identity is the first component we work out in
- order to produce a new corporate identity. Through this work
- line, graphic designers create models and
- motifs for all the visual manifestation &TCP;
- is made of. Once design models and artistic motifs are set in
- place, graphic designers use the render
- functionality described in to combine both design models and artistic motifs into
- final images.
-
-
-
- The main purposes of this work line is define all the visual
- manifestations the &TCP; is made of and provide design models
- and artistic motifs for them in order to render the set of
- images required to transmit the visual style that identifies
- &TCP; as unique organization. To know more about &TCPCVI;,
- read .
-
-
-
- The visual identity work line takes palce in the Identity directory.
-
-
-
-
-
-
-
- Localization
-
-
- The content localization is the second component that must be
- worked out in the corporate identity production cycle.
- Through this work line translators localize source files
- (e.g., SVG, DocBook, Shell scripts) which are later use to
- produce localized images, localized documentation and
- localized automation scripts. To localize source files,
- translators use
- the locale functionality described in
- which takes care of
- retriving translatable strings from source files and provide a
- consistent localization interface based on GNU
- gettext multi-lingual message
- production tool set and xml2po command.
-
-
-
- The main purpose of this work line is extend the visual
- identity (produced in English language) to as many native
- languages as possible in order for people which doesn't
- understand English languague to feel more confortable with
- &TCP; and its messages. To know more about the specific
- localization process read .
-
-
-
- The localization work line takes palce in the Locales directory.
-
-
-
-
-
-
- Documentation
-
-
- The documentation work line is the third component that must
- be worked out in the corporate identity production cycle.
- Through this work line documentors settle down the conceptual
- and practical used to edificate &TCAR;. To write
- documentation, documentors use the help
- functionality described in which provides a consistent interface for building
- documentation through different documentation backends (e.g.,
- Texinfo, DocBook, LaTeX, etc.).
-
-
-
- The main purpose of this work line is describe the standard
- procedures &TCAR; realies on, as well as conceive a place to
- help you understand what &TCAR; is and what can you do with
- it.
-
-
-
- The documentation work line takes palce in the Manuals directory.
-
-
-
-
-
- Packaging
-
-
- The packaging work line is the fourth component that must be
- worked out in the corporate identity production cycle. Through
- this work line packager gather final images, final
- translations and final documentation related to art works and
- put all together inside RPM packages. For this purpose,
- packagers use the pack describe in
- which provides a
- consistent interface for building packages inside the
- repository.
-
-
-
- The main purpose of this work line is pack all the information
- &TCP; requires to rebrand &TCD; according Red Hat
- redistribution guidelines.
-
-
-
- The packaging work line takes palce in the Packages directory.
-
-
-
-
-
-
- Automation
-
-
- The automation work line is the fifth and last component that
- must be worked out in the corporate identity production cycle.
- This work line closes the production cycle and provides the
- production standards graphic designers, documentors,
- translators and packagers need to make their work consistent
- and reusable. For this purpose, programmers develop the
- centos-art.sh script described in .
-
-
-
- The main purpose of this work line is standardize the
- interaction of work lines in a reliable way.
-
-
-
- The automation work line takes palce in the Scripts directory.
-
-
-
-
-
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions.docbook
new file mode 100644
index 0000000..f85e960
--- /dev/null
+++ b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions.docbook
@@ -0,0 +1,16 @@
+
+
+ Repository Conventions
+
+ &repo-convs-mission;
+ &repo-convs-layout;
+ &repo-convs-worklines;
+ &repo-convs-filenames;
+ &repo-convs-relbdirs;
+ &repo-convs-syncpaths;
+ &repo-convs-extending;
+ &repo-convs-publishing;
+ &repo-convs-authoring;
+ &repo-convs-copying;
+
+
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/authoring.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/authoring.docbook
new file mode 100755
index 0000000..06a4394
--- /dev/null
+++ b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/authoring.docbook
@@ -0,0 +1,30 @@
+
+
+ Repository Authoring
+
+
+ The content produced inside &TCAR; is copyright of &TCP;.
+ This is something you, as author, should be aware of because
+ you are contributing your creation's rights to someone else;
+ &TCP; in this case. This way, your work is distributed using
+ &TCP; as copyright holder, not your name (even
+ you remain as natural author of the work). Because &TCP; is
+ the copyright holder, is the license chosen by &TCP; the one
+ applied to your work, so it is the one you need to agree with
+ before making a creation inside &TCAR;.
+
+
+
+ &TCP; is a community project controlled by its own community
+ of users. Inside the community, The CentOS Administrators
+ group is the higher authority and the only one able to set
+ core desition like the kind of license used inside the project
+ and subprojects like &TCAR;.
+
+
+
+ The redistribution conditions of &TCAR; are described in .
+
+
+
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/copying.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/copying.docbook
new file mode 100755
index 0000000..6ecabc2
--- /dev/null
+++ b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/copying.docbook
@@ -0,0 +1,60 @@
+
+
+ Repository Copying Conditions
+
+
+ &TCP; uses &TCAR; to produce &TCP; corporate visual identity.
+
+
+
+ The &TCAR; is not in the public domain; it is copyrighted and
+ there are restrictions on their distribution, but these
+ restrictions are designed to permit everything that a good
+ cooperating citizen would want to do. What is not allowed is
+ to try to prevent others from further sharing any version of
+ this work that they might get from you.
+
+
+
+ Specifically, we want to make sure that you have the right to
+ give away copies of &TCAR;, that you receive source code or
+ else can get it if you want it, that you can change this work
+ or use pieces of it in new free works, and that you know you
+ can do these things.
+
+
+
+ To make sure that everyone has such rights, we have to forbid
+ you to deprive anyone else of these rights. For example, if
+ you distribute copies of the &TCAR;, you must give the
+ recipients all the rights that you have. You must make sure
+ that they, too, receive or can get the source code. And you
+ must tell them their rights.
+
+
+
+ Also, for our own protection, we must make certain that
+ everyone finds out that there is no warranty for the &TCAR;.
+ If this work is modified by someone else and passed on, we
+ want their recipients to know that what they have is not what
+ we distributed, so that any problems introduced by others will
+ not reflect on our reputation.
+
+
+
+ The &TCAR; is released as a GPL work. Individual packages
+ used by &TCAR; include their own licenses and the &TCAR;
+ license applies to all packages that it does not clash with.
+ If there is a clash between the &TCAR; license and individual
+ package licenses, the individual package license applies
+ instead.
+
+
+
+ The precise conditions of the license for the &TCAR; are found
+ in . This manual specifically
+ is covered by the conditions found in .
+
+
+
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/extending.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/extending.docbook
new file mode 100644
index 0000000..a270e5a
--- /dev/null
+++ b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/extending.docbook
@@ -0,0 +1,44 @@
+
+
+ Extending Repository Layout
+
+
+ Occasionly, you may find that new components of &TCPCVI; need
+ to be added to the repository in order to work them out. If
+ that is the case, the first question we need to ask ourselves,
+ before starting to create directories blindly all over, is:
+ What is the right place to store it?
+
+
+
+ To build a directory structure inside the repository you need
+ to define the concept behind it first. Later you need to
+ create a new directory inside the repository, remembering that
+ there are locations inside the repository that already define
+ concepts you probably would prefer to reuse. For example, the
+ Identity/Images/Themes
+ directory stores artistic motifs of different themes, the
+ Identity/Models/Themes
+ directory stores design models for themes, the Manuals directory stores
+ documentation, the Locales stores translation
+ messages, and the Scripts stores automation
+ scripts.
+
+
+
+ The best suggestion we can probably give you would be to send
+ a mail with your questions to the CentOS developers mailing
+ list (centos-devel@centos.org).
+ This is the place where development of &TCAR; takes place and
+ surely, in community, it will be possible to find a place for
+ your new component inside the repository.
+
+
+
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/filenames.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/filenames.docbook
new file mode 100644
index 0000000..c43fada
--- /dev/null
+++ b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/filenames.docbook
@@ -0,0 +1,185 @@
+
+
+ Repository File Names
+
+
+ Regular Files
+
+
+ Inside &TCAR;, file names are always written in lowercase.
+ Digits (e.g., 0, 1, 2), hyphen (-), dot
+ (.) and low line (_)
+ characters are also accepted. In case you use hyphen and dot
+ characters, don't use them as first character in the file
+ name.
+
+
+
+ Files Written Correctly
+
+ The following file names are written correctly:
+
+
+
+
+ 01-welcome.png
+
+
+
+
+ splash.png
+
+
+
+
+ anaconda_header.png
+
+
+
+
+
+
+ Files Written Incorrectly
+
+ The following file names are written incorrectly:
+
+
+
+
+ 01-Welcome.png
+
+
+
+
+ -welcome.png
+
+
+
+
+ Splash.png
+
+
+
+
+ AnacondaHeader.png
+
+
+
+
+
+
+ Exceptions
+
+ When you name files, consider the following exceptions:
+
+
+
+
+ In the very specific case of repository documentation entries
+ written in Texinfo format, file names follow the directory
+ structure naming convenction. This is because they are
+ documenting directories and that is something
+ we want to remark. So, to better describe what we are
+ documenting, files related to documentation entries follow the
+ name convenction used by the item they document.
+
+
+
+
+
+
+
+
+
+ Symbolic Links
+
+ Inside &TCAR;, symbolic link names follow the same
+ convenctions described in .
+
+
+
+
+ Directories
+
+ Inside &TCAR;, directory names are all written capitalized and
+ sometimes in cammel case. Digits (e.g., 0, 1, 2), hyphen
+ (-), dot (.) and low line
+ (_) characters are also accepted. In case you
+ use hyphen and dot characters, don't use them as first
+ character in the directory name.
+
+
+
+ Directories Written Correctly
+
+ The following directory names are written correctly:
+
+
+
+
+ Identity,
+ Themes,
+ Motifs,
+ TreeFlower
+
+
+
+
+ Tcar-ug
+
+
+
+
+ 0.0.1, 0.0.1-35
+
+
+
+
+
+
+ Directories Written Incorrectly
+
+ The following directory names are written incorrectly:
+
+
+
+
+ identitY,
+ theMes,
+ MOTIFS,
+ treeFlower
+
+
+
+
+ tcar-ug
+
+
+
+
+ .0.1, .0.1-35
+
+
+
+
+
+
+ Exceptions
+
+ When you name directories, consider the following exceptions:
+
+
+
+
+ No one so far.
+
+
+
+
+
+
+
+
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/layout.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/layout.docbook
new file mode 100644
index 0000000..e651a73
--- /dev/null
+++ b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/layout.docbook
@@ -0,0 +1,69 @@
+
+
+ Repository Layout
+
+
+ &TCAR; is made of one central repository and
+ many working copies of that central repository.
+ The working copies are independent one another, can be
+ distributed all around the world and provide a local place for
+ designers, documenters, translators and programmers to perform
+ their work in a decentralized way. The central repository, on
+ the other hand, provides a common place for all independent
+ working copies to interchange data in the community.
+
+
+
+ The current infrastructure that holds &TCAR; is supported by
+ Subversion,
+ a version control system which allows you to keep old versions
+ of files and directories (usually source code), keep a log of
+ who, when, and why changes occurred, etc., like CVS, RCS or
+ SCCS and Trac,
+ a web-based software project management and bug/issue tracking
+ system emphasizing ease of use and low ceremony.
+
+
+
+ In addition to current Subversion infrastructure, we are
+ working on a Git infrastructure with the intention of
+ migrating the central repository to it, progressively. Here we
+ use Gitolite to manage Git repositories, Gitweb to make
+ changes browsable through the web and Mantis to track
+ repository issues. The main reason for this migration is to
+ take advantage of distributed version control system inside
+ &TCAR;. It also let people to commit changes locally, without
+ any network access, and later push local commits up to central
+ repository, when the network access be re-established. This
+ could be very useful in very different kind of situations.
+
+
+
+ Subversion
+
+
+ In this layout, the first level of directories inside &TCAR;
+ provides the Subversion's standard trunk-branches-tags layout.
+ The second level of directories provides organization for
+ different work lines, as described in . All other subsequent
+ directory levels from second level
+ on exist to organize specific concepts related to the work
+ line they belong to.
+
+
+
+
+
+ Git
+
+ In this layout, the first level of directories provides
+ organization for different work lines, as described in . All other subsequent
+ directory levels from second level on exist to organize
+ specific concepts related to the work line they belong to.
+
+
+
+
+
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/mission.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/mission.docbook
new file mode 100755
index 0000000..32c6a9d
--- /dev/null
+++ b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/mission.docbook
@@ -0,0 +1,9 @@
+
+
+ Repository Mission
+
+
+ &TCAR; exists to produce &TCP; corporate visual identity.
+
+
+
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/publishing.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/publishing.docbook
new file mode 100755
index 0000000..71bcd14
--- /dev/null
+++ b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/publishing.docbook
@@ -0,0 +1,59 @@
+
+
+ Repository Publishing
+
+
+ When you perform changes inside your working copy, those
+ changes are local to your working copy only. In order for you
+ to share your changes with others, you need to commit them up
+ to the central repository the working copy you are using was
+ initially downloaded from. To commit your changes up to the
+ central repository you use the commit
+ command from the Subversion's client you've installed in your
+ workstation.
+
+
+
+ Initially, when you get registered inside &TCAR;, you won't be
+ able to publish your changes to &TCAR; immediatly. It is
+ necessary that you prove your interest in contributing first
+ sending a mail to the CentOS
+ Developers mailing list (centos-devel@centos.org),
+ preferably in conjunction with a description of the changes
+ you pretend to commit. This restriction is necessary in order
+ to protect the source repository from spammers.
+
+
+
+ Once you've received access to publish your changes, they will
+ remain valid to you and there is no need for you to request
+ permission to publish new changes as long as you behave as a
+ good cooperating citizen.
+
+
+
+ As a good cooperating citizen one understand of a person who
+ respects the work already done by others and share ideas with
+ authors before changing relevant parts of their work,
+ specially in situations when the access required to realize
+ the changes has been granted already. Of course, there is a
+ time when conversation has taken place, the paths has been
+ traced and changing the work is so obvious that there is no
+ need for you to talk about it; that's because you already did,
+ you already built the trust to keep going. As complement, the
+ mailing list mentioned above is available for sharing ideas in
+ a way that good relationship between community citizens could
+ be constantly balanced.
+
+
+
+ The relationship between community citizens is monitored by
+ repository administrators. Repository administrators are
+ responsible of granting that everything goes the way it needs
+ to go in order for &TCAR; to accomplish its mission (see ).
+
+
+
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/relbdirs.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/relbdirs.docbook
new file mode 100644
index 0000000..835f241
--- /dev/null
+++ b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/relbdirs.docbook
@@ -0,0 +1,157 @@
+
+
+ Repository Path Relations
+
+
+ In order for automation scripts to produce content inside a
+ working copy of &TCAR;, it is required that all work lines be
+ related somehow. The automation scripts take the relation
+ between work lines as reference to determine the place the
+ information they will work with will be retrieve from (e.g.,
+ scalable vector graphics, documentation, translations, etc.),
+ as well as the place where it will store the final files
+ produced as result of automation process (e.g., portable
+ network graphics, documentation ready for printing and reading
+ online, etc.).
+
+
+ In order to implement the relation between work lines it is
+ required to establish a path name convenction, so we can
+ conceptually organize different components and relate them one
+ another using predictable path constructions in a scalable
+ way. Based on this need, we identify three different path
+ types inside &TCAR;. These path types are: Output
+ Paths, Input Paths, and
+ Auxiliary Paths.
+
+
+
+ Output Paths
+
+
+ The output paths point to directories inside the working copy
+ which contain files produced from files inside the input
+ paths. For example, the following paths are consider as output
+ paths:
+
+
+
+
+
+ Identity/Images/Brands/
+
+
+
+
+ Documentation/Manuals/Tcar-ug/
+
+
+
+
+ Identity/Images/Themes/Modern/2/Distro/5/Anaconda/
+
+
+
+
+
+ Output paths are also known as Render-able
+ Directories because they are the type of
+ path you should provide as argument to functionality so as to
+ produce content through it.
+
+
+
+
+
+ Input Paths
+
+ The input paths point to a directories inside the working copy
+ which contain files used to produce files inside output paths.
+ For example, the following paths are considered as input
+ paths:
+
+
+
+
+
+ Identity/Models/Brands/
+
+
+
+
+ Documentation/Models/Tcar-ug/
+
+
+
+
+ Identity/Models/Themes/Default/Distro/5/Anaconda/
+
+
+
+
+
+
+ Auxiliary Paths
+
+
+ The auxiliary paths point to directories inside the working
+ copy which contain files used to create modified instances of
+ inside input paths which are use in turn to produce files
+ inside output paths. For example, the following paths are
+ considered as auxiliary paths:
+
+
+
+
+
+ Identity/Images/Brands/
+
+
+
+
+ Locales/Documentation/Models/Docbook/Tcar-ug/es_ES/
+
+
+
+
+ Locales/Identity/Models/Themes/Default/Distro/5/Anaconda/es_ES/
+
+
+
+
+
+ The relationship between input, output and auxiliary paths is
+ created by combining the first directory level of input paths
+ with the first directory level in the repository directory
+ layout. In the repository directory layout, the first level
+ includes the Identity,
+ Documentation and
+ Scripts directories.
+ These directories are always used to create input and output
+ paths. The Locales
+ directory, on the other hand, is always used to create
+ auxiliary paths only for input paths available under Identity, Documentation and Scripts directories.
+
+
+
+ For example, if the LANG environment
+ variable is set to es_ES.UTF-8 and you execute
+ the functionality of
+ centos-art.sh script with the Documentation/Manuals/Docbook/Tcar-ug/
+ input path as argument, it will produce &TCARUG; in Spanish
+ language using translation messages from
+ Locales/Documentation/Models/Docbook/Tcar-ug/es_ES/
+ auxiliary path and would save final documentation files under
+ Documentation/Manuals/Docbook/Tcar-ug/es_ES/
+ output path.
+
+
+
+
+
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/syncpaths.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/syncpaths.docbook
new file mode 100644
index 0000000..d8e353d
--- /dev/null
+++ b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/syncpaths.docbook
@@ -0,0 +1,99 @@
+
+
+ Syncronizing Repository Paths
+
+
+ Once both master and auxiliar paths have been related in the
+ repository, they shouldn't be changed except you absolutly
+ need to do so. In this cases, when you need to change master
+ or auxiliar paths, it is required that you also change the
+ relation between them so as to retain their bond. This
+ process of keeping master and auxiliar paths
+ connected between themselves is known as
+ path syncronization.
+
+
+
+ Path syncronization is required for automation scripts to know
+ where to store final output, where to retrive translation
+ messages from, and whatever information you might need to
+ count with. If the relation between master paths and auxiliar
+ paths is lost, there is no way for automation scripts to know
+ where to retrive the information they need to work with or
+ where to store the output information produced from it.
+ Through path syncronization we organize and extend the content
+ production inside the repository.
+
+
+
+ Path syncronization affects both movement of files and
+ replacement of content inside files. Movement of files is
+ related to actions like renaming files and directories inside
+ the repository. Replacement of content inside files is
+ related to actions like replacing information (e.g., paths
+ information) inside files in order to keep file contents and
+ file locations consistent one another after a file has been
+ moved.
+
+
+
+ The order followed to syncronize path information is very
+ important because the versioned nature of the files we are
+ working with. When a renaming action needs to be performed
+ inside the repository, we avoid making replacements inside
+ files first and file movements later. This would demand two
+ commit actions: one for the files' internal changes and
+ another for the file movement itself. Instead, we prefer to
+ perform file movements first and files' internal replacements
+ later. This way it is possible to commit both changes as if
+ they were just one.
+
+
+
+
+ There is no support for URLs actions inside
+ centos-art.sh script. The
+ centos-art.sh script is designed to work
+ with local files inside the working copy only. If you need to
+ perform URL actions directly, use Subversion's commands
+ instead.
+
+
+
+
+ At this moment there isn't full implementation of path
+ syncronization inside centos-art.sh script
+ and that is somthing we need to do oursleves. However, the
+ texinfo backend inside the
+ help functionality does provide a restricted
+ implementation of path syncronization to documentation area
+ through the ,
+ and options. You can read this
+ implementation and use it as reference to implement path
+ syncronization in other areas.
+
+
+
+ The plan for a full implementation of path syncronization
+ inside centos-art.sh script would be to
+ create individual restricted implementations like the one in
+ texinfo backend for other areas that demand it
+ and then, create a higher implmentation that combines them all
+ as needed. This way, if we try to rename a repository
+ directory, the higher action can know which are all the
+ restricted actions that should be performed in order
+ to make the full path syncronization.
+
+
+
+ For example, if the directory we are renaming is a master
+ path, it is required to syncronize the related output and
+ localization auxiliar paths. On the other hand, if the
+ directory we are renaming through full path syncronization is
+ an auxiliar path, it is required to determine first what is
+ the related master path and later, perform the syncronization
+ from master path to auxiliar paths as if the path provided
+ would be the master path not the auxiliar path.
+
+
+
diff --git a/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/worklines.docbook b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/worklines.docbook
new file mode 100644
index 0000000..094f1bd
--- /dev/null
+++ b/Documentation/Models/Docbook/Tcar-ug/Repository/Conventions/worklines.docbook
@@ -0,0 +1,183 @@
+
+
+ Repository Work Lines
+
+
+ The content production inside &TCAR; has been divided into
+ individual work lines that relate one another based on the
+ idea of doing one thing well. In this model, the content
+ produced individually by each work line is combined one
+ another later to achieve higher purposes (e.g., corporate
+ identity for &TCP;). The repository work lines, as conceived
+ here, provide a relaible environment for people to work
+ syncronized and descentralized.
+
+
+
+ The action of combining work lines inside &TCAR; is known as
+ the corporate identity production cycle. The rest of this
+ section describes the work lines available in the repository
+ and how they fit inside the corporate identity production
+ cycle.
+
+
+
+
+ Visual Identity
+
+
+ The visual identity is the first component we work out in
+ order to produce a new corporate identity. Through this work
+ line, graphic designers create models and
+ motifs for all the visual manifestation &TCP;
+ is made of. Once design models and artistic motifs are set in
+ place, graphic designers use the render
+ functionality described in to combine both design models and artistic motifs into
+ final images.
+
+
+
+ The main purposes of this work line is define all the visual
+ manifestations the &TCP; is made of and provide design models
+ and artistic motifs for them in order to render the set of
+ images required to transmit the visual style that identifies
+ &TCP; as unique organization. To know more about &TCPCVI;,
+ read .
+
+
+
+ The visual identity work line takes palce in the Identity directory.
+
+
+
+
+
+
+
+ Localization
+
+
+ The content localization is the second component that must be
+ worked out in the corporate identity production cycle.
+ Through this work line translators localize source files
+ (e.g., SVG, DocBook, Shell scripts) which are later use to
+ produce localized images, localized documentation and
+ localized automation scripts. To localize source files,
+ translators use
+ the locale functionality described in
+ which takes care of
+ retriving translatable strings from source files and provide a
+ consistent localization interface based on GNU
+ gettext multi-lingual message
+ production tool set and xml2po command.
+
+
+
+ The main purpose of this work line is extend the visual
+ identity (produced in English language) to as many native
+ languages as possible in order for people which doesn't
+ understand English languague to feel more confortable with
+ &TCP; and its messages. To know more about the specific
+ localization process read .
+
+
+
+ The localization work line takes palce in the Locales directory.
+
+
+
+
+
+
+ Documentation
+
+
+ The documentation work line is the third component that must
+ be worked out in the corporate identity production cycle.
+ Through this work line documentors settle down the conceptual
+ and practical used to edificate &TCAR;. To write
+ documentation, documentors use the help
+ functionality described in which provides a consistent interface for building
+ documentation through different documentation backends (e.g.,
+ Texinfo, DocBook, LaTeX, etc.).
+
+
+
+ The main purpose of this work line is describe the standard
+ procedures &TCAR; realies on, as well as conceive a place to
+ help you understand what &TCAR; is and what can you do with
+ it.
+
+
+
+ The documentation work line takes palce in the Manuals directory.
+
+
+
+
+
+ Packaging
+
+
+ The packaging work line is the fourth component that must be
+ worked out in the corporate identity production cycle. Through
+ this work line packager gather final images, final
+ translations and final documentation related to art works and
+ put all together inside RPM packages. For this purpose,
+ packagers use the pack describe in
+ which provides a
+ consistent interface for building packages inside the
+ repository.
+
+
+
+ The main purpose of this work line is pack all the information
+ &TCP; requires to rebrand &TCD; according Red Hat
+ redistribution guidelines.
+
+
+
+ The packaging work line takes palce in the Packages directory.
+
+
+
+
+
+
+ Automation
+
+
+ The automation work line is the fifth and last component that
+ must be worked out in the corporate identity production cycle.
+ This work line closes the production cycle and provides the
+ production standards graphic designers, documentors,
+ translators and packagers need to make their work consistent
+ and reusable. For this purpose, programmers develop the
+ centos-art.sh script described in .
+
+
+
+ The main purpose of this work line is standardize the
+ interaction of work lines in a reliable way.
+
+
+
+ The automation work line takes palce in the Scripts directory.
+
+
+
+
+