On Thu, Aug 6, 2015 at 12:46 PM R. David Murray <rdmur...@bitdance.com> wrote:
> On Thu, 06 Aug 2015 18:16:53 -0000, Brett Cannon <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? > 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 https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
