hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@altiscale.com>
Subject Re: IMPORTANT: automatic changelog creation
Date Wed, 08 Jul 2015 14:51:13 GMT

I think it defeats the purpose ofu

On Jul 8, 2015, at 12:13 AM, Tsuyoshi Ozawa <ozawa@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.  

View raw message