hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Dropping CHANGES.txt?
Date Mon, 21 Nov 2011 19:01:27 GMT
I was thinking... our use of CHANGES.txt is a bit silly - we basically
maintain all of our changes in three places (a) JIRA fixVersion field,
(b) CHANGES.txt, and (c) the SVN changelog. It seems to me that we get
very little value out of CHANGES.txt -- the contents are way too large
(and terse) for any user to really follow, and it doesn't show us much
that JIRA wouldn't.

Two possible proposals for discussion:

Proposal 1) Completely remove CHANGES.txt. Part of the release job
would be to export the list of fixed JIRAs into an HTML file which we
can ship with the release.

With this proposal I'd also consider adding a checkbox to JIRA for
"Include in changelist?" Anything with an explicit release note or the
"Include in changelist" checkbox would get published.

Proposal 2) Leave CHANGES.txt, but make it more of a value judgment on
the part of the committer/patch author whether a patch deserves to go
in there. The main criteria would be "would a user care?" For example,
if it's a bug fix for something that regressed in SVN but was never
released, the user wouldn't care. If it's a bug fix from a previous
release, they would. If it's a minor build change or a fix to a unit
test, they wouldn't. etc etc (we could write up some guidelines on the
wiki)

Any support for the above?
-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Mime
View raw message