Message197976
| Author |
lemburg |
| Recipients |
brett.cannon, ezio.melotti, georg.brandl, lemburg, ncoghlan, orsenthil, pitrou, r.david.murray, tshepang |
| Date |
2013年09月17日.09:19:44 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<52381EAE.7060506@egenix.com> |
| In-reply-to |
<1379408951.52.0.912015409177.issue18967@psf.upfronthosting.co.za> |
| Content |
On 17.09.2013 11:09, Nick Coghlan wrote:
>
> Nick Coghlan added the comment:
>
> I agree the "different audiences" problem can be addressed by using appropriate commit message formatting to say "this bit goes in NEWS" (perhaps with some metadata to say which section).
>
> However, that doesn't solve the question of how we fix inevitable mistakes. One thought that occurs to me is a "fixNEWS" subdir where we can put text files named after commit hashes. If there is a file in fixNEWS, then the script would ignore the corresponding commit and use the file contents instead.
I don't think commit messages are the right place for such text.
They cannot be corrected after the fact, which makes them less
than ideal for the intended purposes: to produce an edited news
compilation.
I'm still not convinced we actually have a problem that needs to
be solved. Please consider the time it takes to resolve a merge
conflict vs. the time it takes to correct mistakes in commit
message formatting, educating committers and tweaking the script
to handle the inevitable mistakes.
Aside: It may be better to add support for news entries to the
tracker. At eGenix we're using a custom field called "News" which
is then listed in a report to build the change log. These can be
edited, there's only one entry per ticket and the report can be
sorted by priority/component/etc, putting the more important
news item at the top. |
|