[core-workflow] the Misc/NEWS problem

[Donald Stufft]

> On Aug 6, 2015, at 4:06 PM, Brett Cannon <bcannon at gmail.com> wrote:
> 
> 
> 
> On Thu, Aug 6, 2015 at 12:46 PM R. David Murray <rdmurray at bitdance.com <mailto:rdmurray at bitdance.com>> wrote:
> On Thu, 06 Aug 2015 18:16:53 -0000, Brett Cannon <bcannon at gmail.com <mailto:bcannon at 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 at python.org <mailto:core-workflow at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150806/0fe4c702/attachment-0001.html>