LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

fix minor typos in Software-Proj-Mgmt-HOWTO.sgml

This commit is contained in:
Jason Leschnik 2016-10-24 21:40:19 +11:00
parent 1ea72425b3
commit 170a21fc56
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
LDP/howto/docbook/Software-Proj-Mgmt-HOWTO.sgml
View File

@ -700,7 +700,7 @@
Source Definition.</ulink> Examples of free licenses given by the
<acronym>DFSG</acronym> are the <acronym>GPL</acronym>, the
<acronym>BSD</acronym>, and the Artistic License. As ESR mentions
in his his HOWTO<xref linkend="esrhowto">, don't write your own
in his HOWTO<xref linkend="esrhowto">, don't write your own
license if at all possible. The three licenses I mention all have
long interpretive traditions. They are also definitely free
software (and can therefore be distributed as part of Debian and
@ -1320,7 +1320,7 @@ pages for more information and options.
<para>Unless your software is particular to a non-English
language (a Japanese language editor for example), please
distribute it with English language documentation. If you don't
speak English or not not confident in your skills, ask a friend
speak English or not confident in your skills, ask a friend
for help. Like it or not, fair or unfair, <emphasis>English is
the language of free software</emphasis>. However, this does not
mean you should limit your documentation to only English. If you
@ -1402,7 +1402,7 @@ pages for more information and options.
possible. Remember: <emphasis>While these binaries packages are
nice, getting the source packaged and released should always be
your priority. Your users or fellow developers can and will do
the the binary packages for you.</emphasis>
the binary packages for you.</emphasis>
</para>
</sect3>
@ -1794,7 +1794,7 @@ pages for more information and options.
The answers to these questions are never straightforward and its
very possible (and even likely) that the person who submitted the
patch may feel differently about the answer to these questions
than you do. However, if you feel that that the answer to either
than you do. However, if you feel that the answer to either
of those questions is <quote>no,</quote> it is your responsibility
to reject the change. If you fail to do this, the project will
become unwieldy and unmaintainable and many ultimately fail.
@ -2877,7 +2877,7 @@ pages for more information and options.
Although I have to honestly say that I am not the ESR fan that
I used to be, this book proved invaluable in getting me where I
am today. The essay that gives the book its title does a good
job of sketching the free software process and does an an
job of sketching the free software process and does an
amazing job of making an argument for free software/open source
development as a road to better software. The rest of the book
has other of ESR's articles, which for the most part are posted
@ -2943,7 +2943,7 @@ pages for more information and options.
this HOWTO and I was very impressed. It's written by a graduate
student in management and I think it succeeds at evaluating the
Linux project as an example of a new paradigm in management--one
that <emphasis>you</emphasis> will be be placing yourself at the
that <emphasis>you</emphasis> will be placing yourself at the
center of in your capacity as maintainer of a free software
project.</para>