We should be using the "Other Changes" section of CHANGES.txt more sparingly

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

We should be using the "Other Changes" section of CHANGES.txt more sparingly

Chris Hostetter-3

The "Other Changes" list in the 7.4 section of solr/CHANGES.txt is
currently the largest list (by number if jiras) for all of 7.4 -- and
includes many things that AFAICT really seem like they should
be listed in one of the more specific list: New Features, Bug Fixes,
Optimizations.

I would like to suggest that committers should really second guess any
inclinaion to put something in "Other Changes" before doing so .. it
should really be the choice of last resort.  users should be able to
understand at a glance what important changes tye may care about, and
burying stuffin "Other" makes that hard.

A good rule of thumb is that if your CHANGES entry uses words "Fix" or
"Improve" then that really sounds like a Bug Fix.  If folks are worried
about "pollutting"  the Bug Fixes section with fixes to *test* bugs, then
let's break them out into a new "Test Improvements/Fixes" section.



-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: We should be using the "Other Changes" section of CHANGES.txt more sparingly

david.w.smiley@gmail.com
I just read through 7.4's Other Changes.  IMO they belong where they are except maybe SOLR-12176 (just by reading the notes here; I didn't go into any issue).  What is the point of adding a new section pertaining to tests?

~ David

On Thu, Apr 5, 2018 at 1:22 PM Chris Hostetter <[hidden email]> wrote:

The "Other Changes" list in the 7.4 section of solr/CHANGES.txt is
currently the largest list (by number if jiras) for all of 7.4 -- and
includes many things that AFAICT really seem like they should
be listed in one of the more specific list: New Features, Bug Fixes,
Optimizations.

I would like to suggest that committers should really second guess any
inclinaion to put something in "Other Changes" before doing so .. it
should really be the choice of last resort.  users should be able to
understand at a glance what important changes tye may care about, and
burying stuffin "Other" makes that hard.

A good rule of thumb is that if your CHANGES entry uses words "Fix" or
"Improve" then that really sounds like a Bug Fix.  If folks are worried
about "pollutting"  the Bug Fixes section with fixes to *test* bugs, then
let's break them out into a new "Test Improvements/Fixes" section.



-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
Reply | Threaded
Open this post in threaded view
|

Re: We should be using the "Other Changes" section of CHANGES.txt more sparingly

Chris Hostetter-3

: I just read through 7.4's Other Changes.  IMO they belong where they are
: except maybe SOLR-12176 (just by reading the notes here; I didn't go into
: any issue).  What is the point of adding a new section pertaining to tests?

Some of those are clearly "there was a bug ... and i fixed it" type issues
-- which means they *should* belong in "Bug Fixes" ... the only reazon i
can think of why they aren't is because they are specifically "there was a
bug IN A TEST ... and i fixed it" type issues, and i'm speculating that
they wound up in "Other" because folks didn't think of them as "real bugs" ...
that's my only reason for suggesting a "Test Improvements/Fixes"

IE: I don't think we need a new section, but if people don't want to put
"test bug fixes" into "bug fixes" then i'd rather have a new section then
dump them in "other"



Some of these though -- based purely on reading the CHANGES entry from
an end users perspective -- read as straight up bug fixes or new features
in solr itself...


* SOLR-12086: Fix format problem in FastLRUCache description string shown
on Cache Statistics page.
   ... why is that not listed as a bug fix? it was evidently a problem
that's now fixed -- isn't that the definition of a bug fix?

* SOLR-12095: AutoScalingHandler validates trigger configurations before
updating Zookeeper.
   ... why is that not listed as a bug fix (or a at least a new feature) ?
it certainly sounds like prior to this there would have been a very bad
outcome if you tried to use an invalid trigger confix.

* SOLR-12176: Improve FORCELEADER to handle the case when a replica win
the election but does not present in clusterstate
   ... why is that not listed as a bug fix (or a at least a new feature) ?
... again: it sounds really scary that prior to this "something"
(presumably bad) would hapen if a replica not in the cluster state won the
election.


Maybe the issue is that these are just poorly worded CHANGES entires that
make things sound worse/better/more-significant then they really are? but
if that's the case let's fix the text to more accurately reflect why they
aren't significant enough to be considered "bugs" (or "new features" if
people feel there is justification in saying "it wasn't really broken
before, but it's better now").

As things stand now, from the perspective of a user, i'm left thinking
"Whoa ... if autoscaling triggers weren't validated before this release,
and that didn't even merit being categorized as a 'bug fix' and was just
noted as an 'Other' change, then what other really scary stuff might not
even merrit a mention at all?


