svn commit: r51933 - head/en_US.ISO8859-1/articles/committers-guide

Eitan Adler <[email protected]>
Newsgroups gmane.os.freebsd.devel.cvs.doc
Message-ID <[email protected]>
Author: eadler
Date: Sat Jun 30 05:56:32 2018
New Revision: 51933
URL: https://svnweb.freebsd.org/changeset/doc/51933

Log:
  Committers guide: wordsmith the section on maintainers
  
  - remove an aside about reading the mailing list. This is taken care of
    by the later sentence about reading revision history
  - use a slightly stronger admonition ("important" instead of "note") for
    the comments about not sending mail directly to the maintainer.
  - Refer explicitly to the 'MAINTAINERS' file at the root of the tree
  - Use the language of "asking for a review" instead of "sending the
    change to them" which, again, encourages a more public interaction.
  - Remove the weasel language "it may help" and just encourage people to
    scan the history

Modified:
  head/en_US.ISO8859-1/articles/committers-guide/article.xml

Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml
==============================================================================
--- head/en_US.ISO8859-1/articles/committers-guide/article.xml	Sat Jun 30 05:33:32 2018	(r51932)
+++ head/en_US.ISO8859-1/articles/committers-guide/article.xml	Sat Jun 30 05:56:32 2018	(r51933)
@@ -2674,18 +2674,17 @@ Relnotes:           yes</programlisting>
       probably little need to check with other committers before
       jumping in with a commit.  Working on a bug in an area of the
       system which is clearly orphaned (and there are a few such
-      areas, to our shame), the same applies.  Trying to modify
-      something which is clearly being actively maintained by someone
-      else (and it is only by watching the
-      <literal><replaceable>repository</replaceable>-committers</literal>
-      mailing list that a developer can really get a feel for just
-      what is and is not) then consider sending the change to them
-      instead, just as a developer would have before becoming a
+      areas, to our shame), the same applies.  When modifying
+      parts of the system which are maintained, formally, or
+      informally, consider asking for review just as a developer
+      would have before becoming a
       committer.  For ports, contact the listed
       <varname>MAINTAINER</varname> in the
-      <filename>Makefile</filename>.  For other parts of the
-      repository, if it is not clear who the active maintainer is, it
-      may help to scan the revision history to see who has committed
+      <filename>Makefile</filename>.</para>
+
+    <para>To determine if an area of the tree is maintained, check the
+      MAINTAINERS file at the root of the tree. If nobody is listed,
+      scan the revision history to see who has committed
       changes in the past.  An example script that lists each person
       who has committed to a given file along with the number of
       commits each person has made can be found at on
@@ -2694,11 +2693,11 @@ Relnotes:           yes</programlisting>
       unanswered or the committer otherwise indicates a lack of
       interest in the area affected, go ahead and commit it.</para>
 
-    <note>
+    <important>
       <para>Avoid sending private emails to maintainers.  Other people
 	might be interested in the conversation, not just the final
 	output.</para>
-    </note>
+    </important>
 
     <para>If there is any doubt about a commit for any reason at all,
       have it reviewed before
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.