From 279d6b1b59b8e04f8b18b62e4dd6c8e49589d9a5 Mon Sep 17 00:00:00 2001 From: Alain Reguera Delgado Date: Jun 10 2013 17:12:48 +0000 Subject: Update Tcar-ug documentation manual. - Fix spelling problem on chapter Convenction. It was renamed to Convention. --- 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. + + +
+ +