On Sat, Aug 8, 2015 at 8:25 AM, Pierre-Yves David <pierre-yves.da...@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 > _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