: On Thu, Apr 5, 2018 at 1:22 PM Chris Hostetter <[hidden email]>
: wrote:
:
: >
: > The "Other Changes" list in the 7.4 section of solr/CHANGES.txt is
: > currently the largest list (by number if jiras) for all of 7.4 -- and
: > includes many things that AFAICT really seem like they should
: > be listed in one of the more specific list: New Features, Bug Fixes,
: > Optimizations.
: >
: > I would like to suggest that committers should really second guess any
: > inclinaion to put something in "Other Changes" before doing so .. it
: > should really be the choice of last resort.  users should be able to
: > understand at a glance what important changes tye may care about, and
: > burying stuffin "Other" makes that hard.
: >
: > A good rule of thumb is that if your CHANGES entry uses words "Fix" or
: > "Improve" then that really sounds like a Bug Fix.  If folks are worried
: > about "pollutting"  the Bug Fixes section with fixes to *test* bugs, then
: > let's break them out into a new "Test Improvements/Fixes" section.
: >
: >
: >
: > -Hoss
: > http://www.lucidworks.com/
: >
: > ---------------------------------------------------------------------
: > To unsubscribe, e-mail: [hidden email]
: > For additional commands, e-mail: [hidden email]
: >
: > --
: Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
: LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
: http://www.solrenterprisesearchserver.com
:

-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: We should be using the "Other Changes" section of CHANGES.txt more sparingly

david.w.smiley@gmail.com
This issues you listed are gray areas; I won't debate each with you.  I respect your opinion.  I just don't see the value of a section for *test* bug fixes.  A user wants to know about the improvements, features, and bug fixes (to a running Solr instance).  Everything else is just not as interesting to a user so goes in other, even though technically it's a bug fix (to a test).

On Thu, Apr 5, 2018 at 2:12 PM Chris Hostetter <[hidden email]> wrote:

: I just read through 7.4's Other Changes.  IMO they belong where they are
: except maybe SOLR-12176 (just by reading the notes here; I didn't go into
: any issue).  What is the point of adding a new section pertaining to tests?

Some of those are clearly "there was a bug ... and i fixed it" type issues
-- which means they *should* belong in "Bug Fixes" ... the only reazon i
can think of why they aren't is because they are specifically "there was a
bug IN A TEST ... and i fixed it" type issues, and i'm speculating that
they wound up in "Other" because folks didn't think of them as "real bugs" ...
that's my only reason for suggesting a "Test Improvements/Fixes"

IE: I don't think we need a new section, but if people don't want to put
"test bug fixes" into "bug fixes" then i'd rather have a new section then
dump them in "other"



Some of these though -- based purely on reading the CHANGES entry from
an end users perspective -- read as straight up bug fixes or new features
in solr itself...


* SOLR-12086: Fix format problem in FastLRUCache description string shown
on Cache Statistics page.
   ... why is that not listed as a bug fix? it was evidently a problem
that's now fixed -- isn't that the definition of a bug fix?

* SOLR-12095: AutoScalingHandler validates trigger configurations before
updating Zookeeper.
   ... why is that not listed as a bug fix (or a at least a new feature) ?
it certainly sounds like prior to this there would have been a very bad
outcome if you tried to use an invalid trigger confix.

* SOLR-12176: Improve FORCELEADER to handle the case when a replica win
the election but does not present in clusterstate
   ... why is that not listed as a bug fix (or a at least a new feature) ?
... again: it sounds really scary that prior to this "something"
(presumably bad) would hapen if a replica not in the cluster state won the
election.


Maybe the issue is that these are just poorly worded CHANGES entires that
make things sound worse/better/more-significant then they really are? but
if that's the case let's fix the text to more accurately reflect why they
aren't significant enough to be considered "bugs" (or "new features" if
people feel there is justification in saying "it wasn't really broken
before, but it's better now").

As things stand now, from the perspective of a user, i'm left thinking
"Whoa ... if autoscaling triggers weren't validated before this release,
and that didn't even merit being categorized as a 'bug fix' and was just
noted as an 'Other' change, then what other really scary stuff might not
even merrit a mention at all?


