]> Savannah Git Hosting - gnulib.git/commitdiff
autoupdate
authorKarl Berry <karl@freefriends.org>
Wed, 17 Jan 2018 18:09:24 +0000 (10:09 -0800)
committerKarl Berry <karl@freefriends.org>
Wed, 17 Jan 2018 18:09:24 +0000 (10:09 -0800)
doc/standards.texi

index 23273b23ee46eb8ee2a2b12827b1dbf56e3633b4..12a2c717fef8d6015d7c2f50309bb583d4a1bac9 100644 (file)
@@ -28,7 +28,7 @@ The GNU coding standards, last updated @value{lastupdate}.
 
 Copyright @copyright{} 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
-2011, 2012, 2013, 2014, 2015, 2016 Free Software Foundation, Inc.
+2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 Free Software Foundation, Inc.
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -3565,7 +3565,7 @@ It is a good idea to start the change log entry with a description
 of the overall change.  This should be as long as needed to give
 a clear description.
 
-The give a list of names of the entities or definitions that you
+Then give a list of names of the entities or definitions that you
 changed, according to the files they are in, and what was changed
 in each one.  @xref{Style of Change Logs}.
 
@@ -3695,7 +3695,7 @@ There's no technical need to make change log entries for non-software
 files (manuals, help files, media files, etc.).  This is because they
 are not susceptible to bugs that are hard to understand.  To correct
 an error, you need not know the history of the erroneous passage; it
-is enough to compare what the file says with the the actual facts.
+is enough to compare what the file says with the actual facts.
 
 However, you should keep change logs for non-software files when the
 project gets copyright assignments from its contributors, so as to