Mercurial > hg > octave-nkf > gnulib-hg
changeset 17454:9b8de09b2e2e
autoupdate
author | Karl Berry <karl@freefriends.org> |
---|---|
date | Fri, 19 Jul 2013 15:08:53 -0700 |
parents | d6a1c46258ab |
children | c8b7822c1226 |
files | doc/maintain.texi doc/standards.texi |
diffstat | 2 files changed, 24 insertions(+), 38 deletions(-) [+] |
line wrap: on
line diff
--- a/doc/maintain.texi +++ b/doc/maintain.texi @@ -5,7 +5,7 @@ @c For double-sided printing, uncomment: @c @setchapternewpage odd @c This date is automagically updated when you save this file: -@set lastupdate May 7, 2013 +@set lastupdate July 19, 2013 @c %**end of header @dircategory GNU organization @@ -1523,9 +1523,11 @@ @item In the @samp{My Account Conf} page on @code{savannah}, upload the GPG -key you will use to sign your packages. If you haven't created one -before, you can do so with the command @code{gpg --gen-key} (you can -accept and/or confirm the default answers to its questions). +key (in ASCII-armored format) that you will use to sign your packages. +If you haven't created one before, you can do so with the command +@code{gpg --gen-key} (you can accept and/or confirm the default +answers to its questions). Then, to get the ASCII-armored version, +run @samp{gpg --export --armor @var{your_key_id}}. Optional but recommended: Send your key to a GPG public key server: @code{gpg --keyserver keys.gnupg.net --send-keys @var{keyid}}, where @@ -1545,8 +1547,7 @@ preferred email address, and your Savannah username. @item -An ASCII armored copy of your GPG key, as an attachment. (@samp{gpg ---export -a @var{your_key_id} >mykey.asc} should give you this.) +The ASCII armored copy of your GPG key, as an attachment. @item A list of names and preferred email addresses of other individuals you @@ -2294,7 +2295,7 @@ Please don't host discussions about your package in a service that requires nonfree software. For instance, Google+ ``communities'' -require running a nonfree Javascript program to post a message, so +require running a nonfree JavaScript program to post a message, so they can't be used in the Free World. To host discussions there would be excluding people who live by free software principles. @@ -2554,6 +2555,14 @@ We don't recommend any specific payment service. However, GNU developers should not use a service that requires them to sign a proprietary software license, such as Google's payment service. +Please also avoid sites that requires users to run nonfree software in +order to donate. (This includes JavaScript software, so try it with +LibreJS or with JavaScript disabled.) + +In the text you post on the site, please pay attention to the +terminological issues we care about (@pxref{Terminology}). + +We have no objections to using Bitcoin to receive donations. The FSF can collect donations for a limited number of projects; if you want to propose that for your project, write to
--- a/doc/standards.texi +++ b/doc/standards.texi @@ -3,7 +3,7 @@ @setfilename standards.info @settitle GNU Coding Standards @c This date is automagically updated when you save this file: -@set lastupdate April 27, 2013 +@set lastupdate July 19, 2013 @c %**end of header @dircategory GNU organization @@ -291,34 +291,11 @@ @cindex programming languages When you want to use a language that gets compiled and runs at high -speed, the best language to use is C. Using another language is like -using a non-standard feature: it will cause trouble for users. Even if -GCC supports the other language, users may find it inconvenient to have -to install the compiler for that other language in order to build your -program. For example, if you write your program in C++, people will -have to install the GNU C++ compiler in order to compile your program. - -C has one other advantage over C++ and other compiled languages: more -people know C, so more people will find it easy to read and modify the -program if it is written in C. - -So in general it is much better to use C, rather than the -comparable alternatives. - -But there are two exceptions to that conclusion: - -@itemize @bullet -@item -It is no problem to use another language to write a tool specifically -intended for use with that language. That is because the only people -who want to build the tool will be those who have installed the other -language anyway. - -@item -If an application is of interest only to a narrow part of the community, -then the question of which language it is written in has less effect on -other people, so you may as well please yourself. -@end itemize +speed, the best language to use is C. C++ is ok too, but please don't +make heavy use of templates. Other languages commonly used in the +free software community, such as Java, Python and Ruby, are ok too. +Please implement the GNU configure and make interface no matter which +language you use. Many programs are designed to be extensible: they include an interpreter for a language that is higher level than C. Often much of the program @@ -333,8 +310,8 @@ Guile also includes bindings for GTK+/GNOME, making it practical to write modern GUI functionality within Guile. We don't reject programs written in other ``scripting languages'' such as Perl and Python, but -using Guile is very important for the overall consistency of the GNU -system. +using Guile is the path that will lead to overall consistency of the +GNU system. @node Compatibility