accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: [DISCUSS] CHANGES Documents
Date Thu, 20 Feb 2014 07:20:26 GMT
On Thu, Feb 20, 2014 at 12:32 AM, Josh Elser <> wrote:

> On 2/19/14, 10:10 PM, Sean Busbey wrote:
>> On Wed, Feb 19, 2014 at 10:33 PM, Christopher <>
>> wrote:
>>> value people are actually getting from this file. I strongly suspect
>>> that, if anything, people just want to know the simple answers "What's
>>> New?" and "Does this fix my bug yet?" questions, and I don't think
>>> this file answers either of those questions well in any of the
>>> previous releases. Nor do I think this format lends itself easily to
>>> answering those questions. A per-release "Release Notes" section on
>>> the website would probably be more useful for that purpose, with a
>>> footnote reference to SCM/JIRA for the full list of changes. But, is
>>> there another role the CHANGES file is expected to play which I'm
>>> overlooking?
>> The main one I can think of is "Will this break my already working system
>> in some other way?"
> I would think that something like an UPGRADE or any sort of document would
> be better served for this. Any other time, there shouldn't be anything
> required.

We allow incompatible changes outside of the public API on minor/bugfix
versions. Some of those changes can easily impact people building on
Accumulo (such as changes to core iterators). We should call those things

For incompatibilities since the previous major version, I don't really care
if we break things out in an UPGRADE document or add them to the CHANGES
file directly (provided the CHANGES file has a note that the UPGRADE
document contains those kinds of considerations).

>  So in addition to your two above major areas, I'd say a section on known
>> backwards incompatible changes[1] would cover things.
>> I agree that a section on the website would be more broadly useful than in
>> the distribution (esp if we're authoring this rather than generating it
>> via
>> jira). I think it would be beneficial, however, to use Markdown in the CMS
>> to author and then include that file directly in the distro as a snapshot
>> for those offline. Authoring in the CMS would hopefully also encourage us
>> to update the document incrementally rather than making the release
>> manager
>> handle it at the end.
>> The more I reread this thread, the more I like the release notes described
>> by Eric[2].
> While I agree that would be nice, I don't know of a quantitative way to
> determine that. Is "critical" categorized by some Jira priority? Do we end
> up omitting something that someone wanted? I feel like we should just
> bundle all changes for that release or none at that point.
We're the Accumulo community, we should be cognizant of what changes are
most likely to impact downstream users. After all, isn't that part of how
we define a public API in the first place?

Ideally, I'd say the jira priorities of CRITICAL and BLOCKER would capture
them. I wouldn't want to make that a requirement. Basically, just use lazy
consensus like we do for most other things.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message