: On Thu, Apr 5, 2018 at 1:22 PM Chris Hostetter <[hidden email]>
: wrote:
:
: >
: > The "Other Changes" list in the 7.4 section of solr/CHANGES.txt is
: > currently the largest list (by number if jiras) for all of 7.4 -- and
: > includes many things that AFAICT really seem like they should
: > be listed in one of the more specific list: New Features, Bug Fixes,
: > Optimizations.
: >
: > I would like to suggest that committers should really second guess any
: > inclinaion to put something in "Other Changes" before doing so .. it
: > should really be the choice of last resort.  users should be able to
: > understand at a glance what important changes tye may care about, and
: > burying stuffin "Other" makes that hard.
: >
: > A good rule of thumb is that if your CHANGES entry uses words "Fix" or
: > "Improve" then that really sounds like a Bug Fix.  If folks are worried
: > about "pollutting"  the Bug Fixes section with fixes to *test* bugs, then
: > let's break them out into a new "Test Improvements/Fixes" section.
: >
: >
: >
: > -Hoss
: > http://www.lucidworks.com/
: >
: > ---------------------------------------------------------------------
: > To unsubscribe, e-mail: [hidden email]
: > For additional commands, e-mail: [hidden email]
: >
: > --
: Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
: LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
: http://www.solrenterprisesearchserver.com
:

-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
Reply | Threaded
Open this post in threaded view
|

Re: We should be using the "Other Changes" section of CHANGES.txt more sparingly

Shawn Heisey-2
On 4/5/2018 12:38 PM, David Smiley wrote:
> This issues you listed are gray areas; I won't debate each with you. 
> I respect your opinion.  I just don't see the value of a section for
> *test* bug fixes.  A user wants to know about the improvements,
> features, and bug fixes (to a running Solr instance).  Everything else
> is just not as interesting to a user so goes in other, even though
> technically it's a bug fix (to a test).

I see two viable solutions.  One is a completely separate CHANGES file
for dev/test issues, the other is a new section in the existing file, so
that Other Changes isn't overrun as Hoss has noticed.

It's my opinion, which I think aligns with what Hoss is saying, that the
fact that Other Changes is getting so much use (abuse?) is an indication
of one of two things, and quite possibly both:

1) The sections we have are insufficient for proper classification.
2) We aren't putting issues in the right section.

Thanks,
Shawn


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: We should be using the "Other Changes" section of CHANGES.txt more sparingly

Jason Gerlowski
To toss my two cents in, I agree with Hoss's point generally.  Burying
important things that users may care about in "Other Changes" makes
them harder to discover, and we should start double-checking ourselves
on that.

But as for test-fix changes specifically, if the main purpose of
CHANGES.txt is to:

> be able to understand at a glance what important changes tye may care about

then I'm not sure test-fixes should be in CHANGES.txt at all.  Very
few users are going to care about test bug fixes when evaluating
what's new in a Solr, or what they'll need to do to upgrade.  The
added noise probably makes it harder for users to identify which
changes actually matter to them.

Best,

Jason

On Thu, Apr 5, 2018 at 2:56 PM, Shawn Heisey <[hidden email]> wrote:

> On 4/5/2018 12:38 PM, David Smiley wrote:
>> This issues you listed are gray areas; I won't debate each with you.
>> I respect your opinion.  I just don't see the value of a section for
>> *test* bug fixes.  A user wants to know about the improvements,
>> features, and bug fixes (to a running Solr instance).  Everything else
>> is just not as interesting to a user so goes in other, even though
>> technically it's a bug fix (to a test).
>
> I see two viable solutions.  One is a completely separate CHANGES file
> for dev/test issues, the other is a new section in the existing file, so
> that Other Changes isn't overrun as Hoss has noticed.
>
> It's my opinion, which I think aligns with what Hoss is saying, that the
> fact that Other Changes is getting so much use (abuse?) is an indication
> of one of two things, and quite possibly both:
>
> 1) The sections we have are insufficient for proper classification.
> 2) We aren't putting issues in the right section.
>
> Thanks,
> Shawn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: We should be using the "Other Changes" section of CHANGES.txt more sparingly

Anshum Gupta-3
I agree with Hoss about the fact that we should try and put things in better suited section. 'Other changes' feels like an easy way out to just put everything, but it makes it really difficult for end users/developers to look at a release and find changes that might be of interest to them.

I also think users are concerned/bothered about bug fixes to tests, and considering we have a reasonable number of commits in just that category, it calls for it's own section. It doesn't make any thing more confusing or hard to maintain, instead only makes it easier for everyone looking at the CHANGES.txt.

 Anshum




On Apr 5, 2018, at 12:21 PM, Jason Gerlowski <[hidden email]> wrote:

