diff --git a/Manuals/Docbook/repository-parts/Directories.docbook b/Manuals/Docbook/repository-parts/Directories.docbook deleted file mode 100644 index d3bb0bc..0000000 --- a/Manuals/Docbook/repository-parts/Directories.docbook +++ /dev/null @@ -1,22 +0,0 @@ - - - Directories - - The CentOS Artwork Repository uses directories to organize - files and describe conceptual idea about corporate identity. Such - conceptual ideas are explained in each directory related - documentation entry. - - In this chapter you'll learn what each directory inside The - CentOS Artwork Repository is for and so, how you can make use of - them. For that purpose, the following list of directories is - available for you to explore: - - &dir-trunk; - &dir-trunk-identity; - &dir-trunk-identity-models; - &dir-trunk-identity-models-themes; - &dir-trunk-identity-models-themes-default; - &dir-trunk-manuals; - - diff --git a/Manuals/Docbook/repository-parts/Directories/trunk.docbook b/Manuals/Docbook/repository-parts/Directories/trunk.docbook deleted file mode 100644 index 1847e6c..0000000 --- a/Manuals/Docbook/repository-parts/Directories/trunk.docbook +++ /dev/null @@ -1,12 +0,0 @@ - - - <filename class="directory">trunk</filename> - - The trunk directory - structure implements the Subversion's trunk concept in a trunk, - branches, tags repository structure. The trunk directory structure provides - the main development line inside the CentOS Artwork - Repository. - - diff --git a/Manuals/Docbook/repository-parts/Directories/trunk/Identity.docbook b/Manuals/Docbook/repository-parts/Directories/trunk/Identity.docbook deleted file mode 100644 index b2ad8a1..0000000 --- a/Manuals/Docbook/repository-parts/Directories/trunk/Identity.docbook +++ /dev/null @@ -1,210 +0,0 @@ - - - <filename class="directory">trunk/Identity</filename> - - The trunk/Identity - directory implements The CentOS Project corporate - identity based on the The CentOS Project - mission and release - schema. - - The CentOS Project exists to provide The CentOS - Distribution. Additionally, The CentOS Project provides The - CentOS Web and The CentOS Showroom to support and promote the - existence of The CentOS Distribution, respectively. - - The - CentOS Project corporate identity is the ``persona'' of the - organization known as The CentOS Project. The CentOS Project - corporate identity plays a significant role in the way The CentOS - Project, as organization, presents itself to both internal and - external stakeholders. In general terms, The CentOS Project - corporate identity expresses the values and ambitions of The - CentOS Project organization, its business, and its - characteristics. The CentOS Project corporate identity provides - visibility, recognizability, reputation, structure and - identification to The CentOS Project organization by means of - corporate design, corporate - communication, and corporate - behaviour. - - The - corporate design is focused on the effective communication of - corporate messages. Corporate messages are all the information - emitted from the corporation to a target audience. In order for - such communication to happen, it is required to put the messages - on a medium available for the target audience to react upon. - These media are know as corporate - manifestations, because the corporation manifests its - existence through them. The specific way used by the corporation - to set their messages on different media is what the corporate - design is about. - - The amount of manifestations a corporation uses to - communicate its existence may very from one corporation to - another. In the very specific case of The CentOS Project, the - following corporate manifestations come to mind: - - - - - The CentOS Distribution — This corporate - manifestaion is built from SRPM packages. There are SRPM - packages that make a remarkable use of images (e.g., Anaconda, - Grub, Syslinux, Gdm, Kdm, Gsplash, Ksplash, Rhgb, Firstboot, - etc.), packages that make a moderate use of images and - packages that don't use images at all. Also, there are some - packages that make use of text-based information that need to - be changed, too (e.g., release notes, eula, the welcome page - of the web browser, etc.), in order for The CentOS Project to - comply the redistribution guidelines of its upstream provider. - The CentOS Distribution corporate manifestation focuses its - attention on SRPM packages that use images in a remarkable - way, specifically those packages that contain branding - information, in both image and textual format, from the - upstream provider. This way, replacing image and text-based - files, we implement the corporate design of The CentOS - Distribution corporate manifestations. - - - - - The CentOS Web — This corporate manifestation - exists to support The CentOS Distribution corporate - manifestation. The CentOS Web corporate manifestation covers - web applications used by The CentOS Project to manifest its - existence on the Internet. These web applications are free - software and come from different providers which distribute - their work with predefined visual styles. Frequently, these - predefined visual styles have no visual relation among - themselves and introduce some visual contraditions when they - all are put together. These visual contraditions need to be - removed in order to comply with The CentOS Project corporate - structure guidelines. - - - - - The CentOS Showroom — This corporate manifestation - exists to promote The CentOS Distribution. The CentOS - Showroom corporate manifestation covers industrial production - of objects branded by The CentOS Project (e.g., clothes, - stationery and installation media). These branded objects are - for distribution on social events and/or shops. They provide - a way of promotion and a route for commercialization that may - help to aliviate The CentOS Project expenses (e.g., hosting, - servers, full-time-developers, etc.), in a similar way as - donations may do. - - - - - The corporate manifestations above seem to cover all the - media required by The CentOS Project, as organization, to show its - existence. However, other corporate manifestations could be added - in the future, if needed, to cover different areas like building, - offices, transportation and whaterver medium The CentOS Project - thouches to show its existence. - - The CentOS Project corporate communication is - based on community communication and takes - place through the following avenues: - - - The CentOS Chat (#centos, #centos-social}, - #centos-devel on irc.freenode.net) - The CentOS Mailing Lists (). - The CentOS Forums (). - The CentOS Wiki (). - Social events, interviews, conferences, etc. - - - - - The CentOS Project corporate behaviour is based on - community behaviour which take place in . - - The CentOS Project corporate structure is based on a - monolithic corporate visual identity - structure. In this configuration, one unique name and - one unique visual style is used in all corporate manifestations of - The CentOS Project. - - In a monolithic corporate visual identity structure, - internal and external stakeholders feel a strong sensation of - uniformity, orientation, and identification with the organization. - No matter if you are visiting web sites, using the distribution, - or acting on social events, the one unique name and one unique - visual style connects them all to say: Hey! we are all - part of The CentOS Project. - - Other corporate structures for The CentOS Project have been - considered as well. Such is the case of producing one different - visual style for each major release of The CentOS Distribution. - This structure isn't inconvenient at all, but some visual - contradictions could be introduced if it isn't applied correctly - and we need to be aware of it. To apply it correctly, we need to - know what The CentOS Project is made of. - - The CentOS Project, as organization, is mainly made of (but - not limited to) three corporate manifestions: The CentOS - Distribution, The CentOS Web and The CentOS Showroom. Inside The - CentOS Distribution corporate manifestations, The CentOS Project - maintains near to four different major releases of The CentOS - Distribution (e.g., the operating system), parallely in time. - However, inside The CentOS Web visual manifestations, the content - is produced for no specific release information (e.g., there is no - a complete web site for each major release of The CentOS - Distribution individually, but one web site to cover them all). - Likewise, the content produced in The CentOS Showroom is created - for no release-specific at all, but for The CentOS Project in - general. - - In order to produce the correct corporate structure for The - CentOS Project, we need to concider all the corporate - manifestations The CentOS Project is made of, not just one of - them. If one different visual style is used for each major - release of The CentOS Distribution, which one of those different - visual styles would be used to cover the remaining visual - manifestations The CentOS Project is made of (e.g., The CentOS Web - and The CentOS Showroom)? - - Probably you are thinking, that's right, but The CentOS - Brand connects them all already, why would we need to join them up - into the same visual style too, isn't it more work to do, and - harder to maintain? - - Harder to maintain, more work to do, probably. Specially - when you consider that The CentOS Project has proven stability and - consistency through time and, that, certainly, didn't come through - swinging magical wands or something but hardly working out to - automate tasks and providing maintainance through time. Said that, - we consider that The CentOS Project corporate structure must be - consequent with such stability and consistency tradition, beyond - the work it might require initially. It is true that The CentOS - Brand does connect all the visual manifestations it is present on, - but that connection would be stronger if one unique visual style - backups it, too. In fact, whatever thing you do to strength the - visual connection among The CentOS Project corporate - manifestations would be very good in favor of The CentOS Project - recognition. - - Obviously, having just one visual style in all corporate - manifestations for eternity would be a very boring thing and would - give the impression of a visually dead project. So, there is no - problem on creating a brand new visual style for each new major - release of The CentOS Distribution, in order to refresh The CentOS - Distribution visual style; the problem itself is in not - propagating the brand new visual style created for the new release - of The CentOS Distribution to all other visual manifestations The - CentOS Project is made of, in a way The CentOS Project could be - recognized no matter what corporate manifestation be in front of - us. Such lack of uniformity is what introduces the visual - contradition we are precisely trying to solve by mean of themes - production in the CentOS Artwork Repository. - - diff --git a/Manuals/Docbook/repository-parts/Directories/trunk/Identity/Models.docbook b/Manuals/Docbook/repository-parts/Directories/trunk/Identity/Models.docbook deleted file mode 100644 index fba2893..0000000 --- a/Manuals/Docbook/repository-parts/Directories/trunk/Identity/Models.docbook +++ /dev/null @@ -1,4 +0,0 @@ - - <filename class="directory">trunk/Identity/Models</filename> - ... - diff --git a/Manuals/Docbook/repository-parts/Directories/trunk/Identity/Models/Themes.docbook b/Manuals/Docbook/repository-parts/Directories/trunk/Identity/Models/Themes.docbook deleted file mode 100644 index a2660e4..0000000 --- a/Manuals/Docbook/repository-parts/Directories/trunk/Identity/Models/Themes.docbook +++ /dev/null @@ -1,31 +0,0 @@ - - - <filename class="directory">trunk/Identity/Models/Themes</filename> - - This directory implements the concept of themes' - design models. - - Themes' design models provide the structural part of images - (e.g., dimensions, translation markers, position of each element - on the visible area, etc.) required by - centos-art.sh to perform theme rendition. The - provide the modeling characteristics for all the different visual - manifestations a theme is made of. Using themes' design models - reduce the time needed for propagating an artistic motif to - different visual manifestations. - - In this directory, themes' design models are organized by - name. There is one directory for each theme's design model. Each - design model directory must be named as specified in . Inside themes' design models - directories, there is one directory for each visual manifestions a - theme is made of. These directories are named visual - manifestation directories and contain one or more SVG - files to describe the visual structure of that visual - manifestion. - - Themes' design models are SVG files and - can be localized using the locale functionality of - centos-art.sh script. - - diff --git a/Manuals/Docbook/repository-parts/Directories/trunk/Identity/Models/Themes/Default.docbook b/Manuals/Docbook/repository-parts/Directories/trunk/Identity/Models/Themes/Default.docbook deleted file mode 100644 index 30fe79b..0000000 --- a/Manuals/Docbook/repository-parts/Directories/trunk/Identity/Models/Themes/Default.docbook +++ /dev/null @@ -1,16 +0,0 @@ - - - <filename class="directory">trunk/Identity/Models/Themes/Default</filename> - - This directory implements the concept of themes' - default design models. - - Themes' default design models provide the common structural - information (e.g., image dimensions, translation markers, - trademark position, etc.) the centos-art.sh - script uses to produce images when no other design model is - specified through the option at - rendition time. - - diff --git a/Manuals/Docbook/repository-parts/Directories/trunk/Manuals.docbook b/Manuals/Docbook/repository-parts/Directories/trunk/Manuals.docbook deleted file mode 100644 index f089182..0000000 --- a/Manuals/Docbook/repository-parts/Directories/trunk/Manuals.docbook +++ /dev/null @@ -1,4 +0,0 @@ - - <filename class="directory">trunk/Manuals</filename> - ... - diff --git a/Manuals/Docbook/repository-parts/Introduction.docbook b/Manuals/Docbook/repository-parts/Introduction.docbook deleted file mode 100644 index c0a4d95..0000000 --- a/Manuals/Docbook/repository-parts/Introduction.docbook +++ /dev/null @@ -1,26 +0,0 @@ - - - Introduction - - Welcome to The CentOS Artwork Repository - Manual. - - The CentOS Artwork Repository Manual describes how The - CentOS Project corporate visual identity is organized and produced - inside the CentOS Artwork Repository (). If you are - looking for a comprehensive, task-oriented guide for understanding - how The CentOS Project corporate visual identity is produced, this - is the manual for you. - - This guide assumes you have a basic understanding of The - CentOS Distribution. If you need help with CentOS, refer to the - help page on The CentOS Wiki () for a list of different - places you can find help. - - &intro-history; - &intro-copying; - &intro-usage; - - diff --git a/Manuals/Docbook/repository-parts/Introduction/copying.docbook b/Manuals/Docbook/repository-parts/Introduction/copying.docbook deleted file mode 100644 index 1c679e0..0000000 --- a/Manuals/Docbook/repository-parts/Introduction/copying.docbook +++ /dev/null @@ -1,91 +0,0 @@ - - - Copying conditions - - Copyright © 2009, 2010, 2011 The CentOS Project - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - - - Preamble - - The CentOS Artwork Repository organizes files in a very - specific way to implement The CentOS Project corporate visual - identity. This very specific organization of files must be - considered part of centos-art.sh script, a bash - script that automate most of the frequent tasks inside the - repository. - - The centos-art.sh script and the - organization of files it needs to work are not in the public - domain; they are 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 program that they might get from you. - - Specifically, we want to make sure that you have the right - to give away copies of centos-art.sh script and - the organization of files it needs to work, that you receive - source code or else can get it if you want it, that you can change - this program or use pieces of it in new free programs, 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 centos-art.sh - script, 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 - centos-art.sh script. If this program 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 centos-art.sh script is released as a - GPL work. Individual packages used by - centos-art.sh script include their own licenses - and the centos-art.sh script license applies to - all packages that it does not clash with. If there is a clash - between the centos-art.sh script license and - individual package licenses, the individual package license - applies instead. - - The precise conditions of the license for the - centos-art.sh script are found in the . This manual specifically is - covered by the . - - - - - The CentOS Brand - - The CentOS Brand () is the main visual manifestaion of The - CentOS Project. The CentOS Project uses The CentOS Brand to - connect all its visual manifestions (e.g., GNU/Linux - Distributions, Websites, Stationery, etc.) and, this way, it - provides recognition among other similar projects available on the - Internet. - - Both The CentOS Brand and all the visual manifestations that - derivate from it are available for you to study and propose - improvement around a good citizen's will at The CentOS Community - environment, but you are not allowed to redistribute them - elsewhere, without the given permission of The CentOS - Project. - - If you need to redistribute either The CentOS Brand or any - visual manifestation derived from it, write your intentions to the - The CentOS Developers mailing list - (centos-devel@centos.org). - - - - - diff --git a/Manuals/Docbook/repository-parts/Introduction/document-convenctions.docbook b/Manuals/Docbook/repository-parts/Introduction/document-convenctions.docbook deleted file mode 100644 index 8e12a51..0000000 --- a/Manuals/Docbook/repository-parts/Introduction/document-convenctions.docbook +++ /dev/null @@ -1,147 +0,0 @@ -
- - Document convenctions - - In this manual the personal pronoun we - is used to repesent The CentOS Artwork SIG, - the group of persons that build The CentOS Project corporate - visual identity through the CentOS Artwork Repository. - - In this manual, certain words are represented in different - fonts, typefaces, sizes, and weights. This highlighting is - systematic; different words are represented in the same style to - indicate their inclusion in a specific category. The types of - words that are represented this way include the following: - - - - command - - Linux commands (and other operating system - commands, when used) are represented this way. This - style should indicate to you that you can type the - word or phrase on the command line and press Enter to - invoke a command. Sometimes a command contains words - that would be displayed in a different style on their - own (such as file names). In these cases, they are - considered to be part of the command, so the entire - phrase is displayed as a command. For example: - - Use the centos-art identity - --render='path/to/dir' command to produce - contents inside the trunk/Identity directory - structure. - - - - - - file name - - File names, directory names, paths, and RPM - package names are represented this way. This style - indicates that a particular file or directory exists - with that name on your system. Examples: - - The init.sh file in - trunk/Scripts/Bash/Cli/ - directory is the initialization script, written in - Bash, used to automate most of tasks in the - repository. - - The centos-art command uses - the ImageMagick RPM package to - convert images from PNG format to other - formats. - - - - - - key - - A key on the keyboard is shown in this style. - For example: - - To use TAB completion to list - particular files in a directory, type @command{ls}, - then a character, and finally the Tab key. Your - terminal displays the list of files in the working - directory that begin with that character. - - - - - key-combination - - A combination of keystrokes is represented in - this way. For example: - - The CtrlAltBackspace - key combination exits your graphical session and - returns you to the graphical login screen or the - console. - - - - - - - computer output - - Text in this style indicates text displayed to a - shell prompt such as error messages and responses to - commands. For example: - - The ls command displays the - contents of a directory. For example: - - -Config help_renameEntry.sh -help_copyEntry.sh help_restoreCrossReferences.sh -help_deleteCrossReferences.sh help_searchIndex.sh - - - The output returned in response to the command (in this - case, the contents of the directory) is shown in this - style. - - - - - Additionally, we use several different strategies to draw - your attention to certain pieces of information. In order of - urgency, these items are marked as a note, tip, important, - caution, or warning. For example: - - - Remember that Linux is case sensitive. In other words, a - rose is not a ROSE is not a rOsE. - - - - The directory @file{/usr/share/doc/} contains additional - documentation for packages installed on your system. - - - - If you modify the DHCP configuration file, the changes - do not take effect until you restart the DHCP daemon. - - - - Do not perform routine tasks as root — use a - regular user account unless you need to use the root account - for system administration tasks. - - - - Be careful to remove only the necessary partitions. - Removing other partitions could result in data loss or a - corrupted system environment. - - -
diff --git a/Manuals/Docbook/repository-parts/Introduction/history.docbook b/Manuals/Docbook/repository-parts/Introduction/history.docbook deleted file mode 100644 index 8d75b67..0000000 --- a/Manuals/Docbook/repository-parts/Introduction/history.docbook +++ /dev/null @@ -1,148 +0,0 @@ - - - History - - The CentOS Artwork Repository started around 2008 during a - discussion about how to automate the slide images of Anaconda, at - CentOS Developers mailing list (centos-devel@centos.org). In such - discussion, Ralph Angenendt rose up his hand to ask —Do you have - something to show?—. - - To answer the question, I suggested a bash script which - combined SVG and SED files in order to produce PNG images in - different languages —together with the proposition of - creating a Subversion repository where translations and image - production could be distributed inside The CentOS - Community—. - - Karanbirn Sighn considered the idea intresting and provided - the infrastructure necessary to support the effort. This way the - CentOS Artwork SIG (https://projects.centos.org/trac/artwork/) and - the CentOS Artwork Repository - (https://projects.centos.org/svn/artwork/) were officially - created. - - Once the CentOS Artwork Repository was available, I uploaded - the bash script for rendering Anaconda slides; Ralph Angenendt - documented it very well; and people started to download working - copies of CentOS Artwork Repository to produce slide images in - their own languages. - - Around 2009, the rendition script was at a very rustic state - where only slide images could be produced, so it was redesigned to - extend the image production to other areas, different from slide - images. In this configuration, one SVG file was used as input to - produce a translated instance of it which, in turn, was used to - produce one translated PNG image as output. The SVG translated - instance was created through SED replacement commands. The - translated PNG image was created from the SVG translated instance - using Inkscape command-line interface. - - The repository directory structure was prepared to receive - the rendition script using design templates and translation files - in the same location. There was one directory structure for each - artwork that needed to be produced. In this configuration, if you - would want to produce the same artwork with a different visual - style or structure, it was needed to create a new directory - structure for it because both the image structure and the image - visual style were together in the design template. - - The rendition script was moved to a common place and linked - from different directory structures. There was no need to have the - same code in different directory structures if it could be in just - one place and then be linked from different locations. - - The concepts about corporate identity began to be - considered. As referece, it was used the book Corporate - Identity by Wally Olins (1989) and Wikipedia related links - (e.g., ). This way, the rendition script main's goal becomes to: - automate production of a monolithic corporate visual identity - structure, based on the mission and the release schema of The - CentOS Project. - - The repository directory structures began to be documented - inside by mean of flat text files. Later, documentation in flat - text files was moved onto LaTeX format and this way The - CentOS Artwork Repository Manual is initiated. - - Around 2010, the rendition script changed its name from - render.sh to centos-art.sh - and became a collection of functionalities where rendition was - just one among others (e.g., documenting and localizing). - - The centos-art.sh was initialy conceived - to organize automation of most frequent tasks inside the - repository based in the conceptual idea of Unix toolbox: - create small and specialized tools that do one thing - well. This way, functionalities inside - centos-art.sh were identified and separated one - another. For example, when images were rendered, there was no need - to load functionalities related to documentation manual. This - layout moved us onto common functionalities and specific - functionalities inside centos-art.sh script. - Common functionalities are loaded when - centos-art.sh script is initiated and are - available to specific functionalities. - - There was no need to have links all around the - repository if a command-line interface could be created (through - symbolic links, in the ~/bin directory) and be called - anywhere inside the repository as it would be a regular - command. - - The centos-art.sh script was redesigned - to handle command-line options trough getopt - option parser. - - The repository directory structure was updated to improve - the implementation of concepts related to corporate visual - identity. Specially in the area related to themes which were - divided into design models and - artistic motifs to eliminate the content - duplication produced by having both image structure and image - visual style in the same file. Now, both - centos-art.sh and repository directory - structure are able to produce themes as result of arbitrary - combinations between design models (structures) and artistic - motifs (visual styles). - - In the documentation area, the documentation files in LaTeX - format were migrated to Texinfo format. In this configuration, - each directory structure in the repository has a documentation - entry associated in a Texinfo structure which can be read, edited - and administered (e.g., renamed, deleted, copied) interactively - throuch centos-art.sh. Additionally, the - texi2html program was used to produced XHTML - output customized by CSS from The CentOS Webenv. - - Around 2011, the centos-art.sh script was - redesigned to start translating SVG and other XML-based files - (e.g., XHTML and Docbook files) through the - xml2po program and shell scripts files (e.g., - Bash scripts) through GNU gettext tools. This - configuration provided a stronger interface for graphic designers, - translators and programmers to produce localized content. The SED - files are no longer used to handle translations. - - The render, help and - locale functionalities were consolidated as the most - frequent tasks performed inside the repository. Additionally, the - prepare and tuneup functionalities are - maintained as useful tasks. - - The centos-art.sh script is updated to - organize functionalities in two groups: the administrative - functionalities and the productive - functionalities. The administrative functionalities cover - actions like: copying, deleting and renaming directory structures - inside the repository. Also, preparing your workstation for using - centos-art.sh script, making backups of the - distribution theme currently installed, installing themes created - inside repository and restoring themes from backup. On the other - hand, the productive functionalities cover actions like: content - rendition, content localization, content documentation and content - maintainance. - - diff --git a/Manuals/Docbook/repository-parts/Introduction/send-in-your-feedback.docbook b/Manuals/Docbook/repository-parts/Introduction/send-in-your-feedback.docbook deleted file mode 100644 index 198696e..0000000 --- a/Manuals/Docbook/repository-parts/Introduction/send-in-your-feedback.docbook +++ /dev/null @@ -1,17 +0,0 @@ -
- - Send in your feedback - - If you find an error in the CentOS Artwork - Repository, or if you have thought of a way to make - this manual better, we would like to hear from you! Share your - suggestions in the appropriate mailing list - (http://lists.centos.org/) and/or bug tracker - (http://bugs.centos.org/). - - When you make suggestion, try to be as specific as possible. - For example, if you have found an error in the manual, include the - section number and some of the surrounding text so we can find it - easily. - -
diff --git a/Manuals/Docbook/repository-parts/Introduction/usage.docbook b/Manuals/Docbook/repository-parts/Introduction/usage.docbook deleted file mode 100644 index 235972f..0000000 --- a/Manuals/Docbook/repository-parts/Introduction/usage.docbook +++ /dev/null @@ -1,369 +0,0 @@ - - - Usage convenctions - - The CentOS Artwork Repository is supported by Subversion - (http://subversion.tigris.org/), 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. - - When using Subversion there is one "source repository" and - many "working copies" of that source repository. The working - copies are independent one another, can be distributed all around - the world and provide a local place for designers, documentors, - translators and programmers to perform their work in a - descentralized way. The source repository, on the other hand, - provides a central place for all independent working copies to - interchange data and provides the information required to permit - extracting previous versions of files at any time. - - - - Policy - - The CentOS Artwork Repository is a collaborative tool - that anyone can have access to. However, changing that tool in - any form is something that should be requested in the CentOS - Developers mailing list (centos-devel@centos.org). Generally, - people download working copies from CentOS Artwork Repository, - study the repository organization, make some changes in their - working copies, make some tests to verify such changes do work - the way expected and finally request access to commit them up - to the CentOS Artwork Repository (i.e., the source repository) - for others to benefit from them. - - Once you've received access to commit your changes, - there is no need for you to request permission again to commit - other changes from your working copy to CentOS Artwork - Repository as long as you behave as a good - cooperating citizen. Otherwise, your rights to - commit changes might be temporarly revoked or permanently - banished. - - 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. Anyway, 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 the CentOS Artwork Repository to accomplish - its mission which is: to provide a colaborative tool for The - CentOS Community where The CentOS Project corporate visual - identity is built and maintained by The CentOS Community - itself. - - It is also important to remember that all the program - and documentation source files inside CentOS Artwork - Repository must comply the terms of and - respectively in order for them to remain inside the - repository. - - - - - - Work lines - - Content production inside the repository is organized by - work lines. There are three major work - lines of production inside The CentOS Artwork Repository, - which are: Graphic design, - Documentation and - Localization. The specific way of - producing content inside each specific work line is - standardized by mean of centos-art.sh - script (which in turn, can be considered a work line by itself - [e.g., the Automation work line]). The - centos-art.sh script provides one specific - functionality for automating each major work line of content - production (e.g., render for producing images, - help for manage documentation, and - locale for localizing contents). - - The graphic design work line exists to cover brand - design, typography design and themes design mainly. - Additionally, some auxiliar areas like icon design, - illustration design, brushes design, patterns designs and - palettes of colors are also included here for completeness. - The graphic design work line is organized in the trunk/Identity directory. - - The documentation work line exists to describe what each - directory inside the CentOS Artwork Repository is for, the - conceptual ideas behind them and, if possible, how automation - scripts make use of them. The documentation work line is - organized in the trunk/Manuals directory. - - The localization work line exists to provide the - translation messages required to produce content in different - languages. Translation messages inside the repository are - stored as portable objects (e.g., .po, .pot) and machine - objects (.mo). The localization work line is organized in the - trunk/Locales - directory. - - The automation work line exists to standardize content - production inside the working copies of CentOS Artwork - Repository. Here is developed the - centos-art.sh script, a bash script - specially designed to automate most frequent tasks (e.g., - rendition, documentation and localization) inside the - repository. There is no need to type several tasks, time - after time, if they can be programmed into just one executable - script. The automation work line is organized in the - trunk/Scripts - directory. - - - - - - Relation between directories - - In order for automation scripts to produce content inside a - working copy of CentOS Artwork Repository, it is required that all - work lines be related somehow. The relation is used by automation - scripts to know where to retrive the information they need to work - with (e.g., design model, translation messages, output locations, - etc.). This kind of relation is built using two path - constructions named master paths and - auxiliar paths. - - The master path points only to directories that contain - source files (e.g., SVG files) required to produce output base - content (e.g., PNG files) through automation scripts. Each master - path inside the repository may have several auxiliar paths - associated, but auxiliar paths can only have one master path - associated. - - Master paths used for producing images through SVG rendition - are organized under trunk/Identity/Models directory - structure and the auxiliar paths under trunk/Identity/Images, trunk/Locales and trunk/Manuals directory - structures. - - Auxiliar paths can point either to directories or files. - When an auxiliar path points to a directory, that directory - contains information that modifies somehow the content produced - from master paths (e.g., translation messages) or provides the - output information required to know where the content produced - from the master path should be stored. When an auxiliar path - points to a file, that file has no other purpose but to document - the master path it refers to. - - Auxiliar paths should never be modified under any reason but - to satisfy the relationship with the master path. Liberal change - of auxiliar paths may suppress the conceptual idea they were - initially created for; and certainly, automation scripts may stop - working as expected. - - The relationship between auxiliar paths and master paths is - built by combining the master path and the second level directory - structures of the repository. The master path is considered the - path identifier and the repository second level directory - structure is considered the common part of the path where the path - identifier is appended to. So, if we have the master path - trunk/Identity/Models/Brands, we'll - end up having, at least, the trunk/Identity/Images/Brands auxiliar - path for storing output files and, optionally, one path under - trunk/Manuals for storing - documentation and one path under trunk/Locales for storing - localizations. - - - - - - Syncronizing paths - - Once both master paths and their auxiliar paths have been - set, they shouldn't be changed. Assuming one master path must be - changed it is required that all related auxiliar paths be changed, - too. This is required in order for master paths to retain their - relation with auxiliar paths. This process of keeping relation - between master paths and auxiliar paths is known as path - syncronization. - - Path syncronization is required for automation scripts to - know where to store final output, where to retrive translation - messages, documentation, and any information that might be - desired. If the relation between master paths and auxiliar paths - is lost, there is no way for centos-art.sh - script to know where to retrive the information it needs to work - with. Path syncronization is the way we use to organize and - extend the information stored in the repository. - - Path syncronization may imply 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. - - The order followed to syncronize path information is very - important because the versioned nature of the repository files we - are working with. When a renaming action must be performed, we - avoid making replacements inside files first and file movements - later. This would require two commit actions: one for the files' - internal changes and another for the file movement itself. - Otherwise, we prefer to perform file movements first and file - 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 commands - instead. - - At this moment there is no full implementation of path - syncronization process inside centos-art.sh - script except by texinfo backend of - help functionality which provides a restricted - implementation of path syncronization to this specific area of - documentation through the , - and options. - The plan for a full implementation of path syncronization would be - to create individual restricted implementations like this one for - other areas that demand it and then, create a higher implmentation - that combines all restricted implementations as needed. This way, - if we try to rename a repository directory the higer action will - define which are all the restricted actions that should be - performed in order for make a full path syncronization. For - example, if the directory we are renaming is part of graphic - design work line, it is required to syncronize related paths in - documentation and localization work lines. Likewise, if the - directory we are renaming is in documentation work line, it is - required to syncronize related paths in graphic design and - localization work lines. In all these cases, the direction used - for syncronizing paths must be from master path to auxiliar path - and never the opposite (i.e., rename the master path first and - auxiliar paths later). - - A practical example, through which you can notice the - usefulness of path syncronization process, is what happen when - documentation entries are renamed (see section ...). - - - - - - Extending repository organization - - Occasionly, you may find that new components of The - CentOS Project corporate visual identity 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 start to - create directories blindly all over, is: What is the - right place to store it? - - The best place to find answers is in The CentOS - Community (see page http://wiki.centos.org/Help), but going - there with hands empty is not good idea. It may give the - impression you don't really care about. Instead, consider the - following suggestions to find your own comprehension in order - to make your own propositions based on it. - - When extending respository structure it is very useful - to bear in mind The CentOS Project corporate visual identity - structure, The CentOS Mission and The CentOS Release Schema. - The rest is a matter of choosing appropriate names. It is also - worth to know that each directory in the repository responds - to a conceptual idea that justifies its existence. - - To build a directory structure inside the repository, - you need to define the conceptual idea first and later create - the directory, remembering that there are locations inside the - repository that define conceptual ideas you probably would - prefer to reuse. For example, the trunk/Identity/Images/Themes - directory stores theme artistic motifs, the trunk/Identity/Models/Themes - directory stores theme design models, the trunk/Manuals directory stores - documentation files, the trunk/Locales stores translation - messages, and the trunk/Scripts stores automation - scripts. - - To better illustrate this desition process, you can - consider to examin the trunk/Identity/Images/Themes/TreeFlower/3 - directory structure as example. This directory can be read - as: the theme development line of version 3 of - TreeFlower artistic motif. Additional, we can - say that TreeFlower artistic motif is part of - themes, as themes are part of The CentOS Project corporate - visual identity. - - The relationship between conceptual ideas can be - stablished by reading each repository documentation entry - individually, from trunk directory to a deeper - directory in the path. For reading repository documentation - entries we use the help functionality of - centos-art.sh script. - - - - - - File names convenction - - Inside the CentOS Artwork Repository, generally, file - names are all written in lowercase (e.g., - 01-welcome.png, - splash.png, - anaconda_header.png, etc.) and directory - names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel - case (e.g., TreeFlower, - etc.). - - In the very specific case of repository documentation - entries, file names follow the directory 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, documentation entries follow the name - convenction used by the item they document. - - - - - - Repository layout - - The CentOS Artwork Repository is organized through a - convenctional trunk, branches - and tags layout. Explanation of each directory - inside the repository can be found in the chapter. - - - - diff --git a/Manuals/Docbook/repository-parts/Licenses/gfdl.docbook b/Manuals/Docbook/repository-parts/Licenses/gfdl.docbook deleted file mode 100644 index 789bb53..0000000 --- a/Manuals/Docbook/repository-parts/Licenses/gfdl.docbook +++ /dev/null @@ -1,591 +0,0 @@ - - - GNU Free Documentation License - - Version 1.2, November 2002 - - Copyright © 2000, 2001, 2002 Free Software Foundation, - Inc. 675 Mass Ave, Cambridge, MA 02139, USA - - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - - - Preamble - - The purpose of this License is to make a manual, - textbook, or other functional and useful document - free in the sense of freedom: to assure - everyone the effective freedom to copy and redistribute it, - with or without modifying it, either commercially or - noncommercially. Secondarily, this License preserves for the - author and publisher a way to get credit for their work, while - not being considered responsible for modifications made by - others. - - This License is a kind of copyleft, which - means that derivative works of the document must themselves be - free in the same sense. It complements the , which is a copyleft license - designed for free software. - - We have designed this License in order to use it for - manuals for free software, because free software needs free - documentation: a free program should come with manuals - providing the same freedoms that the software does. But this - License is not limited to software manuals; it can be used for - any textual work, regardless of subject matter or whether it - is published as a printed book. We recommend this License - principally for works whose purpose is instruction or - reference. - - - - - - Applicability and definitions - - This License applies to any manual or other work, in any - medium, that contains a notice placed by the copyright holder - saying it can be distributed under the terms of this License. - Such a notice grants a world-wide, royalty-free license, - unlimited in duration, to use that work under the conditions - stated herein. The Document, below, refers to - any such manual or work. Any member of the public is a - licensee, and is addressed as you. You accept - the license if you copy, modify or distribute the work in a - way requiring permission under copyright law. - - A - Modified Version of the Document means any work - containing the Document or a portion of it, either copied - verbatim, or with modifications and/or translated into another - language. - - A - Secondary Section is a named appendix or a - front-matter section of the Document that deals exclusively - with the relationship of the publishers or authors of the - Document to the Document's overall subject (or to related - matters) and contains nothing that could fall directly within - that overall subject. (Thus, if the Document is in part a - textbook of mathematics, a may not explain any mathematics.) The relationship could be - a matter of historical connection with the subject or with - related matters, or of legal, commercial, philosophical, - ethical or political position regarding them. - - The Invariant Sections are certain - whose titles are - designated, as being those of Invariant Sections, in the - notice that says that the Document is released under this - License. If a section does not fit the above definition of - Secondary then it is not allowed to be designated as - Invariant. The Document may contain zero Invariant Sections. - If the Document does not identify any Invariant Section then - there are none. - - The - Cover Texts are certain short passages of text - that are listed, as Front-Cover Texts or Back-Cover Texts, in - the notice that says that the Document is released under this - License. A Front-Cover Text may be at most 5 words, and a - Back-Cover Text may be at most 25 words. - - A - Transparent copy of the Document means a - machine-readable copy, represented in a format whose - specification is available to the general public, that is - suitable for revising the document straightforwardly with - generic text editors or (for images composed of pixels) - generic paint programs or (for drawings) some widely available - drawing editor, and that is suitable for input to text - formatters or for automatic translation to a variety of - formats suitable for input to text formatters. A copy made in - an otherwise file format whose - markup, or absence of markup, has been arranged to thwart or - discourage subsequent modification by readers is not . An image format is not if used for any substantial amount of - text. A copy that is not is called Opaque. - - Examples of suitable formats for copies - include plain ASCII without markup, Texinfo input format, - LaTeX input format, SGML or XML using a publicly available - DTD, and standard-conforming simple HTML, PostScript or PDF - designed for human modification. Examples of transparent - image formats include PNG, XCF and JPG. Opaque formats - include proprietary formats that can be read and edited only - by proprietary word processors, SGML or XML for which the DTD - and/or processing tools are not generally available, and the - machine-generated HTML, PostScript or PDF produced by some - word processors for output purposes only. - - The Title - Page means, for a printed book, the title page itself, - plus such following pages as are needed to hold, legibly, the - material this License requires to appear in the title page. - For works in formats which do not have any title page as such, - Title Page means the text near the most - prominent appearance of the work's title, preceding the - beginning of the body of the text. - - A section Entitled XYZ means a named - subunit of the Document whose title either is precisely XYZ or - contains XYZ in parentheses following text that translates XYZ - in another language. (Here XYZ stands for a specific section - name mentioned below, such as Acknowledgements, - Dedications, Endorsements, or - History.) To Preserve the Title - of such a section when you modify the Document means that it - remains a section Entitled XYZ according to - this definition. - - The Document may include Warranty Disclaimers next to - the notice which states that this License applies to the - Document. These Warranty Disclaimers are considered to be - included by reference in this License, but only as regards - disclaiming warranties: any other implication that these - Warranty Disclaimers may have is void and has no effect on the - meaning of this License. - - - - - - Verbatim copying - - You may copy and distribute the Document in any medium, - either commercially or noncommercially, provided that this - License, the copyright notices, and the license notice saying - this License applies to the Document are reproduced in all - copies, and that you add no other conditions whatsoever to - those of this License. You may not use technical measures to - obstruct or control the reading or further copying of the - copies you make or distribute. However, you may accept - compensation in exchange for copies. If you distribute a - large enough number of copies you must also follow the - conditions in section . - - You may also lend copies, under the same conditions - stated above, and you may publicly display copies. - - - - - - Copying in quantity - - If you publish printed copies (or copies in media that - commonly have printed covers) of the Document, numbering more - than 100, and the Document's license notice requires Cover - Texts, you must enclose the copies in covers that carry, - clearly and legibly, all these : - Front-Cover Texts on the front cover, and Back-Cover Texts on - the back cover. Both covers must also clearly and legibly - identify you as the publisher of these copies. The front - cover must present the full title with all words of the title - equally prominent and visible. You may add other material on - the covers in addition. Copying with changes limited to the - covers, as long as they preserve the title of the Document and - satisfy these conditions, can be treated as verbatim copying - in other respects. - - If the required texts for either cover are too - voluminous to fit legibly, you should put the first ones - listed (as many as fit reasonably) on the actual cover, and - continue the rest onto adjacent pages. - - If you publish or distribute Opaque copies of the - Document numbering more than 100, you must either include a - machine-readable copy along with each Opaque copy, - or state in or with each Opaque copy a computer-network - location from which the general network-using public has - access to download using public-standard network protocols a - complete copy of the Document, free of added - material. If you use the latter option, you must take - reasonably prudent steps, when you begin distribution of - Opaque copies in quantity, to ensure that this - copy will remain thus accessible at the stated location until - at least one year after the last time you distribute an Opaque - copy (directly or through your agents or retailers) of that - edition to the public. - - It is requested, but not required, that you contact the - authors of the Document well before redistributing any large - number of copies, to give them a chance to provide you with an - updated version of the Document. - - - - - - Modifications - - You may copy and distribute a of the Document under the - conditions of sections and above, - provided that you release the under precisely this License, with the filling the role of the - Document, thus licensing distribution and modification of the - to whoever possesses a - copy of it. In addition, you must do these things in the - : - - - - - Use in the (and on - the covers, if any) a title distinct from that of the - Document, and from those of previous versions (which - should, if there were any, be listed in the History - section of the Document). You may use the same title - as a previous version if the original publisher of - that version gives permission. - - - List on the , as - authors, one or more persons or entities responsible - for authorship of the modifications in the , together with at least - five of the principal authors of the Document (all of - its principal authors, if it has fewer than five), - unless they release you from this requirement. - - - - State on the the - name of the publisher of the , as the - publisher. - - - - Preserve all the copyright notices of the - Document. - - - - Add an appropriate copyright notice for your - modifications adjacent to the other copyright - notices. - - - - Include, immediately after the copyright - notices, a license notice giving the public permission - to use the under the terms of this - License, in the form shown in the Addendum - below. - - - - Preserve in that license notice the full lists - of and required - given in the Document's - license notice. - - - - Include an unaltered copy of this License. - - - - Preserve the section Entitled - History, Preserve its Title, and add to - it an item stating at least the title, year, new - authors, and publisher of the as given on the . If there is no section - Entitled History in the Document, create - one stating the title, year, authors, and publisher of - the Document as given on its , then add an item describing the as stated in the previous - sentence. - - - - Preserve the network location, if any, given in - the Document for public access to a copy of the Document, and - likewise the network locations given in the Document - for previous versions it was based on. These may be - placed in the History section. You may - omit a network location for a work that was published - at least four years before the Document itself, or if - the original publisher of the version it refers to - gives permission. - - - - For any section Entitled - Acknowledgements or - Dedications, Preserve the Title of the - section, and preserve in the section all the substance - and tone of each of the contributor acknowledgements - and/or dedications given therein. - - - - Preserve all the of the Document, - unaltered in their text and in their titles. Section - numbers or the equivalent are not considered part of - the section titles. - - - - Delete any section Entitled - Endorsements. Such a section may not - be included in the . - - - - Do not retitle any existing section to be - Entitled Endorsements or to conflict in - title with any . - - - Preserve any Warranty Disclaimers. - - - - - If the includes new - front-matter sections or appendices that qualify as and contain no material copied - from the Document, you may at your option designate some or - all of these sections as invariant. To do this, add their - titles to the list of in the 's license notice. These titles - must be distinct from any other section titles. - - You may add a section Entitled - Endorsements, provided it contains nothing but - endorsements of your by various - parties–for example, statements of peer review or that - the text has been approved by an organization as the - authoritative definition of a standard. - - You may add a passage of up to five words as a - Front-Cover Text, and a passage of up to 25 words as a - Back-Cover Text, to the end of the list of in the . Only one passage of - Front-Cover Text and one of Back-Cover Text may be added by - (or through arrangements made by) any one entity. If the - Document already includes a cover text for the same cover, - previously added by you or by arrangement made by the same - entity you are acting on behalf of, you may not add another; - but you may replace the old one, on explicit permission from - the previous publisher that added the old one. - - The author(s) and publisher(s) of the Document do not by - this License give permission to use their names for publicity - for or to assert or imply endorsement of any . - - - - - - Combining documents - - You may combine the Document with other documents - released under this License, under the terms defined in - section above for - modified versions, provided that you include in the - combination all of the of - all of the original documents, unmodified, and list them all - as of your combined work - in its license notice, and that you preserve all their - Warranty Disclaimers. - - The combined work need only contain one copy of this - License, and multiple identical may be replaced with a single - copy. If there are multiple with the same name but - different contents, make the title of each such section unique - by adding at the end of it, in parentheses, the name of the - original author or publisher of that section if known, or else - a unique number. Make the same adjustment to the section - titles in the list of in - the license notice of the combined work. - - In the combination, you must combine any sections - Entitled History in the various original - documents, forming one section Entitled - History; likewise combine any sections Entitled - Acknowledgements, and any sections Entitled - Dedications. You must delete all sections - Entitled Endorsements. - - - - - - Collection of documents - - You may make a collection consisting of the Document and - other documents released under this License, and replace the - individual copies of this License in the various documents - with a single copy that is included in the collection, - provided that you follow the rules of this License for - verbatim copying of each of the documents in all other - respects. - - You may extract a single document from such a - collection, and distribute it individually under this License, - provided you insert a copy of this License into the extracted - document, and follow this License in all other respects - regarding verbatim copying of that document. - - - - - - Aggregation with independent works - - A compilation of the Document or its derivatives with - other separate and independent documents or works, in or on a - volume of a storage or distribution medium, is called an - aggregate if the copyright resulting from the - compilation is not used to limit the legal rights of the - compilation's users beyond what the individual works permit. - When the Document is included in an aggregate, this License - does not apply to the other works in the aggregate which are - not themselves derivative works of the Document. - - If the Cover Text requirement of section is applicable to these - copies of the Document, then if the Document is less than one - half of the entire aggregate, the Document's may be placed on covers that bracket - the Document within the aggregate, or the electronic - equivalent of covers if the Document is in electronic form. - Otherwise they must appear on printed covers that bracket the - whole aggregate. - - - - - - Translations - - Translation is considered a kind of modification, so you - may distribute translations of the Document under the terms of - section . Replacing - with translations - requires special permission from their copyright holders, but - you may include translations of some or all in addition to the original - versions of these . You - may include a translation of this License, and all the license - notices in the Document, and any Warranty Disclaimers, - provided that you also include the original English version of - this License and the original versions of those notices and - disclaimers. In case of a disagreement between the - translation and the original version of this License or a - notice or disclaimer, the original version will - prevail. - - If a section in the Document is Entitled - Acknowledgements, Dedications, - or History, the requirement (section ) to Preserve its Title - (section ) will - typically require changing the actual title. - - - - - - Termination - - You may not copy, modify, sublicense, or distribute the - Document except as expressly provided for under this License. - Any other attempt to copy, modify, sublicense or distribute - the Document is void, and will automatically terminate your - rights under this License. However, parties who have received - copies, or rights, from you under this License will not have - their licenses terminated so long as such parties remain in - full compliance. - - - - - - Future Revisions of this License - - The Free Software Foundation may publish new, revised - versions of the GNU Free Documentation License from time to - time. Such new versions will be similar in spirit to the - present version, but may differ in detail to address new - problems or concerns. See . - - Each version of the License is given a distinguishing - version number. If the Document specifies that a particular - numbered version of this License or any later - version applies to it, you have the option of - following the terms and conditions either of that specified - version or of any later version that has been published (not - as a draft) by the Free Software Foundation. If the Document - does not specify a version number of this License, you may - choose any version ever published (not as a draft) by the Free - Software Foundation. - - - - - - How to use this License for your documents - - To use this License in a document you have written, - include a copy of the License in the document and put the - following copyright and license notices just after the title - page: - - - Copyright (C) YEAR YOUR NAME. - - Permission is granted to copy, distribute and/or modify this - document under the terms of the GNU Free Documentation License, - Version 1.2 or any later version published by the Free Software - Foundation; with no Invariant Sections, no Front-Cover Texts, and - no Back-Cover Texts. A copy of the license is included in the - section entitled GNU Free Documentation License. - - - If you have , - Front-Cover Texts and Back-Cover Texts, replace the - with...Texts. line with this: - - - with the Invariant Sections being LIST THEIR TITLES, with the - Front-Cover Texts being LIST, and with the Back-Cover Texts being - LIST. - - - If you have - without , or some other - combination of the three, merge those two alternatives to suit - the situation. - - If your document contains nontrivial examples of program - code, we recommend releasing these examples in parallel under - your choice of free software license, such as the GNU General - Public License, to permit their use in free software. - - - - diff --git a/Manuals/Docbook/repository-parts/Licenses/gpl.docbook b/Manuals/Docbook/repository-parts/Licenses/gpl.docbook deleted file mode 100644 index 3ddcafc..0000000 --- a/Manuals/Docbook/repository-parts/Licenses/gpl.docbook +++ /dev/null @@ -1,485 +0,0 @@ - - - GNU General Public License - - Version 2, June 1991 - - Copyright © 1989, 1991 Free Software Foundation, Inc. - 675 Mass Ave, Cambridge, MA 02139, USA - - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - - - Preamble - - The licenses for most software are designed to take away - your freedom to share and change it. By contrast, the GNU General - Public License is intended to guarantee your freedom to share and - change free software–to make sure the software is free for - all its users. This General Public License applies to most of the - Free Software Foundation's software and to any other program whose - authors commit to using it. (Some other Free Software Foundation - software is covered by the GNU Library General Public License - instead.) You can apply it to your programs, too. - - When we speak of free software, we are referring to freedom, - not price. Our General Public Licenses are designed to make sure - that you have the freedom to distribute copies of free software - (and charge for this service if you wish), that you receive source - code or can get it if you want it, that you can change the - software or use pieces of it in new free programs; and that you - know you can do these things. - - To protect your rights, we need to make restrictions that - forbid anyone to deny you these rights or to ask you to surrender - the rights. These restrictions translate to certain - responsibilities for you if you distribute copies of the software, - or if you modify it. - - For example, if you distribute copies of such a program, - whether gratis or for a fee, 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 show them these terms so - they know their rights. - - We protect your rights with two steps: - - - - copyright the software, and - - - offer you this license which gives you legal - permission to copy, distribute and/or modify the - software. - - - - - Also, for each author's protection and ours, we want to make - certain that everyone understands that there is no warranty for - this free software. If the software is modified by someone else - and passed on, we want its recipients to know that what they have - is not the original, so that any problems introduced by others - will not reflect on the original authors' reputations. - - Finally, any free program is threatened constantly by - software patents. We wish to avoid the danger that redistributors - of a free program will individually obtain patent licenses, in - effect making the program proprietary. To prevent this, we have - made it clear that any patent must be licensed for everyone's free - use or not licensed at all. - - The precise terms and conditions for copying, distribution - and modification follow. - - - - - - Terms and Conditions for Copying, Distribution and Modification - - - - Section 1 - - You may copy and distribute verbatim copies of the - Program's source code as you receive it, in any medium, - provided that you conspicuously and appropriately publish on - each copy an appropriate copyright notice and disclaimer of - warranty; keep intact all the notices that refer to this - License and to the absence of any warranty; and give any other - recipients of the Program a copy of this License along with - the Program. - - You may charge a fee for the physical act of - transferring a copy, and you may at your option offer warranty - protection in exchange for a fee. - - - - - - Section 2 - - You may modify your copy or copies of the Program or - any portion of it, thus forming a work based on the - Program, and copy and distribute such modifications or - work under the terms of above, provided that you also meet all of these - conditions: - - - - You must cause the modified files to carry prominent - notices stating that you changed the files and the date of - any change. - - - You must cause any work that you distribute or - publish, that in whole or in part contains or is derived - from the Program or any part thereof, to be licensed as a - whole at no charge to all third parties under the terms of - this License. - - - If the modified program normally reads commands - interactively when run, you must cause it, when started - running for such interactive use in the most ordinary way, - to print or display an announcement including an - appropriate copyright notice and a notice that there is no - warranty (or else, saying that you provide a warranty) and - that users may redistribute the program under these - conditions, and telling the user how to view a copy of - this License. - - - Exception - - If the Program itself is interactive but does not - normally print such an announcement, your work based - on the Program is not required to print an - announcement. - - - - - - - These requirements apply to the modified work as a whole. - If identifiable sections of that work are not derived from the - Program, and can be reasonably considered independent and separate - works in themselves, then this License, and its terms, do not - apply to those sections when you distribute them as separate - works. But when you distribute the same sections as part of a - whole which is a work based on the Program, the distribution of - the whole must be on the terms of this License, whose permissions - for other licensees extend to the entire whole, and thus to each - and every part regardless of who wrote it. - - Thus, it is not the intent of this section to claim rights - or contest your rights to work written entirely by you; rather, - the intent is to exercise the right to control the distribution of - derivative or collective works based on the Program. - - In addition, mere aggregation of another work not based on - the Program with the Program (or with a work based on the Program) - on a volume of a storage or distribution medium does not bring the - other work under the scope of this License. - - - - - - Section 3 - - You may copy and distribute the Program (or a work - based on it, under ) in - object code or executable form under the terms of and above provided that you also - do one of the following: - - - - - Accompany it with the complete corresponding - machine-readable source code, which must be distributed - under the terms of and - above on a medium - customarily used for software interchange; or, - - - - - Accompany it with a written offer, valid for at - least three years, to give any third party, for a charge - no more than your cost of physically performing source - distribution, a complete machine-readable copy of the - corresponding source code, to be distributed under the - terms of and above on a medium - customarily used for software interchange; or, - - Accompany it with the information you received as - to the offer to distribute corresponding source code. - (This alternative is allowed only for noncommercial - distribution and only if you received the program in - object code or executable form with such an offer, in - accord with Subsection b above.) - - - - - - The source code for a work means the preferred form of the - work for making modifications to it. For an executable work, - complete source code means all the source code for all modules it - contains, plus any associated interface definition files, plus the - scripts used to control compilation and installation of the - executable. However, as a special exception, the source code - distributed need not include anything that is normally distributed - (in either source or binary form) with the major components - (compiler, kernel, and so on) of the operating system on which the - executable runs, unless that component itself accompanies the - executable. - - If distribution of executable or object code is made by - offering access to copy from a designated place, then offering - equivalent access to copy the source code from the same place - counts as distribution of the source code, even though third - parties are not compelled to copy the source along with the object - code. - - - - - - Section 4 - - You may not copy, modify, sublicense, or distribute the - Program except as expressly provided under this License. Any - attempt otherwise to copy, modify, sublicense or distribute the - Program is void, and will automatically terminate your rights - under this License. However, parties who have received copies, or - rights, from you under this License will not have their licenses - terminated so long as such parties remain in full - compliance. - - - - - - Section 5 - - You are not required to accept this License, since you have - not signed it. However, nothing else grants you permission to - modify or distribute the Program or its derivative works. These - actions are prohibited by law if you do not accept this License. - Therefore, by modifying or distributing the Program (or any work - based on the Program), you indicate your acceptance of this - License to do so, and all its terms and conditions for copying, - distributing or modifying the Program or works based on it. - - - - - - Section 6 - - Each time you redistribute the Program (or any work based on - the Program), the recipient automatically receives a license from - the original licensor to copy, distribute or modify the Program - subject to these terms and conditions. You may not impose any - further restrictions on the recipients' exercise of the rights - granted herein. You are not responsible for enforcing compliance - by third parties to this License. - - - - - - Section 7 - - If, as a consequence of a court judgment or allegation of - patent infringement or for any other reason (not limited to patent - issues), conditions are imposed on you (whether by court order, - agreement or otherwise) that contradict the conditions of this - License, they do not excuse you from the conditions of this - License. If you cannot distribute so as to satisfy simultaneously - your obligations under this License and any other pertinent - obligations, then as a consequence you may not distribute the - Program at all. For example, if a patent license would not permit - royalty-free redistribution of the Program by all those who - receive copies directly or indirectly through you, then the only - way you could satisfy both it and this License would be to refrain - entirely from distribution of the Program. - - If any portion of this section is held invalid or - unenforceable under any particular circumstance, the balance of - the section is intended to apply and the section as a whole is - intended to apply in other circumstances. - - It is not the purpose of this section to induce you to - infringe any patents or other property right claims or to contest - validity of any such claims; this section has the sole purpose of - protecting the integrity of the free software distribution system, - which is implemented by public license practices. Many people - have made generous contributions to the wide range of software - distributed through that system in reliance on consistent - application of that system; it is up to the author/donor to decide - if he or she is willing to distribute software through any other - system and a licensee cannot impose that choice. - - This section is intended to make thoroughly clear what is - believed to be a consequence of the rest of this License. - - - - - - Section 8 - - If the distribution and/or use of the Program is restricted - in certain countries either by patents or by copyrighted - interfaces, the original copyright holder who places the Program - under this License may add an explicit geographical distribution - limitation excluding those countries, so that distribution is - permitted only in or among countries not thus excluded. In such - case, this License incorporates the limitation as if written in - the body of this License. - - - - - - Section 9 - - The Free Software Foundation may publish revised and/or new - versions of the General Public License from time to time. Such - new versions will be similar in spirit to the present version, but - may differ in detail to address new problems or concerns. - - Each version is given a distinguishing version number. If - the Program specifies a version number of this License which - applies to it and any later version, you have the - option of following the terms and conditions either of that - version or of any later version published by the Free Software - Foundation. If the Program does not specify a version number of - this License, you may choose any version ever published by the - Free Software Foundation. - - - - - - Section 10 - - If you wish to incorporate parts of the Program into other - free programs whose distribution conditions are different, write - to the author to ask for permission. For software which is - copyrighted by the Free Software Foundation, write to the Free - Software Foundation; we sometimes make exceptions for this. Our - decision will be guided by the two goals of preserving the free - status of all derivatives of our free software and of promoting - the sharing and reuse of software generally. - - - - - - NO WARRANTY - Section 11 - - BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO - WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE - LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT - HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM AS IS WITHOUT - WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT - NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND - FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE - QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE - PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY - SERVICING, REPAIR OR CORRECTION. - - - - - - Section 12 - - IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO - IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY - MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE - LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, - INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR - INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF - DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU - OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY - OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN - ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. - - End of Terms and Conditions. - - - - - - - - How to Apply These Terms to Your New Programs - - If you develop a new program, and you want it to be of - the greatest possible use to the public, the best way to - achieve this is to make it free software which everyone can - redistribute and change under these terms. - - To do so, attach the following notices to the program. - It is safest to attach them to the start of each source file - to most effectively convey the exclusion of warranty; and each - file should have at least the copyright line - and a pointer to where the full notice is found. - - - <one line to give the program's name and a brief idea of what it does.> - Copyright (C) 19yy <name of author> - - This program is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation; either version 2 of the License, or - (at your option) any later version. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - - Also add information on how to contact you by electronic - and paper mail. - - If the program is interactive, make it output a short - notice like this when it starts in an interactive mode: - - - Gnomovision version 69, Copyright (C) 19yy name of author - Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. - This is free software, and you are welcome to redistribute it - under certain conditions; type `show c' for details. - - - The hypothetical commands `show w' and `show c' should - show the appropriate parts of the General Public License. Of - course, the commands you use may be called something other - than `show w' and `show c'; they could even be mouse-clicks or - menu items–whatever suits your program. - - You should also get your employer (if you work as a - programmer) or your school, if any, to sign a copyright - disclaimer for the program, if necessary. Here is a - sample; alter the names: - - - Yoyodyne, Inc., hereby disclaims all copyright interest in the program - `Gnomovision' (which makes passes at compilers) written by James Hacker. - - <signature of Ty Coon>, 1 April 1989 - Ty Coon, President of Vice - - - This General Public License does not permit - incorporating your program into proprietary programs. If your - program is a subroutine library, you may consider it more - useful to permit linking proprietary applications with the - library. If this is what you want to do, use the GNU Library - General Public License instead of this License. - - - - diff --git a/Manuals/Docbook/repository.docbook b/Manuals/Docbook/repository.docbook deleted file mode 100644 index b9373cc..0000000 --- a/Manuals/Docbook/repository.docbook +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - - - - - - - - - - - - - - -]> - - - - - - The CentOS Artwork Repository Manual - - - - Alain - Reguera Delgado - - - - - - 2009 - 2010 - 2011 - The CentOS Artwork SIG - - - - - Permission is granted to copy, distribute and/or modify - this document under the terms of the GNU Free - Documentation License, Version 1.2 or any later version - published by the Free Software Foundation; with no - Invariant Sections, no Front-Cover Texts, and no - Back-Cover Texts. A copy of the license is included in - the section entitled . - - - - Jun, 2011 - - - - This manuals documents relevant information regarding - the deployment, organization, and administration of - CentOS Artwork Repository. - - - - - - - Repository - &intro; - &dir; - - - - Licenses - &licenses-gpl; - &licenses-gfdl; - - - diff --git a/Manuals/Repository/repository-parts/Directories.docbook b/Manuals/Repository/repository-parts/Directories.docbook new file mode 100644 index 0000000..d3bb0bc --- /dev/null +++ b/Manuals/Repository/repository-parts/Directories.docbook @@ -0,0 +1,22 @@ + + + Directories + + The CentOS Artwork Repository uses directories to organize + files and describe conceptual idea about corporate identity. Such + conceptual ideas are explained in each directory related + documentation entry. + + In this chapter you'll learn what each directory inside The + CentOS Artwork Repository is for and so, how you can make use of + them. For that purpose, the following list of directories is + available for you to explore: + + &dir-trunk; + &dir-trunk-identity; + &dir-trunk-identity-models; + &dir-trunk-identity-models-themes; + &dir-trunk-identity-models-themes-default; + &dir-trunk-manuals; + + diff --git a/Manuals/Repository/repository-parts/Directories/trunk.docbook b/Manuals/Repository/repository-parts/Directories/trunk.docbook new file mode 100644 index 0000000..1847e6c --- /dev/null +++ b/Manuals/Repository/repository-parts/Directories/trunk.docbook @@ -0,0 +1,12 @@ + + + <filename class="directory">trunk</filename> + + The trunk directory + structure implements the Subversion's trunk concept in a trunk, + branches, tags repository structure. The trunk directory structure provides + the main development line inside the CentOS Artwork + Repository. + + diff --git a/Manuals/Repository/repository-parts/Directories/trunk/Identity.docbook b/Manuals/Repository/repository-parts/Directories/trunk/Identity.docbook new file mode 100644 index 0000000..b2ad8a1 --- /dev/null +++ b/Manuals/Repository/repository-parts/Directories/trunk/Identity.docbook @@ -0,0 +1,210 @@ + + + <filename class="directory">trunk/Identity</filename> + + The trunk/Identity + directory implements The CentOS Project corporate + identity based on the The CentOS Project + mission and release + schema. + + The CentOS Project exists to provide The CentOS + Distribution. Additionally, The CentOS Project provides The + CentOS Web and The CentOS Showroom to support and promote the + existence of The CentOS Distribution, respectively. + + The + CentOS Project corporate identity is the ``persona'' of the + organization known as The CentOS Project. The CentOS Project + corporate identity plays a significant role in the way The CentOS + Project, as organization, presents itself to both internal and + external stakeholders. In general terms, The CentOS Project + corporate identity expresses the values and ambitions of The + CentOS Project organization, its business, and its + characteristics. The CentOS Project corporate identity provides + visibility, recognizability, reputation, structure and + identification to The CentOS Project organization by means of + corporate design, corporate + communication, and corporate + behaviour. + + The + corporate design is focused on the effective communication of + corporate messages. Corporate messages are all the information + emitted from the corporation to a target audience. In order for + such communication to happen, it is required to put the messages + on a medium available for the target audience to react upon. + These media are know as corporate + manifestations, because the corporation manifests its + existence through them. The specific way used by the corporation + to set their messages on different media is what the corporate + design is about. + + The amount of manifestations a corporation uses to + communicate its existence may very from one corporation to + another. In the very specific case of The CentOS Project, the + following corporate manifestations come to mind: + + + + + The CentOS Distribution — This corporate + manifestaion is built from SRPM packages. There are SRPM + packages that make a remarkable use of images (e.g., Anaconda, + Grub, Syslinux, Gdm, Kdm, Gsplash, Ksplash, Rhgb, Firstboot, + etc.), packages that make a moderate use of images and + packages that don't use images at all. Also, there are some + packages that make use of text-based information that need to + be changed, too (e.g., release notes, eula, the welcome page + of the web browser, etc.), in order for The CentOS Project to + comply the redistribution guidelines of its upstream provider. + The CentOS Distribution corporate manifestation focuses its + attention on SRPM packages that use images in a remarkable + way, specifically those packages that contain branding + information, in both image and textual format, from the + upstream provider. This way, replacing image and text-based + files, we implement the corporate design of The CentOS + Distribution corporate manifestations. + + + + + The CentOS Web — This corporate manifestation + exists to support The CentOS Distribution corporate + manifestation. The CentOS Web corporate manifestation covers + web applications used by The CentOS Project to manifest its + existence on the Internet. These web applications are free + software and come from different providers which distribute + their work with predefined visual styles. Frequently, these + predefined visual styles have no visual relation among + themselves and introduce some visual contraditions when they + all are put together. These visual contraditions need to be + removed in order to comply with The CentOS Project corporate + structure guidelines. + + + + + The CentOS Showroom — This corporate manifestation + exists to promote The CentOS Distribution. The CentOS + Showroom corporate manifestation covers industrial production + of objects branded by The CentOS Project (e.g., clothes, + stationery and installation media). These branded objects are + for distribution on social events and/or shops. They provide + a way of promotion and a route for commercialization that may + help to aliviate The CentOS Project expenses (e.g., hosting, + servers, full-time-developers, etc.), in a similar way as + donations may do. + + + + + The corporate manifestations above seem to cover all the + media required by The CentOS Project, as organization, to show its + existence. However, other corporate manifestations could be added + in the future, if needed, to cover different areas like building, + offices, transportation and whaterver medium The CentOS Project + thouches to show its existence. + + The CentOS Project corporate communication is + based on community communication and takes + place through the following avenues: + + + The CentOS Chat (#centos, #centos-social}, + #centos-devel on irc.freenode.net) + The CentOS Mailing Lists (). + The CentOS Forums (). + The CentOS Wiki (). + Social events, interviews, conferences, etc. + + + + + The CentOS Project corporate behaviour is based on + community behaviour which take place in . + + The CentOS Project corporate structure is based on a + monolithic corporate visual identity + structure. In this configuration, one unique name and + one unique visual style is used in all corporate manifestations of + The CentOS Project. + + In a monolithic corporate visual identity structure, + internal and external stakeholders feel a strong sensation of + uniformity, orientation, and identification with the organization. + No matter if you are visiting web sites, using the distribution, + or acting on social events, the one unique name and one unique + visual style connects them all to say: Hey! we are all + part of The CentOS Project. + + Other corporate structures for The CentOS Project have been + considered as well. Such is the case of producing one different + visual style for each major release of The CentOS Distribution. + This structure isn't inconvenient at all, but some visual + contradictions could be introduced if it isn't applied correctly + and we need to be aware of it. To apply it correctly, we need to + know what The CentOS Project is made of. + + The CentOS Project, as organization, is mainly made of (but + not limited to) three corporate manifestions: The CentOS + Distribution, The CentOS Web and The CentOS Showroom. Inside The + CentOS Distribution corporate manifestations, The CentOS Project + maintains near to four different major releases of The CentOS + Distribution (e.g., the operating system), parallely in time. + However, inside The CentOS Web visual manifestations, the content + is produced for no specific release information (e.g., there is no + a complete web site for each major release of The CentOS + Distribution individually, but one web site to cover them all). + Likewise, the content produced in The CentOS Showroom is created + for no release-specific at all, but for The CentOS Project in + general. + + In order to produce the correct corporate structure for The + CentOS Project, we need to concider all the corporate + manifestations The CentOS Project is made of, not just one of + them. If one different visual style is used for each major + release of The CentOS Distribution, which one of those different + visual styles would be used to cover the remaining visual + manifestations The CentOS Project is made of (e.g., The CentOS Web + and The CentOS Showroom)? + + Probably you are thinking, that's right, but The CentOS + Brand connects them all already, why would we need to join them up + into the same visual style too, isn't it more work to do, and + harder to maintain? + + Harder to maintain, more work to do, probably. Specially + when you consider that The CentOS Project has proven stability and + consistency through time and, that, certainly, didn't come through + swinging magical wands or something but hardly working out to + automate tasks and providing maintainance through time. Said that, + we consider that The CentOS Project corporate structure must be + consequent with such stability and consistency tradition, beyond + the work it might require initially. It is true that The CentOS + Brand does connect all the visual manifestations it is present on, + but that connection would be stronger if one unique visual style + backups it, too. In fact, whatever thing you do to strength the + visual connection among The CentOS Project corporate + manifestations would be very good in favor of The CentOS Project + recognition. + + Obviously, having just one visual style in all corporate + manifestations for eternity would be a very boring thing and would + give the impression of a visually dead project. So, there is no + problem on creating a brand new visual style for each new major + release of The CentOS Distribution, in order to refresh The CentOS + Distribution visual style; the problem itself is in not + propagating the brand new visual style created for the new release + of The CentOS Distribution to all other visual manifestations The + CentOS Project is made of, in a way The CentOS Project could be + recognized no matter what corporate manifestation be in front of + us. Such lack of uniformity is what introduces the visual + contradition we are precisely trying to solve by mean of themes + production in the CentOS Artwork Repository. + + diff --git a/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models.docbook b/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models.docbook new file mode 100644 index 0000000..fba2893 --- /dev/null +++ b/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models.docbook @@ -0,0 +1,4 @@ + + <filename class="directory">trunk/Identity/Models</filename> + ... + diff --git a/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models/Themes.docbook b/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models/Themes.docbook new file mode 100644 index 0000000..a2660e4 --- /dev/null +++ b/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models/Themes.docbook @@ -0,0 +1,31 @@ + + + <filename class="directory">trunk/Identity/Models/Themes</filename> + + This directory implements the concept of themes' + design models. + + Themes' design models provide the structural part of images + (e.g., dimensions, translation markers, position of each element + on the visible area, etc.) required by + centos-art.sh to perform theme rendition. The + provide the modeling characteristics for all the different visual + manifestations a theme is made of. Using themes' design models + reduce the time needed for propagating an artistic motif to + different visual manifestations. + + In this directory, themes' design models are organized by + name. There is one directory for each theme's design model. Each + design model directory must be named as specified in . Inside themes' design models + directories, there is one directory for each visual manifestions a + theme is made of. These directories are named visual + manifestation directories and contain one or more SVG + files to describe the visual structure of that visual + manifestion. + + Themes' design models are SVG files and + can be localized using the locale functionality of + centos-art.sh script. + + diff --git a/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models/Themes/Default.docbook b/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models/Themes/Default.docbook new file mode 100644 index 0000000..30fe79b --- /dev/null +++ b/Manuals/Repository/repository-parts/Directories/trunk/Identity/Models/Themes/Default.docbook @@ -0,0 +1,16 @@ + + + <filename class="directory">trunk/Identity/Models/Themes/Default</filename> + + This directory implements the concept of themes' + default design models. + + Themes' default design models provide the common structural + information (e.g., image dimensions, translation markers, + trademark position, etc.) the centos-art.sh + script uses to produce images when no other design model is + specified through the option at + rendition time. + + diff --git a/Manuals/Repository/repository-parts/Directories/trunk/Manuals.docbook b/Manuals/Repository/repository-parts/Directories/trunk/Manuals.docbook new file mode 100644 index 0000000..f089182 --- /dev/null +++ b/Manuals/Repository/repository-parts/Directories/trunk/Manuals.docbook @@ -0,0 +1,4 @@ + + <filename class="directory">trunk/Manuals</filename> + ... + diff --git a/Manuals/Repository/repository-parts/Introduction.docbook b/Manuals/Repository/repository-parts/Introduction.docbook new file mode 100644 index 0000000..c0a4d95 --- /dev/null +++ b/Manuals/Repository/repository-parts/Introduction.docbook @@ -0,0 +1,26 @@ + + + Introduction + + Welcome to The CentOS Artwork Repository + Manual. + + The CentOS Artwork Repository Manual describes how The + CentOS Project corporate visual identity is organized and produced + inside the CentOS Artwork Repository (). If you are + looking for a comprehensive, task-oriented guide for understanding + how The CentOS Project corporate visual identity is produced, this + is the manual for you. + + This guide assumes you have a basic understanding of The + CentOS Distribution. If you need help with CentOS, refer to the + help page on The CentOS Wiki () for a list of different + places you can find help. + + &intro-history; + &intro-copying; + &intro-usage; + + diff --git a/Manuals/Repository/repository-parts/Introduction/copying.docbook b/Manuals/Repository/repository-parts/Introduction/copying.docbook new file mode 100644 index 0000000..1c679e0 --- /dev/null +++ b/Manuals/Repository/repository-parts/Introduction/copying.docbook @@ -0,0 +1,91 @@ + + + Copying conditions + + Copyright © 2009, 2010, 2011 The CentOS Project + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + + + Preamble + + The CentOS Artwork Repository organizes files in a very + specific way to implement The CentOS Project corporate visual + identity. This very specific organization of files must be + considered part of centos-art.sh script, a bash + script that automate most of the frequent tasks inside the + repository. + + The centos-art.sh script and the + organization of files it needs to work are not in the public + domain; they are 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 program that they might get from you. + + Specifically, we want to make sure that you have the right + to give away copies of centos-art.sh script and + the organization of files it needs to work, that you receive + source code or else can get it if you want it, that you can change + this program or use pieces of it in new free programs, 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 centos-art.sh + script, 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 + centos-art.sh script. If this program 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 centos-art.sh script is released as a + GPL work. Individual packages used by + centos-art.sh script include their own licenses + and the centos-art.sh script license applies to + all packages that it does not clash with. If there is a clash + between the centos-art.sh script license and + individual package licenses, the individual package license + applies instead. + + The precise conditions of the license for the + centos-art.sh script are found in the . This manual specifically is + covered by the . + + + + + The CentOS Brand + + The CentOS Brand () is the main visual manifestaion of The + CentOS Project. The CentOS Project uses The CentOS Brand to + connect all its visual manifestions (e.g., GNU/Linux + Distributions, Websites, Stationery, etc.) and, this way, it + provides recognition among other similar projects available on the + Internet. + + Both The CentOS Brand and all the visual manifestations that + derivate from it are available for you to study and propose + improvement around a good citizen's will at The CentOS Community + environment, but you are not allowed to redistribute them + elsewhere, without the given permission of The CentOS + Project. + + If you need to redistribute either The CentOS Brand or any + visual manifestation derived from it, write your intentions to the + The CentOS Developers mailing list + (centos-devel@centos.org). + + + + + diff --git a/Manuals/Repository/repository-parts/Introduction/document-convenctions.docbook b/Manuals/Repository/repository-parts/Introduction/document-convenctions.docbook new file mode 100644 index 0000000..8e12a51 --- /dev/null +++ b/Manuals/Repository/repository-parts/Introduction/document-convenctions.docbook @@ -0,0 +1,147 @@ +
+ + Document convenctions + + In this manual the personal pronoun we + is used to repesent The CentOS Artwork SIG, + the group of persons that build The CentOS Project corporate + visual identity through the CentOS Artwork Repository. + + In this manual, certain words are represented in different + fonts, typefaces, sizes, and weights. This highlighting is + systematic; different words are represented in the same style to + indicate their inclusion in a specific category. The types of + words that are represented this way include the following: + + + + command + + Linux commands (and other operating system + commands, when used) are represented this way. This + style should indicate to you that you can type the + word or phrase on the command line and press Enter to + invoke a command. Sometimes a command contains words + that would be displayed in a different style on their + own (such as file names). In these cases, they are + considered to be part of the command, so the entire + phrase is displayed as a command. For example: + + Use the centos-art identity + --render='path/to/dir' command to produce + contents inside the trunk/Identity directory + structure. + + + + + + file name + + File names, directory names, paths, and RPM + package names are represented this way. This style + indicates that a particular file or directory exists + with that name on your system. Examples: + + The init.sh file in + trunk/Scripts/Bash/Cli/ + directory is the initialization script, written in + Bash, used to automate most of tasks in the + repository. + + The centos-art command uses + the ImageMagick RPM package to + convert images from PNG format to other + formats. + + + + + + key + + A key on the keyboard is shown in this style. + For example: + + To use TAB completion to list + particular files in a directory, type @command{ls}, + then a character, and finally the Tab key. Your + terminal displays the list of files in the working + directory that begin with that character. + + + + + key-combination + + A combination of keystrokes is represented in + this way. For example: + + The CtrlAltBackspace + key combination exits your graphical session and + returns you to the graphical login screen or the + console. + + + + + + + computer output + + Text in this style indicates text displayed to a + shell prompt such as error messages and responses to + commands. For example: + + The ls command displays the + contents of a directory. For example: + + +Config help_renameEntry.sh +help_copyEntry.sh help_restoreCrossReferences.sh +help_deleteCrossReferences.sh help_searchIndex.sh + + + The output returned in response to the command (in this + case, the contents of the directory) is shown in this + style. + + + + + Additionally, we use several different strategies to draw + your attention to certain pieces of information. In order of + urgency, these items are marked as a note, tip, important, + caution, or warning. For example: + + + Remember that Linux is case sensitive. In other words, a + rose is not a ROSE is not a rOsE. + + + + The directory @file{/usr/share/doc/} contains additional + documentation for packages installed on your system. + + + + If you modify the DHCP configuration file, the changes + do not take effect until you restart the DHCP daemon. + + + + Do not perform routine tasks as root — use a + regular user account unless you need to use the root account + for system administration tasks. + + + + Be careful to remove only the necessary partitions. + Removing other partitions could result in data loss or a + corrupted system environment. + + +
diff --git a/Manuals/Repository/repository-parts/Introduction/history.docbook b/Manuals/Repository/repository-parts/Introduction/history.docbook new file mode 100644 index 0000000..8d75b67 --- /dev/null +++ b/Manuals/Repository/repository-parts/Introduction/history.docbook @@ -0,0 +1,148 @@ + + + History + + The CentOS Artwork Repository started around 2008 during a + discussion about how to automate the slide images of Anaconda, at + CentOS Developers mailing list (centos-devel@centos.org). In such + discussion, Ralph Angenendt rose up his hand to ask —Do you have + something to show?—. + + To answer the question, I suggested a bash script which + combined SVG and SED files in order to produce PNG images in + different languages —together with the proposition of + creating a Subversion repository where translations and image + production could be distributed inside The CentOS + Community—. + + Karanbirn Sighn considered the idea intresting and provided + the infrastructure necessary to support the effort. This way the + CentOS Artwork SIG (https://projects.centos.org/trac/artwork/) and + the CentOS Artwork Repository + (https://projects.centos.org/svn/artwork/) were officially + created. + + Once the CentOS Artwork Repository was available, I uploaded + the bash script for rendering Anaconda slides; Ralph Angenendt + documented it very well; and people started to download working + copies of CentOS Artwork Repository to produce slide images in + their own languages. + + Around 2009, the rendition script was at a very rustic state + where only slide images could be produced, so it was redesigned to + extend the image production to other areas, different from slide + images. In this configuration, one SVG file was used as input to + produce a translated instance of it which, in turn, was used to + produce one translated PNG image as output. The SVG translated + instance was created through SED replacement commands. The + translated PNG image was created from the SVG translated instance + using Inkscape command-line interface. + + The repository directory structure was prepared to receive + the rendition script using design templates and translation files + in the same location. There was one directory structure for each + artwork that needed to be produced. In this configuration, if you + would want to produce the same artwork with a different visual + style or structure, it was needed to create a new directory + structure for it because both the image structure and the image + visual style were together in the design template. + + The rendition script was moved to a common place and linked + from different directory structures. There was no need to have the + same code in different directory structures if it could be in just + one place and then be linked from different locations. + + The concepts about corporate identity began to be + considered. As referece, it was used the book Corporate + Identity by Wally Olins (1989) and Wikipedia related links + (e.g., ). This way, the rendition script main's goal becomes to: + automate production of a monolithic corporate visual identity + structure, based on the mission and the release schema of The + CentOS Project. + + The repository directory structures began to be documented + inside by mean of flat text files. Later, documentation in flat + text files was moved onto LaTeX format and this way The + CentOS Artwork Repository Manual is initiated. + + Around 2010, the rendition script changed its name from + render.sh to centos-art.sh + and became a collection of functionalities where rendition was + just one among others (e.g., documenting and localizing). + + The centos-art.sh was initialy conceived + to organize automation of most frequent tasks inside the + repository based in the conceptual idea of Unix toolbox: + create small and specialized tools that do one thing + well. This way, functionalities inside + centos-art.sh were identified and separated one + another. For example, when images were rendered, there was no need + to load functionalities related to documentation manual. This + layout moved us onto common functionalities and specific + functionalities inside centos-art.sh script. + Common functionalities are loaded when + centos-art.sh script is initiated and are + available to specific functionalities. + + There was no need to have links all around the + repository if a command-line interface could be created (through + symbolic links, in the ~/bin directory) and be called + anywhere inside the repository as it would be a regular + command. + + The centos-art.sh script was redesigned + to handle command-line options trough getopt + option parser. + + The repository directory structure was updated to improve + the implementation of concepts related to corporate visual + identity. Specially in the area related to themes which were + divided into design models and + artistic motifs to eliminate the content + duplication produced by having both image structure and image + visual style in the same file. Now, both + centos-art.sh and repository directory + structure are able to produce themes as result of arbitrary + combinations between design models (structures) and artistic + motifs (visual styles). + + In the documentation area, the documentation files in LaTeX + format were migrated to Texinfo format. In this configuration, + each directory structure in the repository has a documentation + entry associated in a Texinfo structure which can be read, edited + and administered (e.g., renamed, deleted, copied) interactively + throuch centos-art.sh. Additionally, the + texi2html program was used to produced XHTML + output customized by CSS from The CentOS Webenv. + + Around 2011, the centos-art.sh script was + redesigned to start translating SVG and other XML-based files + (e.g., XHTML and Docbook files) through the + xml2po program and shell scripts files (e.g., + Bash scripts) through GNU gettext tools. This + configuration provided a stronger interface for graphic designers, + translators and programmers to produce localized content. The SED + files are no longer used to handle translations. + + The render, help and + locale functionalities were consolidated as the most + frequent tasks performed inside the repository. Additionally, the + prepare and tuneup functionalities are + maintained as useful tasks. + + The centos-art.sh script is updated to + organize functionalities in two groups: the administrative + functionalities and the productive + functionalities. The administrative functionalities cover + actions like: copying, deleting and renaming directory structures + inside the repository. Also, preparing your workstation for using + centos-art.sh script, making backups of the + distribution theme currently installed, installing themes created + inside repository and restoring themes from backup. On the other + hand, the productive functionalities cover actions like: content + rendition, content localization, content documentation and content + maintainance. + + diff --git a/Manuals/Repository/repository-parts/Introduction/send-in-your-feedback.docbook b/Manuals/Repository/repository-parts/Introduction/send-in-your-feedback.docbook new file mode 100644 index 0000000..198696e --- /dev/null +++ b/Manuals/Repository/repository-parts/Introduction/send-in-your-feedback.docbook @@ -0,0 +1,17 @@ +
+ + Send in your feedback + + If you find an error in the CentOS Artwork + Repository, or if you have thought of a way to make + this manual better, we would like to hear from you! Share your + suggestions in the appropriate mailing list + (http://lists.centos.org/) and/or bug tracker + (http://bugs.centos.org/). + + When you make suggestion, try to be as specific as possible. + For example, if you have found an error in the manual, include the + section number and some of the surrounding text so we can find it + easily. + +
diff --git a/Manuals/Repository/repository-parts/Introduction/usage.docbook b/Manuals/Repository/repository-parts/Introduction/usage.docbook new file mode 100644 index 0000000..235972f --- /dev/null +++ b/Manuals/Repository/repository-parts/Introduction/usage.docbook @@ -0,0 +1,369 @@ + + + Usage convenctions + + The CentOS Artwork Repository is supported by Subversion + (http://subversion.tigris.org/), 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. + + When using Subversion there is one "source repository" and + many "working copies" of that source repository. The working + copies are independent one another, can be distributed all around + the world and provide a local place for designers, documentors, + translators and programmers to perform their work in a + descentralized way. The source repository, on the other hand, + provides a central place for all independent working copies to + interchange data and provides the information required to permit + extracting previous versions of files at any time. + + + + Policy + + The CentOS Artwork Repository is a collaborative tool + that anyone can have access to. However, changing that tool in + any form is something that should be requested in the CentOS + Developers mailing list (centos-devel@centos.org). Generally, + people download working copies from CentOS Artwork Repository, + study the repository organization, make some changes in their + working copies, make some tests to verify such changes do work + the way expected and finally request access to commit them up + to the CentOS Artwork Repository (i.e., the source repository) + for others to benefit from them. + + Once you've received access to commit your changes, + there is no need for you to request permission again to commit + other changes from your working copy to CentOS Artwork + Repository as long as you behave as a good + cooperating citizen. Otherwise, your rights to + commit changes might be temporarly revoked or permanently + banished. + + 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. Anyway, 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 the CentOS Artwork Repository to accomplish + its mission which is: to provide a colaborative tool for The + CentOS Community where The CentOS Project corporate visual + identity is built and maintained by The CentOS Community + itself. + + It is also important to remember that all the program + and documentation source files inside CentOS Artwork + Repository must comply the terms of and + respectively in order for them to remain inside the + repository. + + + + + + Work lines + + Content production inside the repository is organized by + work lines. There are three major work + lines of production inside The CentOS Artwork Repository, + which are: Graphic design, + Documentation and + Localization. The specific way of + producing content inside each specific work line is + standardized by mean of centos-art.sh + script (which in turn, can be considered a work line by itself + [e.g., the Automation work line]). The + centos-art.sh script provides one specific + functionality for automating each major work line of content + production (e.g., render for producing images, + help for manage documentation, and + locale for localizing contents). + + The graphic design work line exists to cover brand + design, typography design and themes design mainly. + Additionally, some auxiliar areas like icon design, + illustration design, brushes design, patterns designs and + palettes of colors are also included here for completeness. + The graphic design work line is organized in the trunk/Identity directory. + + The documentation work line exists to describe what each + directory inside the CentOS Artwork Repository is for, the + conceptual ideas behind them and, if possible, how automation + scripts make use of them. The documentation work line is + organized in the trunk/Manuals directory. + + The localization work line exists to provide the + translation messages required to produce content in different + languages. Translation messages inside the repository are + stored as portable objects (e.g., .po, .pot) and machine + objects (.mo). The localization work line is organized in the + trunk/Locales + directory. + + The automation work line exists to standardize content + production inside the working copies of CentOS Artwork + Repository. Here is developed the + centos-art.sh script, a bash script + specially designed to automate most frequent tasks (e.g., + rendition, documentation and localization) inside the + repository. There is no need to type several tasks, time + after time, if they can be programmed into just one executable + script. The automation work line is organized in the + trunk/Scripts + directory. + + + + + + Relation between directories + + In order for automation scripts to produce content inside a + working copy of CentOS Artwork Repository, it is required that all + work lines be related somehow. The relation is used by automation + scripts to know where to retrive the information they need to work + with (e.g., design model, translation messages, output locations, + etc.). This kind of relation is built using two path + constructions named master paths and + auxiliar paths. + + The master path points only to directories that contain + source files (e.g., SVG files) required to produce output base + content (e.g., PNG files) through automation scripts. Each master + path inside the repository may have several auxiliar paths + associated, but auxiliar paths can only have one master path + associated. + + Master paths used for producing images through SVG rendition + are organized under trunk/Identity/Models directory + structure and the auxiliar paths under trunk/Identity/Images, trunk/Locales and trunk/Manuals directory + structures. + + Auxiliar paths can point either to directories or files. + When an auxiliar path points to a directory, that directory + contains information that modifies somehow the content produced + from master paths (e.g., translation messages) or provides the + output information required to know where the content produced + from the master path should be stored. When an auxiliar path + points to a file, that file has no other purpose but to document + the master path it refers to. + + Auxiliar paths should never be modified under any reason but + to satisfy the relationship with the master path. Liberal change + of auxiliar paths may suppress the conceptual idea they were + initially created for; and certainly, automation scripts may stop + working as expected. + + The relationship between auxiliar paths and master paths is + built by combining the master path and the second level directory + structures of the repository. The master path is considered the + path identifier and the repository second level directory + structure is considered the common part of the path where the path + identifier is appended to. So, if we have the master path + trunk/Identity/Models/Brands, we'll + end up having, at least, the trunk/Identity/Images/Brands auxiliar + path for storing output files and, optionally, one path under + trunk/Manuals for storing + documentation and one path under trunk/Locales for storing + localizations. + + + + + + Syncronizing paths + + Once both master paths and their auxiliar paths have been + set, they shouldn't be changed. Assuming one master path must be + changed it is required that all related auxiliar paths be changed, + too. This is required in order for master paths to retain their + relation with auxiliar paths. This process of keeping relation + between master paths and auxiliar paths is known as path + syncronization. + + Path syncronization is required for automation scripts to + know where to store final output, where to retrive translation + messages, documentation, and any information that might be + desired. If the relation between master paths and auxiliar paths + is lost, there is no way for centos-art.sh + script to know where to retrive the information it needs to work + with. Path syncronization is the way we use to organize and + extend the information stored in the repository. + + Path syncronization may imply 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. + + The order followed to syncronize path information is very + important because the versioned nature of the repository files we + are working with. When a renaming action must be performed, we + avoid making replacements inside files first and file movements + later. This would require two commit actions: one for the files' + internal changes and another for the file movement itself. + Otherwise, we prefer to perform file movements first and file + 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 commands + instead. + + At this moment there is no full implementation of path + syncronization process inside centos-art.sh + script except by texinfo backend of + help functionality which provides a restricted + implementation of path syncronization to this specific area of + documentation through the , + and options. + The plan for a full implementation of path syncronization would be + to create individual restricted implementations like this one for + other areas that demand it and then, create a higher implmentation + that combines all restricted implementations as needed. This way, + if we try to rename a repository directory the higer action will + define which are all the restricted actions that should be + performed in order for make a full path syncronization. For + example, if the directory we are renaming is part of graphic + design work line, it is required to syncronize related paths in + documentation and localization work lines. Likewise, if the + directory we are renaming is in documentation work line, it is + required to syncronize related paths in graphic design and + localization work lines. In all these cases, the direction used + for syncronizing paths must be from master path to auxiliar path + and never the opposite (i.e., rename the master path first and + auxiliar paths later). + + A practical example, through which you can notice the + usefulness of path syncronization process, is what happen when + documentation entries are renamed (see section ...). + + + + + + Extending repository organization + + Occasionly, you may find that new components of The + CentOS Project corporate visual identity 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 start to + create directories blindly all over, is: What is the + right place to store it? + + The best place to find answers is in The CentOS + Community (see page http://wiki.centos.org/Help), but going + there with hands empty is not good idea. It may give the + impression you don't really care about. Instead, consider the + following suggestions to find your own comprehension in order + to make your own propositions based on it. + + When extending respository structure it is very useful + to bear in mind The CentOS Project corporate visual identity + structure, The CentOS Mission and The CentOS Release Schema. + The rest is a matter of choosing appropriate names. It is also + worth to know that each directory in the repository responds + to a conceptual idea that justifies its existence. + + To build a directory structure inside the repository, + you need to define the conceptual idea first and later create + the directory, remembering that there are locations inside the + repository that define conceptual ideas you probably would + prefer to reuse. For example, the trunk/Identity/Images/Themes + directory stores theme artistic motifs, the trunk/Identity/Models/Themes + directory stores theme design models, the trunk/Manuals directory stores + documentation files, the trunk/Locales stores translation + messages, and the trunk/Scripts stores automation + scripts. + + To better illustrate this desition process, you can + consider to examin the trunk/Identity/Images/Themes/TreeFlower/3 + directory structure as example. This directory can be read + as: the theme development line of version 3 of + TreeFlower artistic motif. Additional, we can + say that TreeFlower artistic motif is part of + themes, as themes are part of The CentOS Project corporate + visual identity. + + The relationship between conceptual ideas can be + stablished by reading each repository documentation entry + individually, from trunk directory to a deeper + directory in the path. For reading repository documentation + entries we use the help functionality of + centos-art.sh script. + + + + + + File names convenction + + Inside the CentOS Artwork Repository, generally, file + names are all written in lowercase (e.g., + 01-welcome.png, + splash.png, + anaconda_header.png, etc.) and directory + names are all written capitalized (e.g., Identity, Themes, Motifs) and sometimes in cammel + case (e.g., TreeFlower, + etc.). + + In the very specific case of repository documentation + entries, file names follow the directory 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, documentation entries follow the name + convenction used by the item they document. + + + + + + Repository layout + + The CentOS Artwork Repository is organized through a + convenctional trunk, branches + and tags layout. Explanation of each directory + inside the repository can be found in the chapter. + + + + diff --git a/Manuals/Repository/repository-parts/Licenses/gfdl.docbook b/Manuals/Repository/repository-parts/Licenses/gfdl.docbook new file mode 100644 index 0000000..789bb53 --- /dev/null +++ b/Manuals/Repository/repository-parts/Licenses/gfdl.docbook @@ -0,0 +1,591 @@ + + + GNU Free Documentation License + + Version 1.2, November 2002 + + Copyright © 2000, 2001, 2002 Free Software Foundation, + Inc. 675 Mass Ave, Cambridge, MA 02139, USA + + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + + + Preamble + + The purpose of this License is to make a manual, + textbook, or other functional and useful document + free in the sense of freedom: to assure + everyone the effective freedom to copy and redistribute it, + with or without modifying it, either commercially or + noncommercially. Secondarily, this License preserves for the + author and publisher a way to get credit for their work, while + not being considered responsible for modifications made by + others. + + This License is a kind of copyleft, which + means that derivative works of the document must themselves be + free in the same sense. It complements the , which is a copyleft license + designed for free software. + + We have designed this License in order to use it for + manuals for free software, because free software needs free + documentation: a free program should come with manuals + providing the same freedoms that the software does. But this + License is not limited to software manuals; it can be used for + any textual work, regardless of subject matter or whether it + is published as a printed book. We recommend this License + principally for works whose purpose is instruction or + reference. + + + + + + Applicability and definitions + + This License applies to any manual or other work, in any + medium, that contains a notice placed by the copyright holder + saying it can be distributed under the terms of this License. + Such a notice grants a world-wide, royalty-free license, + unlimited in duration, to use that work under the conditions + stated herein. The Document, below, refers to + any such manual or work. Any member of the public is a + licensee, and is addressed as you. You accept + the license if you copy, modify or distribute the work in a + way requiring permission under copyright law. + + A + Modified Version of the Document means any work + containing the Document or a portion of it, either copied + verbatim, or with modifications and/or translated into another + language. + + A + Secondary Section is a named appendix or a + front-matter section of the Document that deals exclusively + with the relationship of the publishers or authors of the + Document to the Document's overall subject (or to related + matters) and contains nothing that could fall directly within + that overall subject. (Thus, if the Document is in part a + textbook of mathematics, a may not explain any mathematics.) The relationship could be + a matter of historical connection with the subject or with + related matters, or of legal, commercial, philosophical, + ethical or political position regarding them. + + The Invariant Sections are certain + whose titles are + designated, as being those of Invariant Sections, in the + notice that says that the Document is released under this + License. If a section does not fit the above definition of + Secondary then it is not allowed to be designated as + Invariant. The Document may contain zero Invariant Sections. + If the Document does not identify any Invariant Section then + there are none. + + The + Cover Texts are certain short passages of text + that are listed, as Front-Cover Texts or Back-Cover Texts, in + the notice that says that the Document is released under this + License. A Front-Cover Text may be at most 5 words, and a + Back-Cover Text may be at most 25 words. + + A + Transparent copy of the Document means a + machine-readable copy, represented in a format whose + specification is available to the general public, that is + suitable for revising the document straightforwardly with + generic text editors or (for images composed of pixels) + generic paint programs or (for drawings) some widely available + drawing editor, and that is suitable for input to text + formatters or for automatic translation to a variety of + formats suitable for input to text formatters. A copy made in + an otherwise file format whose + markup, or absence of markup, has been arranged to thwart or + discourage subsequent modification by readers is not . An image format is not if used for any substantial amount of + text. A copy that is not is called Opaque. + + Examples of suitable formats for copies + include plain ASCII without markup, Texinfo input format, + LaTeX input format, SGML or XML using a publicly available + DTD, and standard-conforming simple HTML, PostScript or PDF + designed for human modification. Examples of transparent + image formats include PNG, XCF and JPG. Opaque formats + include proprietary formats that can be read and edited only + by proprietary word processors, SGML or XML for which the DTD + and/or processing tools are not generally available, and the + machine-generated HTML, PostScript or PDF produced by some + word processors for output purposes only. + + The Title + Page means, for a printed book, the title page itself, + plus such following pages as are needed to hold, legibly, the + material this License requires to appear in the title page. + For works in formats which do not have any title page as such, + Title Page means the text near the most + prominent appearance of the work's title, preceding the + beginning of the body of the text. + + A section Entitled XYZ means a named + subunit of the Document whose title either is precisely XYZ or + contains XYZ in parentheses following text that translates XYZ + in another language. (Here XYZ stands for a specific section + name mentioned below, such as Acknowledgements, + Dedications, Endorsements, or + History.) To Preserve the Title + of such a section when you modify the Document means that it + remains a section Entitled XYZ according to + this definition. + + The Document may include Warranty Disclaimers next to + the notice which states that this License applies to the + Document. These Warranty Disclaimers are considered to be + included by reference in this License, but only as regards + disclaiming warranties: any other implication that these + Warranty Disclaimers may have is void and has no effect on the + meaning of this License. + + + + + + Verbatim copying + + You may copy and distribute the Document in any medium, + either commercially or noncommercially, provided that this + License, the copyright notices, and the license notice saying + this License applies to the Document are reproduced in all + copies, and that you add no other conditions whatsoever to + those of this License. You may not use technical measures to + obstruct or control the reading or further copying of the + copies you make or distribute. However, you may accept + compensation in exchange for copies. If you distribute a + large enough number of copies you must also follow the + conditions in section . + + You may also lend copies, under the same conditions + stated above, and you may publicly display copies. + + + + + + Copying in quantity + + If you publish printed copies (or copies in media that + commonly have printed covers) of the Document, numbering more + than 100, and the Document's license notice requires Cover + Texts, you must enclose the copies in covers that carry, + clearly and legibly, all these : + Front-Cover Texts on the front cover, and Back-Cover Texts on + the back cover. Both covers must also clearly and legibly + identify you as the publisher of these copies. The front + cover must present the full title with all words of the title + equally prominent and visible. You may add other material on + the covers in addition. Copying with changes limited to the + covers, as long as they preserve the title of the Document and + satisfy these conditions, can be treated as verbatim copying + in other respects. + + If the required texts for either cover are too + voluminous to fit legibly, you should put the first ones + listed (as many as fit reasonably) on the actual cover, and + continue the rest onto adjacent pages. + + If you publish or distribute Opaque copies of the + Document numbering more than 100, you must either include a + machine-readable copy along with each Opaque copy, + or state in or with each Opaque copy a computer-network + location from which the general network-using public has + access to download using public-standard network protocols a + complete copy of the Document, free of added + material. If you use the latter option, you must take + reasonably prudent steps, when you begin distribution of + Opaque copies in quantity, to ensure that this + copy will remain thus accessible at the stated location until + at least one year after the last time you distribute an Opaque + copy (directly or through your agents or retailers) of that + edition to the public. + + It is requested, but not required, that you contact the + authors of the Document well before redistributing any large + number of copies, to give them a chance to provide you with an + updated version of the Document. + + + + + + Modifications + + You may copy and distribute a of the Document under the + conditions of sections and above, + provided that you release the under precisely this License, with the filling the role of the + Document, thus licensing distribution and modification of the + to whoever possesses a + copy of it. In addition, you must do these things in the + : + + + + + Use in the (and on + the covers, if any) a title distinct from that of the + Document, and from those of previous versions (which + should, if there were any, be listed in the History + section of the Document). You may use the same title + as a previous version if the original publisher of + that version gives permission. + + + List on the , as + authors, one or more persons or entities responsible + for authorship of the modifications in the , together with at least + five of the principal authors of the Document (all of + its principal authors, if it has fewer than five), + unless they release you from this requirement. + + + + State on the the + name of the publisher of the , as the + publisher. + + + + Preserve all the copyright notices of the + Document. + + + + Add an appropriate copyright notice for your + modifications adjacent to the other copyright + notices. + + + + Include, immediately after the copyright + notices, a license notice giving the public permission + to use the under the terms of this + License, in the form shown in the Addendum + below. + + + + Preserve in that license notice the full lists + of and required + given in the Document's + license notice. + + + + Include an unaltered copy of this License. + + + + Preserve the section Entitled + History, Preserve its Title, and add to + it an item stating at least the title, year, new + authors, and publisher of the as given on the . If there is no section + Entitled History in the Document, create + one stating the title, year, authors, and publisher of + the Document as given on its , then add an item describing the as stated in the previous + sentence. + + + + Preserve the network location, if any, given in + the Document for public access to a copy of the Document, and + likewise the network locations given in the Document + for previous versions it was based on. These may be + placed in the History section. You may + omit a network location for a work that was published + at least four years before the Document itself, or if + the original publisher of the version it refers to + gives permission. + + + + For any section Entitled + Acknowledgements or + Dedications, Preserve the Title of the + section, and preserve in the section all the substance + and tone of each of the contributor acknowledgements + and/or dedications given therein. + + + + Preserve all the of the Document, + unaltered in their text and in their titles. Section + numbers or the equivalent are not considered part of + the section titles. + + + + Delete any section Entitled + Endorsements. Such a section may not + be included in the . + + + + Do not retitle any existing section to be + Entitled Endorsements or to conflict in + title with any . + + + Preserve any Warranty Disclaimers. + + + + + If the includes new + front-matter sections or appendices that qualify as and contain no material copied + from the Document, you may at your option designate some or + all of these sections as invariant. To do this, add their + titles to the list of in the 's license notice. These titles + must be distinct from any other section titles. + + You may add a section Entitled + Endorsements, provided it contains nothing but + endorsements of your by various + parties–for example, statements of peer review or that + the text has been approved by an organization as the + authoritative definition of a standard. + + You may add a passage of up to five words as a + Front-Cover Text, and a passage of up to 25 words as a + Back-Cover Text, to the end of the list of in the . Only one passage of + Front-Cover Text and one of Back-Cover Text may be added by + (or through arrangements made by) any one entity. If the + Document already includes a cover text for the same cover, + previously added by you or by arrangement made by the same + entity you are acting on behalf of, you may not add another; + but you may replace the old one, on explicit permission from + the previous publisher that added the old one. + + The author(s) and publisher(s) of the Document do not by + this License give permission to use their names for publicity + for or to assert or imply endorsement of any . + + + + + + Combining documents + + You may combine the Document with other documents + released under this License, under the terms defined in + section above for + modified versions, provided that you include in the + combination all of the of + all of the original documents, unmodified, and list them all + as of your combined work + in its license notice, and that you preserve all their + Warranty Disclaimers. + + The combined work need only contain one copy of this + License, and multiple identical may be replaced with a single + copy. If there are multiple with the same name but + different contents, make the title of each such section unique + by adding at the end of it, in parentheses, the name of the + original author or publisher of that section if known, or else + a unique number. Make the same adjustment to the section + titles in the list of in + the license notice of the combined work. + + In the combination, you must combine any sections + Entitled History in the various original + documents, forming one section Entitled + History; likewise combine any sections Entitled + Acknowledgements, and any sections Entitled + Dedications. You must delete all sections + Entitled Endorsements. + + + + + + Collection of documents + + You may make a collection consisting of the Document and + other documents released under this License, and replace the + individual copies of this License in the various documents + with a single copy that is included in the collection, + provided that you follow the rules of this License for + verbatim copying of each of the documents in all other + respects. + + You may extract a single document from such a + collection, and distribute it individually under this License, + provided you insert a copy of this License into the extracted + document, and follow this License in all other respects + regarding verbatim copying of that document. + + + + + + Aggregation with independent works + + A compilation of the Document or its derivatives with + other separate and independent documents or works, in or on a + volume of a storage or distribution medium, is called an + aggregate if the copyright resulting from the + compilation is not used to limit the legal rights of the + compilation's users beyond what the individual works permit. + When the Document is included in an aggregate, this License + does not apply to the other works in the aggregate which are + not themselves derivative works of the Document. + + If the Cover Text requirement of section is applicable to these + copies of the Document, then if the Document is less than one + half of the entire aggregate, the Document's may be placed on covers that bracket + the Document within the aggregate, or the electronic + equivalent of covers if the Document is in electronic form. + Otherwise they must appear on printed covers that bracket the + whole aggregate. + + + + + + Translations + + Translation is considered a kind of modification, so you + may distribute translations of the Document under the terms of + section . Replacing + with translations + requires special permission from their copyright holders, but + you may include translations of some or all in addition to the original + versions of these . You + may include a translation of this License, and all the license + notices in the Document, and any Warranty Disclaimers, + provided that you also include the original English version of + this License and the original versions of those notices and + disclaimers. In case of a disagreement between the + translation and the original version of this License or a + notice or disclaimer, the original version will + prevail. + + If a section in the Document is Entitled + Acknowledgements, Dedications, + or History, the requirement (section ) to Preserve its Title + (section ) will + typically require changing the actual title. + + + + + + Termination + + You may not copy, modify, sublicense, or distribute the + Document except as expressly provided for under this License. + Any other attempt to copy, modify, sublicense or distribute + the Document is void, and will automatically terminate your + rights under this License. However, parties who have received + copies, or rights, from you under this License will not have + their licenses terminated so long as such parties remain in + full compliance. + + + + + + Future Revisions of this License + + The Free Software Foundation may publish new, revised + versions of the GNU Free Documentation License from time to + time. Such new versions will be similar in spirit to the + present version, but may differ in detail to address new + problems or concerns. See . + + Each version of the License is given a distinguishing + version number. If the Document specifies that a particular + numbered version of this License or any later + version applies to it, you have the option of + following the terms and conditions either of that specified + version or of any later version that has been published (not + as a draft) by the Free Software Foundation. If the Document + does not specify a version number of this License, you may + choose any version ever published (not as a draft) by the Free + Software Foundation. + + + + + + How to use this License for your documents + + To use this License in a document you have written, + include a copy of the License in the document and put the + following copyright and license notices just after the title + page: + + + Copyright (C) YEAR YOUR NAME. + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation License, + Version 1.2 or any later version published by the Free Software + Foundation; with no Invariant Sections, no Front-Cover Texts, and + no Back-Cover Texts. A copy of the license is included in the + section entitled GNU Free Documentation License. + + + If you have , + Front-Cover Texts and Back-Cover Texts, replace the + with...Texts. line with this: + + + with the Invariant Sections being LIST THEIR TITLES, with the + Front-Cover Texts being LIST, and with the Back-Cover Texts being + LIST. + + + If you have + without , or some other + combination of the three, merge those two alternatives to suit + the situation. + + If your document contains nontrivial examples of program + code, we recommend releasing these examples in parallel under + your choice of free software license, such as the GNU General + Public License, to permit their use in free software. + + + + diff --git a/Manuals/Repository/repository-parts/Licenses/gpl.docbook b/Manuals/Repository/repository-parts/Licenses/gpl.docbook new file mode 100644 index 0000000..3ddcafc --- /dev/null +++ b/Manuals/Repository/repository-parts/Licenses/gpl.docbook @@ -0,0 +1,485 @@ + + + GNU General Public License + + Version 2, June 1991 + + Copyright © 1989, 1991 Free Software Foundation, Inc. + 675 Mass Ave, Cambridge, MA 02139, USA + + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + + + Preamble + + The licenses for most software are designed to take away + your freedom to share and change it. By contrast, the GNU General + Public License is intended to guarantee your freedom to share and + change free software–to make sure the software is free for + all its users. This General Public License applies to most of the + Free Software Foundation's software and to any other program whose + authors commit to using it. (Some other Free Software Foundation + software is covered by the GNU Library General Public License + instead.) You can apply it to your programs, too. + + When we speak of free software, we are referring to freedom, + not price. Our General Public Licenses are designed to make sure + that you have the freedom to distribute copies of free software + (and charge for this service if you wish), that you receive source + code or can get it if you want it, that you can change the + software or use pieces of it in new free programs; and that you + know you can do these things. + + To protect your rights, we need to make restrictions that + forbid anyone to deny you these rights or to ask you to surrender + the rights. These restrictions translate to certain + responsibilities for you if you distribute copies of the software, + or if you modify it. + + For example, if you distribute copies of such a program, + whether gratis or for a fee, 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 show them these terms so + they know their rights. + + We protect your rights with two steps: + + + + copyright the software, and + + + offer you this license which gives you legal + permission to copy, distribute and/or modify the + software. + + + + + Also, for each author's protection and ours, we want to make + certain that everyone understands that there is no warranty for + this free software. If the software is modified by someone else + and passed on, we want its recipients to know that what they have + is not the original, so that any problems introduced by others + will not reflect on the original authors' reputations. + + Finally, any free program is threatened constantly by + software patents. We wish to avoid the danger that redistributors + of a free program will individually obtain patent licenses, in + effect making the program proprietary. To prevent this, we have + made it clear that any patent must be licensed for everyone's free + use or not licensed at all. + + The precise terms and conditions for copying, distribution + and modification follow. + + + + + + Terms and Conditions for Copying, Distribution and Modification + + + + Section 1 + + You may copy and distribute verbatim copies of the + Program's source code as you receive it, in any medium, + provided that you conspicuously and appropriately publish on + each copy an appropriate copyright notice and disclaimer of + warranty; keep intact all the notices that refer to this + License and to the absence of any warranty; and give any other + recipients of the Program a copy of this License along with + the Program. + + You may charge a fee for the physical act of + transferring a copy, and you may at your option offer warranty + protection in exchange for a fee. + + + + + + Section 2 + + You may modify your copy or copies of the Program or + any portion of it, thus forming a work based on the + Program, and copy and distribute such modifications or + work under the terms of above, provided that you also meet all of these + conditions: + + + + You must cause the modified files to carry prominent + notices stating that you changed the files and the date of + any change. + + + You must cause any work that you distribute or + publish, that in whole or in part contains or is derived + from the Program or any part thereof, to be licensed as a + whole at no charge to all third parties under the terms of + this License. + + + If the modified program normally reads commands + interactively when run, you must cause it, when started + running for such interactive use in the most ordinary way, + to print or display an announcement including an + appropriate copyright notice and a notice that there is no + warranty (or else, saying that you provide a warranty) and + that users may redistribute the program under these + conditions, and telling the user how to view a copy of + this License. + + + Exception + + If the Program itself is interactive but does not + normally print such an announcement, your work based + on the Program is not required to print an + announcement. + + + + + + + These requirements apply to the modified work as a whole. + If identifiable sections of that work are not derived from the + Program, and can be reasonably considered independent and separate + works in themselves, then this License, and its terms, do not + apply to those sections when you distribute them as separate + works. But when you distribute the same sections as part of a + whole which is a work based on the Program, the distribution of + the whole must be on the terms of this License, whose permissions + for other licensees extend to the entire whole, and thus to each + and every part regardless of who wrote it. + + Thus, it is not the intent of this section to claim rights + or contest your rights to work written entirely by you; rather, + the intent is to exercise the right to control the distribution of + derivative or collective works based on the Program. + + In addition, mere aggregation of another work not based on + the Program with the Program (or with a work based on the Program) + on a volume of a storage or distribution medium does not bring the + other work under the scope of this License. + + + + + + Section 3 + + You may copy and distribute the Program (or a work + based on it, under ) in + object code or executable form under the terms of and above provided that you also + do one of the following: + + + + + Accompany it with the complete corresponding + machine-readable source code, which must be distributed + under the terms of and + above on a medium + customarily used for software interchange; or, + + + + + Accompany it with a written offer, valid for at + least three years, to give any third party, for a charge + no more than your cost of physically performing source + distribution, a complete machine-readable copy of the + corresponding source code, to be distributed under the + terms of and above on a medium + customarily used for software interchange; or, + + Accompany it with the information you received as + to the offer to distribute corresponding source code. + (This alternative is allowed only for noncommercial + distribution and only if you received the program in + object code or executable form with such an offer, in + accord with Subsection b above.) + + + + + + The source code for a work means the preferred form of the + work for making modifications to it. For an executable work, + complete source code means all the source code for all modules it + contains, plus any associated interface definition files, plus the + scripts used to control compilation and installation of the + executable. However, as a special exception, the source code + distributed need not include anything that is normally distributed + (in either source or binary form) with the major components + (compiler, kernel, and so on) of the operating system on which the + executable runs, unless that component itself accompanies the + executable. + + If distribution of executable or object code is made by + offering access to copy from a designated place, then offering + equivalent access to copy the source code from the same place + counts as distribution of the source code, even though third + parties are not compelled to copy the source along with the object + code. + + + + + + Section 4 + + You may not copy, modify, sublicense, or distribute the + Program except as expressly provided under this License. Any + attempt otherwise to copy, modify, sublicense or distribute the + Program is void, and will automatically terminate your rights + under this License. However, parties who have received copies, or + rights, from you under this License will not have their licenses + terminated so long as such parties remain in full + compliance. + + + + + + Section 5 + + You are not required to accept this License, since you have + not signed it. However, nothing else grants you permission to + modify or distribute the Program or its derivative works. These + actions are prohibited by law if you do not accept this License. + Therefore, by modifying or distributing the Program (or any work + based on the Program), you indicate your acceptance of this + License to do so, and all its terms and conditions for copying, + distributing or modifying the Program or works based on it. + + + + + + Section 6 + + Each time you redistribute the Program (or any work based on + the Program), the recipient automatically receives a license from + the original licensor to copy, distribute or modify the Program + subject to these terms and conditions. You may not impose any + further restrictions on the recipients' exercise of the rights + granted herein. You are not responsible for enforcing compliance + by third parties to this License. + + + + + + Section 7 + + If, as a consequence of a court judgment or allegation of + patent infringement or for any other reason (not limited to patent + issues), conditions are imposed on you (whether by court order, + agreement or otherwise) that contradict the conditions of this + License, they do not excuse you from the conditions of this + License. If you cannot distribute so as to satisfy simultaneously + your obligations under this License and any other pertinent + obligations, then as a consequence you may not distribute the + Program at all. For example, if a patent license would not permit + royalty-free redistribution of the Program by all those who + receive copies directly or indirectly through you, then the only + way you could satisfy both it and this License would be to refrain + entirely from distribution of the Program. + + If any portion of this section is held invalid or + unenforceable under any particular circumstance, the balance of + the section is intended to apply and the section as a whole is + intended to apply in other circumstances. + + It is not the purpose of this section to induce you to + infringe any patents or other property right claims or to contest + validity of any such claims; this section has the sole purpose of + protecting the integrity of the free software distribution system, + which is implemented by public license practices. Many people + have made generous contributions to the wide range of software + distributed through that system in reliance on consistent + application of that system; it is up to the author/donor to decide + if he or she is willing to distribute software through any other + system and a licensee cannot impose that choice. + + This section is intended to make thoroughly clear what is + believed to be a consequence of the rest of this License. + + + + + + Section 8 + + If the distribution and/or use of the Program is restricted + in certain countries either by patents or by copyrighted + interfaces, the original copyright holder who places the Program + under this License may add an explicit geographical distribution + limitation excluding those countries, so that distribution is + permitted only in or among countries not thus excluded. In such + case, this License incorporates the limitation as if written in + the body of this License. + + + + + + Section 9 + + The Free Software Foundation may publish revised and/or new + versions of the General Public License from time to time. Such + new versions will be similar in spirit to the present version, but + may differ in detail to address new problems or concerns. + + Each version is given a distinguishing version number. If + the Program specifies a version number of this License which + applies to it and any later version, you have the + option of following the terms and conditions either of that + version or of any later version published by the Free Software + Foundation. If the Program does not specify a version number of + this License, you may choose any version ever published by the + Free Software Foundation. + + + + + + Section 10 + + If you wish to incorporate parts of the Program into other + free programs whose distribution conditions are different, write + to the author to ask for permission. For software which is + copyrighted by the Free Software Foundation, write to the Free + Software Foundation; we sometimes make exceptions for this. Our + decision will be guided by the two goals of preserving the free + status of all derivatives of our free software and of promoting + the sharing and reuse of software generally. + + + + + + NO WARRANTY + Section 11 + + BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO + WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE + LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT + HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM AS IS WITHOUT + WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT + NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND + FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE + QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE + PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY + SERVICING, REPAIR OR CORRECTION. + + + + + + Section 12 + + IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO + IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY + MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE + LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, + INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR + INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF + DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU + OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY + OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN + ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. + + End of Terms and Conditions. + + + + + + + + How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of + the greatest possible use to the public, the best way to + achieve this is to make it free software which everyone can + redistribute and change under these terms. + + To do so, attach the following notices to the program. + It is safest to attach them to the start of each source file + to most effectively convey the exclusion of warranty; and each + file should have at least the copyright line + and a pointer to where the full notice is found. + + + <one line to give the program's name and a brief idea of what it does.> + Copyright (C) 19yy <name of author> + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + + + Also add information on how to contact you by electronic + and paper mail. + + If the program is interactive, make it output a short + notice like this when it starts in an interactive mode: + + + Gnomovision version 69, Copyright (C) 19yy name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + + + The hypothetical commands `show w' and `show c' should + show the appropriate parts of the General Public License. Of + course, the commands you use may be called something other + than `show w' and `show c'; they could even be mouse-clicks or + menu items–whatever suits your program. + + You should also get your employer (if you work as a + programmer) or your school, if any, to sign a copyright + disclaimer for the program, if necessary. Here is a + sample; alter the names: + + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacker. + + <signature of Ty Coon>, 1 April 1989 + Ty Coon, President of Vice + + + This General Public License does not permit + incorporating your program into proprietary programs. If your + program is a subroutine library, you may consider it more + useful to permit linking proprietary applications with the + library. If this is what you want to do, use the GNU Library + General Public License instead of this License. + + + + diff --git a/Manuals/Repository/repository.docbook b/Manuals/Repository/repository.docbook new file mode 100644 index 0000000..b9373cc --- /dev/null +++ b/Manuals/Repository/repository.docbook @@ -0,0 +1,87 @@ + + + + + + + + + + + + + + + + + + + + +]> + + + + + + The CentOS Artwork Repository Manual + + + + Alain + Reguera Delgado + + + + + + 2009 + 2010 + 2011 + The CentOS Artwork SIG + + + + + Permission is granted to copy, distribute and/or modify + this document under the terms of the GNU Free + Documentation License, Version 1.2 or any later version + published by the Free Software Foundation; with no + Invariant Sections, no Front-Cover Texts, and no + Back-Cover Texts. A copy of the license is included in + the section entitled . + + + + Jun, 2011 + + + + This manuals documents relevant information regarding + the deployment, organization, and administration of + CentOS Artwork Repository. + + + + + + + Repository + &intro; + &dir; + + + + Licenses + &licenses-gpl; + &licenses-gfdl; + + +