cvs commit: www/hints submit.html

jeroen at linuxfromscratch.org jeroen at linuxfromscratch.org
Tue Jan 27 16:55:31 PST 2004


jeroen      04/01/27 17:55:31

  Modified:    hints    submit.html
  Log:
  Expand requirements for hint filenames.
  
  Revision  Changes    Path
  1.55      +1 -1      www/hints/submit.html
  
  Index: submit.html
  ===================================================================
  RCS file: /home/cvsroot/www/hints/submit.html,v
  retrieving revision 1.54
  retrieving revision 1.55
  diff -u -r1.54 -r1.55
  --- submit.html	19 Dec 2003 12:37:24 -0000	1.54
  +++ submit.html	28 Jan 2004 00:55:31 -0000	1.55
  @@ -63,7 +63,7 @@
   	<li>A hint should not duplicate documentation that is already available elsewhere on a particular topic, it should complement it. Documentation available elsewhere includes <a href="http://www.tldp.org/">LDP documentation</a>, documentation available from the package website, documentation available by a simple <a href="http://www.google.com">google</a> search. Also, things that are already well documented in the book(s) or at the LDP should not be repeated in the hint unless the hint describes matters in more detail, in a different way, or from a different perspective. So things such as installation of db, freetype, zlib, etc can just be referenced by pointers to the book. </li>
   	<li>Authors who are not interested in maintaining their hints any more should send a message to the hints mailing list specifying that the hint is <a href="adoptahint.html">up for adoption</a>. The author should also notify the hints list if the hint is not relevant anymore.</li>
   	<li>Hints that have been integrated into the book will be retired after a stable version of the book is released.</li>
  -	<li>Keep the file name of the hint short, but descriptive. The extension for the hint should be .txt. The name should be all lowercase.</li>
  +	<li>Keep the file name of the hint short, but descriptive. The extension for the hint should be .txt. The name may be composed of a combination of lowercase letters, numbers, and a few symbols <code>_</code> <code>-</code> <code>+</code>.</li>
   	<li>The hint document is text based. The format for the hints is as explained at the end of this document.</li>
   	<li>Avoid including scripts and patches in the hints. Keep these as separate files to avoid spoiling the beauty of the hint:) Patches should follow the <a href="http://patches.linuxfromscratch.org">patches format</a>. The patches that you submit will be comitted to the patches repository (so be sure to mention the hint in the patch description) under the appropriate package name. The scripts or patches that don't fit into the patches project will be available from the <a href="downloads/attachments">Attachments</a> link in the left menu. If you need to reference any patches in your hint, point to the patches subproject (e.g. http://www.linuxfromscratch.org/patches/<package_name>/<patch_name>). If you need to reference to any attachments, point to the attachments directory (e.g. http://www.linuxfromscratch.org/hints/downloads/attachments/<hint_name>/) Don't worry if the URIs are incorrect, the maintainer will modify the URIs before submitting. Since maintainers are sometimes lazy, you may need to give them a bit of a push/shove to "do the right thing".</li>
   	<li>To submit or update a hint, send an e-mail to the <a href="http://linuxfromscratch.org/mailman/listinfo/hints" title="Archive and subscription information for the hints mailinglist">hint mailing list</a>. From there it will be picked up by the hint maintainer, who will update the hint index and the tarball. To check if your hint has already been included, you can <a href="http://linuxfromscratch.org/mailman/listinfo/hints">subscribe</a> to the hints mailinglist and check for the CVS commit message. Keep the hints list solely for <strong>submitting hints and updates to hints</strong>.</li>
  
  
  



More information about the website mailing list