On Thu, Aug 6, 2015 at 2:59 AM M.-A. Lemburg <m...@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/ >
_______________________________________________ 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
