I think it defeats the purpose ofu
On Jul 8, 2015, at 12:13 AM, Tsuyoshi Ozawa <[email protected]> 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.
