[core-workflow] the Misc/NEWS problem

Ezio Melotti ezio.melotti at gmail.com
Sat Aug 8 14:05:02 CEST 2015


On Sat, Aug 8, 2015 at 8:25 AM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 08/05/2015 10:30 PM, 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 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.
>
>
> (I'm a bit late to the party here, sorry).
>
> You have another solution (5) having a dedicated merge script for misc/NEWS
> that knows how to parse the format and generate a good merge. It should not
> be too complicated to achieve. I've successfully used such script for
> similarish file in the past.
>

A merge script is already attached to the aforementioned issue: see
http://bugs.python.org/issue18967#msg217079 and
http://bugs.python.org/file35032/newsmerge.py
I think you were the one who convinced and helped me implementing it :)

Best Regards,
Ezio Melotti

> The main issue of (3) is that you will make mistake. Either wrong commit
> message or change flagged as News worthy but later backed out or changed so
> much than the initial message is irrelevant.
>
> (Mercurial will have not problem editing commit message as long as they did
> not made it to the main public repo, however be sure that you will let
> mistake slip through).
>
> --
> Pierre-Yves David
>


More information about the core-workflow mailing list