> On Aug 6, 2015, at 4:06 PM, Brett Cannon <bcan...@gmail.com> wrote: > > > > On Thu, Aug 6, 2015 at 12:46 PM R. David Murray <rdmur...@bitdance.com > <mailto:rdmur...@bitdance.com>> wrote: > On Thu, 06 Aug 2015 18:16:53 -0000, Brett Cannon <bcan...@gmail.com > <mailto:bcan...@gmail.com>> wrote: > > > However, having a commit log based generator offers a relatively > > > decent way to deal with that: a Misc/NEWS.overrides directory, with > > > filename prefixes based on the commit hashes to be overridden. > > > > > > > This is making me prefer MAL's #4 solution. > > I'm liking this solution as well...there's programming work to be done > regardless, and adding a tracker field isn't *that* hard. > > However, the problem Nick points out above is really still an issue we > ought to address at some point even if we don't take NEWS info from the > commit messages, because it would be nice to be able to do some > automated checks about the relationships between issues and commits, and > to do that we have to have some way to "edit" the commit messages where > we specify the wrong issue number. > > Could there be some sort of Mercurial solution for that problem? > > > Short or an errata file for commit messages I don't think there is thanks to > Mercurial's strong stance on immutable commit data. Does git even allow > editing the commit message after the fact?
You can edit it sure, but it will create a new commit and divergent histories so it’s not going to do something generally useful for already pushed commits. > > In addition to the "NEWS relevant changes *must* have a tracker issue" > (which I agree is good anyway), another thing to keep in mind for the > tracker based proposal is that it will make the versions and resolution > fields more meaningful, and thus more care must be taken with those > fields. I don't see this as a bad thing either, but it is something we > need to recognize and deal with if we deploy this solution. > > Yep. > > > Oh, and it does mean that the technique we have sometimes used of > removing versions from the list once the fix is committed to that > version would have to be changed. So that involves some retraining > as well. > > Yes, it would mean either a second field to list what versions the fix has > been applied to (eww), or simply having to read through the messages of the > issue to keep track of where a fix still need to be applied and not > considering it fixed until all versions have received the fix. > _______________________________________________ > core-workflow mailing list > core-workflow@python.org <mailto:core-workflow@python.org> > https://mail.python.org/mailman/listinfo/core-workflow > <https://mail.python.org/mailman/listinfo/core-workflow> > This list is governed by the PSF Code of Conduct: > https://www.python.org/psf/codeofconduct > <https://www.python.org/psf/codeofconduct>
_______________________________________________ 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
