You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Stefan Podkowinski <sp...@apache.org> on 2017/07/18 13:10:45 UTC

CHANGES.txt

Has there been any consensus in the past about what goes into
CHANGES.txt and what not? My naive assumption was that the intended
audience for the file are users who want to know about changes between
new releases. Having that in mind, I skipped changes.txt once in a while
for updates that have no relevance except for developers. For releases,
such as 4.0, the list is already substantial and hard to digest. I'm
also wondering how informative entries such as e.g. "Remove unused
method" are for the general user. So my question is, should we add all
resolved tickets to changes.txt, or should we try to keep the list less
verbose in the future?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org


Re: CHANGES.txt

Posted by Stefan Podkowinski <sp...@apache.org>.
Thanks your responses! Seems like all of you prefer to have both trivial
and non-trivial updates in CHANGES.txt. I'm going to keep that in mind,
but will continue to omit them for documentation edits.


On 18.07.2017 23:49, kurt greaves wrote:
> I agree that all patches should be added to changes.txt, just to rule out
> any ambiguities. When people look at Changes.txt it's usually to find
> something specific, not to browse the list of changes. Anything significant
> should make it into news.txt, which is more appropriate for users.
> changes.txt is more aimed at developers in my opinion.
> 
> On that note, messages like "Remove unused method" should be more specific,
> that's just a bad commit message in general, and doesn't give at context.
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org


RE: CHANGES.txt

Posted by kurt greaves <ku...@instaclustr.com>.
I agree that all patches should be added to changes.txt, just to rule out
any ambiguities. When people look at Changes.txt it's usually to find
something specific, not to browse the list of changes. Anything significant
should make it into news.txt, which is more appropriate for users.
changes.txt is more aimed at developers in my opinion.

On that note, messages like "Remove unused method" should be more specific,
that's just a bad commit message in general, and doesn't give at context.

RE: CHANGES.txt

Posted by Jacques-Henri Berthemet <ja...@genesys.com>.
I also think all issues should be kept in CHANGES.txt, it very useful either to find what changed or to track some obscure bugs months after the release. Sometime when developing plugins for Cassandra you find solutions/resolution there.

Maybe if you want to reduce the list you could provide a link to a Jira filter that lists all the fixed issues for 4.0 in the CHANGES.txt, but an offline list is always more convenient.

--
Jacques-Henri Berthemet

-----Original Message-----
From: Eric Evans [mailto:john.eric.evans@gmail.com] 
Sent: mardi 18 juillet 2017 07:09
To: dev@cassandra.apache.org
Subject: Re: CHANGES.txt

On Tue, Jul 18, 2017 at 8:10 AM, Stefan Podkowinski <sp...@apache.org> wrote:
> Has there been any consensus in the past about what goes into 
> CHANGES.txt and what not? My naive assumption was that the intended 
> audience for the file are users who want to know about changes between 
> new releases. Having that in mind, I skipped changes.txt once in a 
> while for updates that have no relevance except for developers. For 
> releases, such as 4.0, the list is already substantial and hard to 
> digest. I'm also wondering how informative entries such as e.g. 
> "Remove unused method" are for the general user. So my question is, 
> should we add all resolved tickets to changes.txt, or should we try to 
> keep the list less verbose in the future?

One problem with trying to be selective, is that it invites judgment as to what is or is not worthy for inclusion, and that's bound to be a slippery slope.  I also think it's not uncommon for what appears to be a trivial change for one person, to be very important to someone else.

I wonder if the length of the list for 4.0 doesn't have as much to do with the delays in getting it released.

--
Eric Evans
john.eric.evans@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org


Re: CHANGES.txt

Posted by Eric Evans <jo...@gmail.com>.
On Tue, Jul 18, 2017 at 8:10 AM, Stefan Podkowinski <sp...@apache.org> wrote:
> Has there been any consensus in the past about what goes into
> CHANGES.txt and what not? My naive assumption was that the intended
> audience for the file are users who want to know about changes between
> new releases. Having that in mind, I skipped changes.txt once in a while
> for updates that have no relevance except for developers. For releases,
> such as 4.0, the list is already substantial and hard to digest. I'm
> also wondering how informative entries such as e.g. "Remove unused
> method" are for the general user. So my question is, should we add all
> resolved tickets to changes.txt, or should we try to keep the list less
> verbose in the future?

One problem with trying to be selective, is that it invites judgment
as to what is or is not worthy for inclusion, and that's bound to be a
slippery slope.  I also think it's not uncommon for what appears to be
a trivial change for one person, to be very important to someone else.

I wonder if the length of the list for 4.0 doesn't have as much to do
with the delays in getting it released.

-- 
Eric Evans
john.eric.evans@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org