Re: IMPORTANT: automatic changelog creation

[Allen Wittenauer <aw...@altiscale.com>]

I think it defeats the purpose ofu

On Jul 8, 2015, at 12:13 AM, Tsuyoshi Ozawa <oz...@apache.org> wrote:

> +1, thanks Allen and Andrew for taking lots effort!
> 
>> Is there any possibility that, we can restrict someone from editing the
>> issue in jira once its marked as "closed" after release?
> 
> Vinay's comment looks considerable for us to me. What do you think?


	If you lock closed liras, then how does re-open work when something gets reverted?

	I’m also not sure what purpose it ultimately serves.  Is it the fear that the release data that gets shipped with the src tar ball will be wrong? Is it that the data might change?  That happens now and is pretty much unfixable no matter what one does. [1]  Besides, it’s going to be *extremely* valuable for RMs to be able to edit the JIRA data when cutting a release, especially given how many people are refusing to write release notes for incompatible changes. Being easily audit-able _and easily fixable!_ is a huge win.

	It really is a feature that this data can be changed.

	Let’s say there is a change. Next release, we can re-roll the old change and release notes data for all releases and it will be correct on the website, etc, from that point on.

	FWIW, this is one of the reasons why we really should be publishing trunk’s doc-set to the website.  It’s generally more accurate than the last release. Never mind everyone seeming to think that “current” = trunk and getting confused when they write a doc patch that doesn’t apply to trunk.

[1] As part of the JIRA cleanup last year,  I added hundreds of JIRAs to 2.0.0-alpha and 0.23.x last year that were incorrectly marked for 0.24 and 3.0.0.  I doubt anyone but me (and the future 3.0.0 RM?) really cares.