Github user ctubbsii commented on a diff in the pull request:

    https://github.com/apache/accumulo/pull/211#discussion_r99498747
  
    --- Diff: docs/src/main/asciidoc/chapters/administration.txt ---
    @@ -1182,17 +1182,19 @@ conditions that vary from the environments 
individually tested in the various
     components. For example, Accumulo's use of HDFS includes many short block
     reads, which differs from the more common full file read used in most
     map/reduce applications. We have found that certain versions of Accumulo 
and
    -Hadoop will include stability bugs that greatly affect overall stability. 
In
    -our testing, Accumulo 1.6.2, Hadoop 2.6.0, and Zookeeper 3.4.6 resulted in 
a
    -stable VM clusters that did not fail a month of testing, while Accumulo 
1.6.1,
    -Hadoop 2.5.1, and Zookeeper 3.4.5 had a mean time between failure of less 
than
    -a week under heavy ingest and query load. We expect that results will vary 
with
    -other configurations, and you should choose your software versions with 
that in
    -mind.
    -
    -
    -
    -
    -
    -
    -
    +Hadoop will include stability bugs that greatly affect overall stability.
    +Release notes typically contain information about versions used in
    +release testing.
    +
    +The following table shows the Hadoop, Zookeeper and
    +Thrift versions defined in the dependency section of the POM for building 
the
    +artifacts.  
    +
    +|================================================
    +|Accumulo |Hadoop |Zookeeper |Thrift
    +|1.7            |2.2.0     |3.4.6          |0.9.1
    +|1.8            |2.6.4     |3.4.6          |0.9.3
    +|================================================
    +
    --- End diff --
    
    The concern isn't that it's onerous. It's that it's likely to become stale, 
or incorrect, due to lack of maintenance, and that it can't be updated for a 
previous release, when the release notes can be.
    
    If the suggestion is based on a simplification of the table, I'd be 
interested to know what that simplified version would look like.
    
    As for preferring the user manual over the release notes, what exactly is 
the argument here? Just that some people might check there first? Because I'm 
pretty sure most people check the downloads page first, and with the way we're 
starting to use Jekyll feeds to publish releases, it really feels like the 
release notes are going to be the first things most users see. It's also the 
only place seasoned users are going to look... because the user manual 
typically doesn't get re-read by users who already know how to use it.
    
    Even if some people check the user manual first... they can be easily 
directed to the release notes on the website, with a single sentence that won't 
get stale. That would still allow all the other benefits of having the info on 
the release notes (ability to correct/update post-release, ability to get 
patch-release granularity instead of just major/minor, etc.)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

Reply via email to