[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] [taler-deployment] branch master updated: doc no longer bel
|
From: |
gnunet |
|
Subject: |
[GNUnet-SVN] [taler-deployment] branch master updated: doc no longer belongs here |
|
Date: |
Thu, 29 Aug 2019 11:56:49 +0200 |
This is an automated email from the git hooks/post-receive script.
dold pushed a commit to branch master
in repository deployment.
The following commit(s) were added to refs/heads/master by this push:
new 8244dc8 doc no longer belongs here
8244dc8 is described below
commit 8244dc8bc4244ca3b9dcce2ef77cee3837c0a401
Author: Florian Dold <address@hidden>
AuthorDate: Thu Aug 29 11:56:46 2019 +0200
doc no longer belongs here
---
doc/Makefile | 13 --
doc/brown-paper.css | 63 ------
doc/docstyle.css | 85 --------
doc/onboarding.texi | 415 --------------------------------------
doc/version.texi | 4 -
taler-docbuild/update_doc_bank.sh | 3 -
6 files changed, 583 deletions(-)
diff --git a/doc/Makefile b/doc/Makefile
deleted file mode 100644
index 0c9f835..0000000
--- a/doc/Makefile
+++ /dev/null
@@ -1,13 +0,0 @@
-all: onboarding.pdf onboarding.html
-
-onboarding.pdf: onboarding.texi
- texi2pdf onboarding.texi
-
-onboarding.html: onboarding.texi
- texi2any --html --no-split --css-ref=docstyle.css
--css-ref=brown-paper.css onboarding.texi
-
-clean:
- rm -f onboarding.html onboarding.pdf
-
-info_TEXINFOS = onboarding.texi
-manual_TEXINFOS = version.texi
diff --git a/doc/brown-paper.css b/doc/brown-paper.css
deleted file mode 100644
index 65e2e79..0000000
--- a/doc/brown-paper.css
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
-
-Brown Paper style from goldblog.com.ua (c) Zaripov Yura <address@hidden>
-
-*/
-
-.hljs {
- display: block;
- overflow-x: auto;
- padding: 0.5em;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal {
- color:#005599;
- font-weight:bold;
-}
-
-.hljs,
-.hljs-subst {
- color: #363c69;
-}
-
-.hljs-string,
-.hljs-title,
-.hljs-section,
-.hljs-type,
-.hljs-attribute,
-.hljs-symbol,
-.hljs-bullet,
-.hljs-built_in,
-.hljs-addition,
-.hljs-variable,
-.hljs-template-tag,
-.hljs-template-variable,
-.hljs-link,
-.hljs-name {
- color: #2c009f;
-}
-
-.hljs-comment,
-.hljs-quote,
-.hljs-meta,
-.hljs-deletion {
- color: #802022;
-}
-
-.hljs-keyword,
-.hljs-selector-tag,
-.hljs-literal,
-.hljs-doctag,
-.hljs-title,
-.hljs-section,
-.hljs-type,
-.hljs-name,
-.hljs-strong {
- font-weight: bold;
-}
-
-.hljs-emphasis {
- font-style: italic;
-}
diff --git a/doc/docstyle.css b/doc/docstyle.css
deleted file mode 100644
index 1a3a88b..0000000
--- a/doc/docstyle.css
+++ /dev/null
@@ -1,85 +0,0 @@
-html, body {
- font-size: 1em;
- text-align: left;
- text-decoration: none;
-}
-html { background-color: #e7e7e7; }
-
-body {
- max-width: 74.92em;
- margin: 0 auto;
- padding: .5em 1em 1em 1em;
- background-color: white;
- border: .1em solid #c0c0c0;
-}
-
-h1, h2, h3, h4 { color: #333; }
-h5, h6, dt { color: #222; }
-
-
-a h3 {
- color: #005090;
-}
-
-a[href] { color: #005090; }
-a[href]:visited { color: #100070; }
-a[href]:active, a[href]:hover {
- color: #100070;
- text-decoration: none;
-}
-
-.linkrow {
- margin: 3em 0;
-}
-
-.linkrow {
- text-align: center;
-}
-
-div.example { padding: .8em 1.2em .4em; }
-pre.example { padding: .8em 1.2em; }
-div.example, pre.example {
- margin: 1em 0 1em 3% ;
- -webkit-border-radius: .3em;
- -moz-border-radius: .3em;
- border-radius: .3em;
- border: 1px solid #d4cbb6;
- background-color: #f2efe4;
-}
-div.example > pre.example {
- padding: 0 0 .4em;
- margin: 0;
- border: none;
-}
-
-pre.smallexample {
- margin: 1em 0 1em 3% ;
- -webkit-border-radius: .3em;
- -moz-border-radius: .3em;
- border-radius: .3em;
- border: 1px solid #d4cbb6;
- background-color: #f2efe4;
-}
-
-
-/* This makes the very long tables of contents in Gnulib and other
- manuals easier to read. */
-.contents ul, .shortcontents ul { font-weight: bold; }
-.contents ul ul, .shortcontents ul ul { font-weight: normal; }
-.contents ul { list-style: none; }
-
-/* For colored navigation bars (Emacs manual): make the bar extend
- across the whole width of the page and give it a decent height. */
-.header, .node { margin: 0 -1em; padding: 0 1em; }
-.header p, .node p { line-height: 2em; }
-
-/* For navigation links */
-.node a, .header a { display: inline-block; line-height: 2em; }
-.node a:hover, .header a:hover { background: #f2efe4; }
-
-table.cartouche {
- border-collapse: collapse;
- border-color: darkred;
- border-style: solid;
- border-width: 3px;
-}
diff --git a/doc/onboarding.texi b/doc/onboarding.texi
deleted file mode 100644
index 367ff1e..0000000
--- a/doc/onboarding.texi
+++ /dev/null
@@ -1,415 +0,0 @@
-\input texinfo @c -*-texinfo-*-
-@c %**start of header
-@setfilename onboarding.info
-@include version.texi
-@settitle Notes for taler.net admins and developers @value{VERSION}
-
-@c Define a new index for options.
-@defcodeindex op
-@c Combine everything into one index (arbitrarily chosen to be the
-@c concept index).
-@syncodeindex op cp
-@c %**end of header
-
-@copying
-Howtos for taler.net admins and developers (version @value{VERSION},
@value{UPDATED}),
-Copyright @copyright{} 2017 INRIA
-
-@quotation
-Permission is granted to copy, distribute and/or modify this document
-under the terms of the GNU Free Documentation License, Version 1.3 or
-any later version published by the Free Software Foundation; with no
-Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
-Texts. A copy of the license is included in the section entitled
-``GNU Free Documentation License''.
-@end quotation
-@end copying
-@c If your manual is published on paper by the FSF, it should include
-@c The standard FSF Front-Cover and Back-Cover Texts, as given in
-@c maintain.texi.
-@c
-@c Titlepage
-@c
-@titlepage
-@title Notes for taler.net admins and developers
-@subtitle Version @value{VERSION}
-@subtitle @value{UPDATED}
-@author Marcello Stanisci (@email{marcello@@taler.net})
-@page
-@vskip 0pt plus 1filll
-@insertcopying
-@end titlepage
-
-@c @summarycontents
-@contents
-
-@ifnottex
-@node Top
-@top Notes for taler.net admins and developers
-@insertcopying
-@end ifnottex
-
-@menu
-* Taler installation:: How to install all Taler components
-* Testing components:: How to make and run tests
-* Releases:: Releases patterns
-* Code:: Where to find Taler code
-* Bugtracking:: How to track Taler bugs
-* Continuous integration:: How CI is currently performed
-* Code coverage:: Where to find coverage reports
-@end menu
-
-@node Taler installation
-@chapter Taler installation
-
-@section Users serving Taler.
-
-On Gv.Taler.Net, there are four users that are set up to serve Taler
-on the internet:
-
-@itemize
-@item @code{taler-test}: serves @code{*.test.taler.net} and gets automatically
built by Buildbot.
-@item @code{taler-internal}: serves @code{*.int.taler.net}, and does
@emph{NOT} get automatically built.
-@end itemize
-
-The following two users are @emph{NEVER} automatically built, and
-they both serve @code{*.demo.taler.net}. At any given time, only
-one is active and serves the HTTP requests from the outside; the other
-one can so be compiled without any downtime. If the compilation succeeds,
-the inactive user can be switched to become active (see next section),
-and viceversa.
-
-@itemize
-@item @code{demo-blue}
-@item @code{demo-green}
-@end itemize
-
-@section Compile and switch color.
-
-If the setup is already bootstrapped, then it should only be needed
-to login as 'demo-X' (with X being the inactive color); and then:
-@example
-$ source activate
-$ taler-deployment-build
-@end example
-
-and then switch the color by logging in as the @emph{demo} user,
-and switch the color with the following command:
-
-@example
-$ taler-deployment-switch-demo-X
-@end example
-
-@section Full bootstrap.
-
-In order to bootstrap a Taler installation under a empty home
-directory, do:
-
-@example
-$ cd $HOME
-$ git clone git://git.taler.net/deployment
-@end example
-
-Then run the bootstrap script that will download all the repositories.
-
-@example
-$ ./deployment/bootstrap-taler <env>
-
-# <env> will make all the services serve *.<env>.taler.net
-#
-# Currently at Gv.Taler.Net, only 'demo' / 'test' / 'int' have
-# DNS and certs configured.
-@end example
-
-If successful, then activate the new environment with:
-
-@example
-source activate
-@end example
-
-Compile and install all the components.
-@example
-$ taler-deployment-build
-@end example
-
-Create the global configuration file.
-@example
-$ taler-deployment-config-generate
-@end example
-
-Create (only) the folders where all the data needed by
-Taler will be copied into (keys / JSONs with wire details / ..)
-@example
-$ taler-deployment-hier
-@end example
-
-Create all the keys.
-@example
-$ taler-deployment-keyup
-@end example
-
-Sign the @code{/wire} response for the exchange.
-@example
-$ taler-deployment-sign
-@end example
-
-@cartouche
-@quotation Note
-If the DB schema of merchant/exchange/auditor changed, at this
-point it MIGHT be necessary to reset all the tables. To this
-regard, consider running one of the following commands:
-
-@example
-# To reset the merchant DB.
-$ taler-merchant-dbinit -r
-
-# To reset the exchange DB.
-$ taler-exchange-dbinit -r
-
-# To reset the exchange DB.
-$ taler-auditor-dbinit -r
-@end example
-
-@end quotation
-@end cartouche
-
-If all the steps succeeded, then it should be possible
-to launch all the services. Give:
-
-@example
-$ taler-deployment-start
-
-# or restart, if you want to kill old processes and
-# start new ones.
-$ taler-deployment-restart
-@end example
-
-Verify that all services are up and running:
-@example
-$ taler-deployment-arm -I
-$ tail logs/<component>-<date>.log
-@end example
-
-@section How to upgrade the code.
-
-Some repositories, especially the ones from the released components,
-have a @emph{stable} branch, that keeps older and more stable code.
-Therefore, upon each release we must rebase those stable branches
-on the master.
-
-The following commands do that:
-
-@example
-$ cd $REPO
-
-$ git pull origin master stable
-$ git checkout stable
-
-# option a: resolve conflicts resulting from hotfixes
-$ git rebase master
-$ ...
-
-# option b: force stable to master
-$ git update-ref refs/heads/stable master
-
-$ git push # possibly with --force
-
-# continue development
-$ git checkout master
-@end example
-
-@node Testing components
-@chapter Testing components
-
-@c CMDs
-@c Traits
-@c Twister setup
-
-This chapter is a VERY ABSTRACT description of how testing
-is implemented in Taler, and in NO WAY wants to substitute
-the reading of the actual source code by the user.
-
-In Taler, a test case is a array of @code{struct TALER_TESTING_Command},
-informally referred to as @code{CMD}, that is iteratively executed by
-the testing interpreter. This latter is transparently initiated
-by the testing library.
-
-However, the developer does not have to defined CMDs manually,
-but rather call the proper constructor provided by the library.
-For example, if a CMD is supposed to test feature @code{x},
-then the library would provide the @code{TALER_TESTING_cmd_x ()}
-constructor for it. Obviously, each constructor has its own
-particular arguments that make sense to test @code{x}, and all
-constructor are thoroughly commented within the source code.
-
-Internally, each CMD has two methods: @code{run ()} and @code{cleanup ()}.
-The former contains the main logic to test feature @code{x},
-whereas the latter cleans the memory up after execution.
-
-In a test life, each CMD needs some internal state, made by
-values it keeps in memory. Often, the test has to @emph{share}
-those values with other CMDs: for example, CMD1 may create some
-key material and CMD2 needs this key material to encrypt data.
-
-The offering of internal values from CMD1 to CMD2 is made
-by @emph{traits}. A trait is a @code{struct TALER_TESTING_Trait},
-and each CMD contains a array of traits, that it offers
-via the public trait interface to other commands. The
-definition and filling of such array happens transparently
-to the test developer.
-
-For example, the following example shows how CMD2 takes
-an amount object offered by CMD1 via the trait interface.
-
-Note: the main interpreter and the most part of CMDs and traits
-are hosted inside the exchange codebase, but nothing prevents
-the developer from implementing new CMDs and traits within
-other codebases.
-
-@example
-/* Withouth loss of generality, let's consider the
- * following logic to exist inside the run() method of CMD1 */
-..
-
-struct TALER_Amount *a;
-/**
- * the second argument (0) points to the first amount object offered,
- * in case multiple are available.
- */
-if (GNUNET_OK != TALER_TESTING_get_trait_amount_obj (cmd2, 0, &a))
- return GNUNET_SYSERR;
-...
-
-use(a); /* 'a' points straight into the internal state of CMD2 */
-@end example
-
-In the Taler realm, there is also the possibility to alter the
-behaviour of supposedly well-behaved components. This is needed
-when, for example, we want the exchange to return some corrupted
-signature in order to check if the merchant backend detects it.
-
-This alteration is accomplished by another service called @emph{twister}.
-The twister acts as a proxy between service A and B, and can be
-programmed to tamper with the data exchanged by A and B.
-
-Please refer to the Twister codebase (under the @code{test} directory)
-in order to see how to configure it.
-
-@node Releases
-@chapter Releases
-
-@section Release Process and Checklists
-
-This document describes the process for releasing a new version of the various
-Taler components to the official GNU mirrors.
-
-The following components are published on the GNU mirrors
-
-@itemize
-@item taler-exchange (exchange.git)
-@item taler-merchant (merchant.git)
-@item talerdonations (donations.git)
-@item talerblog (blog.git)
-@item taler-bank (bank.git)
-@item taler-wallet-webex (wallet-webex.git)
-@end itemize
-
-@section Tagging
-
-Tag releases with an @b{annotated} commit, like
-
-@example
-git tag -a v0.1.0 -m "Official release v0.1.0"
-git push origin v0.1.0
-@end example
-
-@section Database for tests
-
-For tests in the exchange and merchant to run, make sure that
-a database @emph{talercheck} is accessible by @emph{$USER}. Otherwise tests
-involving the database logic are skipped.
-
-@section Exchange, merchant
-
-Set the version in @code{configure.ac}. The commit being tagged
-should be the change of the version.
-
-For the exchange test cases to pass, @code{make install} must be run first.
-Without it, test cases will fail because plugins can't be located.
-
-@example
-./bootstrap
-./configure # add required options for your system
-make dist
-tar -xf taler-$COMPONENT-$VERSION.tar.gz
-cd taler-$COMPONENT-$VERSION
-make install check
-@end example
-
-@section Wallet WebExtension
-
-The version of the wallet is in @emph{manifest.json}. The @code{version_name}
should be
-adjusted, and @emph{version} should be increased independently on every upload
to
-the WebStore.
-
-@example
-./configure
-make dist
-@end example
-
-@c FIXME: selenium test cases
-
-@section Upload to GNU mirrors
-
-See
@emph{https://www.gnu.org/prep/maintain/maintain.html#Automated-FTP-Uploads}
-
-Directive file:
-
-@example
-version: 1.2
-directory: taler
-filename: taler-exchange-0.1.0.tar.gz
-@end example
-
-Upload the files in @b{binary mode} to the ftp servers.
-
-@node Code
-@chapter Code
-Taler code is versioned via Git. For those users without write access,
-all the codebases are found at the following URL:
-
-@example
-git://git.taler.net/<repository>
-@end example
-
-A complete list of all the existing repositories is currently found at
-@code{https://git.taler.net/}. Note: @code{<repository>} must NOT have
-the @code{.git} extension.
-
-@node Bugtracking
-@chapter Bugtracking
-Bug tracking is done with Mantis (https://www.mantisbt.org/). All the
-bugs are then showed and managed at @code{https://bugs.gnunet.org/}, under
-the "Taler" project. A registration on the Web site is needed in order to
-use the bug tracker.
-
-@node Continuous integration
-@chapter Continuous integration
-CI is done with Buildbot (https://buildbot.net/), and builds are triggered
-by the means of Git hooks. The results are published at
@code{https://buildbot.wild.gv.taler.net/}.
-
-In order to avoid downtimes, CI uses a "blue/green" deployment technique.
-In detail, there are two users building code on the system, the "green" and
-the "blue" user; and at any given time, one is running Taler services and
-the other one is either building the code or waiting for that.
-
-There is also the possibility to trigger builds manually, but this is only
-reserved to "admin" users.
-
-@node Code coverage
-@chapter Code coverage
-Code coverage is done with the Gcov / Lcov
(http://ltp.sourceforge.net/coverage/lcov.php)
-combo, and it is run *nightly* (once a day) by a Buildbot worker. The
-coverage results are then published at @code{https://lcov.taler.net/}.
-
-@bye
diff --git a/doc/version.texi b/doc/version.texi
deleted file mode 100644
index 1bd19c2..0000000
--- a/doc/version.texi
+++ /dev/null
@@ -1,4 +0,0 @@
-@set UPDATED 31 May 2017
-@set UPDATED-MONTH May 2017
-@set EDITION 0.2.0
-@set VERSION 0.2.0
diff --git a/taler-docbuild/update_doc_bank.sh
b/taler-docbuild/update_doc_bank.sh
index 5698a13..030736b 100755
--- a/taler-docbuild/update_doc_bank.sh
+++ b/taler-docbuild/update_doc_bank.sh
@@ -12,9 +12,6 @@ fetch () {
cd $HOME/bank
fetch
-./bootstrap
-./configure --enable-only-doc
-make pdf
make html
mkdir -p $HOME/build/bank/manual/pdf
mkdir -p $HOME/build/bank/manual/html
--
To stop receiving notification emails like this one, please contact
address@hidden.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] [taler-deployment] branch master updated: doc no longer belongs here,
gnunet <=