[core-workflow] the Misc/NEWS problem

[Brett Cannon]

On Thu, Aug 6, 2015 at 2:59 AM M.-A. Lemburg <mal at egenix.com> wrote:

> On 06.08.2015 07:30, Brett Cannon wrote:
> > 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.
> >
> > So how do we solve this? I can remember 3 possible solutions that have
> been
> > proposed previously:
> >
> >    1. A single file per entry
> >    2. A single file per release version of Python
> >    3. Automating it based on commit messages
>
> I had mentioned a fourth one:
>
>      4. Add a NEWS field to the issue tracker and use it's content
>         for the file entry
>
> This is how eGenix does it and it's been working great so far.
> We simply have our issue tracker generate a report and use
> this as basis for the change log when cutting a release.
>

It also takes care of categorization since we can just grab that from the
Components field.


>
> The advantage over checkin messages is that you are not stuck
> if you have multiple checkins for a single issue which should
> only have a single entry in the change log.
>
> Without using the issue tracker, this is similar to approach
> #2 you mentioned above, but with only creating that file
> once during the release process instead of patching it up with
> every single checkin.
>

The only drawback I see to this is it will require an issue for every
change that should go into the changelog. Now I actually think that's a
good thing, but I can see some pushback from python-dev by those who don't
want the hassle. But I would argue that any change significant enough to
warrant an entry in the changelog warrants an issue to track it.

-Brett


>
> > 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.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source  (#1, Aug 06 2015)
> >>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
> >>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
> >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
> ________________________________________________________________________
>
> ::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::
>
>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>            Registered at Amtsgericht Duesseldorf: HRB 46611
>                http://www.egenix.com/company/contact/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150806/5d6d2a96/attachment.html>