To toss my two cents in, I agree with Hoss's point generally.  Burying
important things that users may care about in "Other Changes" makes
them harder to discover, and we should start double-checking ourselves
on that.

But as for test-fix changes specifically, if the main purpose of
CHANGES.txt is to:

be able to understand at a glance what important changes tye may care about

then I'm not sure test-fixes should be in CHANGES.txt at all.  Very
few users are going to care about test bug fixes when evaluating
what's new in a Solr, or what they'll need to do to upgrade.  The
added noise probably makes it harder for users to identify which
changes actually matter to them.

Best,

Jason

On Thu, Apr 5, 2018 at 2:56 PM, Shawn Heisey <[hidden email]> wrote:
On 4/5/2018 12:38 PM, David Smiley wrote:
This issues you listed are gray areas; I won't debate each with you.
I respect your opinion.  I just don't see the value of a section for
*test* bug fixes.  A user wants to know about the improvements,
features, and bug fixes (to a running Solr instance).  Everything else
is just not as interesting to a user so goes in other, even though
technically it's a bug fix (to a test).

I see two viable solutions.  One is a completely separate CHANGES file
for dev/test issues, the other is a new section in the existing file, so
that Other Changes isn't overrun as Hoss has noticed.

It's my opinion, which I think aligns with what Hoss is saying, that the
fact that Other Changes is getting so much use (abuse?) is an indication
of one of two things, and quite possibly both:

1) The sections we have are insufficient for proper classification.
2) We aren't putting issues in the right section.

Thanks,
Shawn


---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]


---------------------------------------------------------------------
To unsubscribe, [hidden email]
For additional commands, [hidden email]



signature.asc (891 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: We should be using the "Other Changes" section of CHANGES.txt more sparingly

Erick Erickson
I'd like people to get credit for test fixes, whether in a new section
or not. Cleaning up tests is enough of a thankless task as it stands,
some recognition for attending to that is in order ;) CHANGES.txt is a
good place for that. Besides, having a section of that may encourage
people to take fixing tests more seriously.

On Thu, Apr 5, 2018 at 12:43 PM, Anshum Gupta <[hidden email]> wrote:

> I agree with Hoss about the fact that we should try and put things in better
> suited section. 'Other changes' feels like an easy way out to just put
> everything, but it makes it really difficult for end users/developers to
> look at a release and find changes that might be of interest to them.
>
> I also think users are concerned/bothered about bug fixes to tests, and
> considering we have a reasonable number of commits in just that category, it
> calls for it's own section. It doesn't make any thing more confusing or hard
> to maintain, instead only makes it easier for everyone looking at the
> CHANGES.txt.
>
>  Anshum
>
>
>
>
> On Apr 5, 2018, at 12:21 PM, Jason Gerlowski <[hidden email]> wrote:
>
> To toss my two cents in, I agree with Hoss's point generally.  Burying
> important things that users may care about in "Other Changes" makes
> them harder to discover, and we should start double-checking ourselves
> on that.
>
> But as for test-fix changes specifically, if the main purpose of
> CHANGES.txt is to:
>
> be able to understand at a glance what important changes tye may care about
>
>
> then I'm not sure test-fixes should be in CHANGES.txt at all.  Very
> few users are going to care about test bug fixes when evaluating
> what's new in a Solr, or what they'll need to do to upgrade.  The
> added noise probably makes it harder for users to identify which
> changes actually matter to them.
>
> Best,
>
> Jason
>
> On Thu, Apr 5, 2018 at 2:56 PM, Shawn Heisey <[hidden email]> wrote:
>
> On 4/5/2018 12:38 PM, David Smiley wrote:
>
> This issues you listed are gray areas; I won't debate each with you.
> I respect your opinion.  I just don't see the value of a section for
> *test* bug fixes.  A user wants to know about the improvements,
> features, and bug fixes (to a running Solr instance).  Everything else
> is just not as interesting to a user so goes in other, even though
> technically it's a bug fix (to a test).
>
>
> I see two viable solutions.  One is a completely separate CHANGES file
> for dev/test issues, the other is a new section in the existing file, so
> that Other Changes isn't overrun as Hoss has noticed.
>
> It's my opinion, which I think aligns with what Hoss is saying, that the
> fact that Other Changes is getting so much use (abuse?) is an indication
> of one of two things, and quite possibly both:
>
> 1) The sections we have are insufficient for proper classification.
> 2) We aren't putting issues in the right section.
>
> Thanks,
> Shawn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]