httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sl...@apache.org
Subject cvs commit: httpd-site/docs/dev patches.html
Date Fri, 18 Jun 2004 19:35:55 GMT
slive       2004/06/18 12:35:55

  Modified:    xdocs/dev patches.xml
               docs/dev patches.html
  Log:
  Add Bill's "what to do if my patch gets ignored" suggestions.
  
  Revision  Changes    Path
  1.9       +20 -5     httpd-site/xdocs/dev/patches.xml
  
  Index: patches.xml
  ===================================================================
  RCS file: /home/cvs/httpd-site/xdocs/dev/patches.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -d -b -u -r1.8 -r1.9
  --- patches.xml	17 Jun 2004 18:15:21 -0000	1.8
  +++ patches.xml	18 Jun 2004 19:35:54 -0000	1.9
  @@ -168,6 +168,12 @@
   
   <ol>
   
  +<li>Be persistent but polite.  Post to the developers list pointing
  +out your patch and why you feel it is important.  Feel free to do this
  +about once a week and continue until you get a response. Just be sure
  +to be polite about it, since the developers are unlikely to respond to
  +rude messages.</li>
  +
   <li>Encourage other Apache users to review and test your patch, and then
   append a note to the bug report with the details.  Developers are much more
   likely to review and commit a patch if they see that it has been widely
  @@ -177,11 +183,20 @@
   style suggestions in the above sections and include any necessary
   documentation changes.</li>
   
  -<li>Be persistent but polite.  Post to the developers list pointing
  -out your patch and why you feel it is important.  Feel free to do this
  -about once a week and continue until you get a response. Just be sure
  -to be polite about it, since the developers are unlikely to respond to
  -rude messages.</li>
  +<li>Review the bugs database for similar errors.  If there are
  +duplicates, close them as duplicates of the initial report (this cross
  +references the two bugs to each other.)  Add an extra note when
  +closing well documented dups if the particular bug report contains
  +useful unique details.  If there is a report that isn't identical, but
  +might be helped by your patch, mark it as 'depends on' the bug report
  +containing your patch.  Finally mark the original incident as 'depends
  +on' your bug report, with patch.</li>
  +
  +<li>Earn "brownie points" by dealing with other bug reports that you
  +can politely and correctly address.  As ugly as this job is -- sort of
  +like the poop crew following a parade -- it leaves the principal
  +committers with time to address the real bugs and their solutions
  +instead of sweeping up the droppings.</li>
   
   </ol>
   </section>
  
  
  
  1.31      +20 -5     httpd-site/docs/dev/patches.html
  
  Index: patches.html
  ===================================================================
  RCS file: /home/cvs/httpd-site/docs/dev/patches.html,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -d -b -u -r1.30 -r1.31
  --- patches.html	17 Jun 2004 18:15:23 -0000	1.30
  +++ patches.html	18 Jun 2004 19:35:55 -0000	1.31
  @@ -234,6 +234,12 @@
   on what you can do to encourage action on your patch:</p>
   <ol>
   
  +<li>Be persistent but polite.  Post to the developers list pointing
  +out your patch and why you feel it is important.  Feel free to do this
  +about once a week and continue until you get a response. Just be sure
  +to be polite about it, since the developers are unlikely to respond to
  +rude messages.</li>
  +
   <li>Encourage other Apache users to review and test your patch, and then
   append a note to the bug report with the details.  Developers are much more
   likely to review and commit a patch if they see that it has been widely
  @@ -243,11 +249,20 @@
   style suggestions in the above sections and include any necessary
   documentation changes.</li>
   
  -<li>Be persistent but polite.  Post to the developers list pointing
  -out your patch and why you feel it is important.  Feel free to do this
  -about once a week and continue until you get a response. Just be sure
  -to be polite about it, since the developers are unlikely to respond to
  -rude messages.</li>
  +<li>Review the bugs database for similar errors.  If there are
  +duplicates, close them as duplicates of the initial report (this cross
  +references the two bugs to each other.)  Add an extra note when
  +closing well documented dups if the particular bug report contains
  +useful unique details.  If there is a report that isn't identical, but
  +might be helped by your patch, mark it as 'depends on' the bug report
  +containing your patch.  Finally mark the original incident as 'depends
  +on' your bug report, with patch.</li>
  +
  +<li>Earn "brownie points" by dealing with other bug reports that you
  +can politely and correctly address.  As ugly as this job is -- sort of
  +like the poop crew following a parade -- it leaves the principal
  +committers with time to address the real bugs and their solutions
  +instead of sweeping up the droppings.</li>
   
   </ol>
     </blockquote>
  
  
  

Mime
View raw message