<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 8/5/15 10:43 PM, Zachary Ware wrote:<br>
    </div>
    <blockquote
cite="mid:CAKJDb-Pa6rCDuafP6KzYzYf8SMiS4rU2RhN-raBk6nbZ=REfVg@mail.gmail.com"
      type="cite">On Thursday, August 6, 2015, Brett Cannon <<a
        moz-do-not-send="true" href="mailto:bcannon@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:bcannon@gmail.com">bcannon@gmail.com</a></a>>
      wrote:<br>
      <blockquote class="gmail_quote" style="margin:0 0 0
        .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <div dir="ltr">If we ever want to have a nice workflow where we
          can automate as much as possible, we need to figure out a way
          deal with our most common merge conflict: Misc/NEWS. Thanks to
          shifts in the format between different minor versions the file
          is pretty much guaranteed to have a conflict when doing a
          merge up a version.
          <div><br>
          </div>
          <div>So how do we solve this? I can remember 3 possible
            solutions that have been proposed previously:</div>
          <div>
            <ol>
              <li>A single file per entry</li>
              <li>A single file per release version of Python</li>
              <li>Automating it based on commit messages</li>
            </ol>
            <div>I personally prefer #3 as I hate repeating myself since
              I just copy and paste the first line(s) of my commits to
              Misc/NEWS as it is anyway (basically up to the first pair
              of newlines). We would need a way to signal that the
              commit message contains nothing useful for the
              to-be-generated NEWS file when it's simply a fix for a
              previous commit (probably some marker that is somewhat
              inconspicuous like a dash on its own line or something).
              In terms of the section of the NEWS file that a commit
              belongs, that can once again be a marker or honestly
              something we drop or infer based on what files were edited
              in the commit.</div>
          </div>
        </div>
      </blockquote>
      <div><span
          style="background-color:rgba(255,255,255,0);font-size:small"><br>
        </span></div>
      <div><span
          style="background-color:rgba(255,255,255,0);font-size:small">See
          also </span><a moz-do-not-send="true"
          href="http://bugs.python.org/issue18967" target="_blank"
          style="-webkit-tap-highlight-color: rgba(26, 26, 26,
          0.301961);">http://bugs.python.org/issue18967</a><span
          style="background-color:rgba(255,255,255,0);font-size:small">,
          which even has a couple of sample implementations.</span><br>
      </div>
    </blockquote>
    <br>
    Thanks Zach. This issue has interesting reading.<br>
    <br>
    The crux of that issue's discussion balances: a) the desire for
    automation of generating the NEWS file with b) the desire to provide
    useful information to the users. <br>
    <br>
    Something similar to Firefox's approach <a
      href="https://www.mozilla.org/en-US/firefox/39.0/releasenotes/"><a class="moz-txt-link-freetext" href="https://www.mozilla.org/en-US/firefox/39.0/releasenotes/">https://www.mozilla.org/en-US/firefox/39.0/releasenotes/</a></a>
    may be reasonable. Putting implementation and display aside for the
    moment, the Firefox approach gives: 1) user friendly info on a
    subset of news/release items and 2) a link to a comprehensive list
    of changes. <br>
    <br>
    Even if one wanted a text file similar to the current NEWS file, one
    could still take the Firefox approach. Put user friendly highlights
    for a subset of key issues (which would require some manual
    intervention though much less than now) and follow that with a
    comprehensive list of changes using one of the proposed options
    based on commit messages.<br>
    <br>
    Carol<br>
    <br>
    <blockquote
cite="mid:CAKJDb-Pa6rCDuafP6KzYzYf8SMiS4rU2RhN-raBk6nbZ=REfVg@mail.gmail.com"
      type="cite">
      <div><font size="2"><span
            style="background-color:rgba(255,255,255,0)"><br>
          </span></font></div>
      <div><font size="2"><span
            style="background-color:rgba(255,255,255,0)">--</span></font></div>
      <div><font size="2"><span
            style="background-color:rgba(255,255,255,0)">Zach</span></font></div>
      <div><font size="2"><span
            style="background-color:rgba(255,255,255,0)">(On an iPad)</span></font></div>
      <br>
      <br>
      -- <br>
      Sent from Gmail Mobile<br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
core-workflow mailing list
<a class="moz-txt-link-abbreviated" href="mailto:core-workflow@python.org">core-workflow@python.org</a>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/core-workflow">https://mail.python.org/mailman/listinfo/core-workflow</a>
This list is governed by the PSF Code of Conduct: <a class="moz-txt-link-freetext" href="https://www.python.org/psf/codeofconduct">https://www.python.org/psf/codeofconduct</a></pre>
    </blockquote>
    <br>
    <br>
    <div class="moz-signature">-- <br>
      <font face="arial">
        <b>Carol Willing</b> <br>
        Developer | Willing Consulting <br>
        <a class="moz-txt-link-freetext" href="https://willingconsulting.com">https://willingconsulting.com</a> <br>
      </font></div>
  </body>
</html>