accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] CHANGES Documents
Date Thu, 20 Feb 2014 18:23:16 GMT
On Thu, Feb 20, 2014 at 1:21 PM, Keith Turner <keith@deenlo.com> wrote:

>
>
>
> On Thu, Feb 20, 2014 at 1:10 PM, Josh Elser <josh.elser@gmail.com> wrote:
>
>> On 2/20/14, 10:00 AM, Keith Turner wrote:
>>
>>> On Thu, Feb 20, 2014 at 1:10 AM, Sean Busbey<busbey+lists@cloudera.com
>>> >wrote:
>>>
>>>  >On Wed, Feb 19, 2014 at 10:33 PM, Christopher<ctubbsii@apache.org>
>>>>  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?"
>>>> >
>>>> >So in addition to your two above major areas, I'd say a section on
>>>> known
>>>> >backwards incompatible changes[1] would cover things.
>>>> >
>>>>
>>> I would really like to see this type of information called out in release
>>> notes.
>>>
>>
>> Agreed
>>
>>
>>
>>  There have been a lot of good ideas mentioned.  What do we want to do for
>>> 1.5.1?  I would not be opposed to waiting a few days on the 1.5.1 release
>>> if someone wants to create nice user friendly release notes.  Or for
>>> 1.5.1
>>> we could just continue to do what was done for 1.4.X releases.   For
>>> 1.6.0
>>> I think we should create a user friendly summary of whats important in
>>> the
>>> release.
>>>
>>>
>> I'd prefer to not hold up 1.5.1 for something like this, and would rather
>> just follow suite with 1.4. By this, you mean having all CHANGES from 1.4.X
>> and 1.5.0 in addition to the 1.5.1 changes, correct? Is this acceptable to
>> everyone? I know there were other suggestions made and don't want to
>> prematurely squash discussion.
>>
>
> I was thinking taking the 1.5.0 changes file and adding the 1.5.1 stuff to
> it.  If we did anything w/ 1.4, we would would only want to take 1.4.0
> changes and add that after 1.5.0.  Not all changes in 1.4.[1.2.3.4] are in
> 1.5 series and any changes that are in both are hopefully marked properly
> in jira and already in the 1.5.X list. Since the 1.4.0 changes were not
> listed in 1.5.0, I am not neutral on adding that in 1.5.1.
>

s/not neutral/not not neutral/


>
>
>>
>> For 1.6.0, I would be happy to play around with some static-content
>> generation tools (I like jekyll[1], personally, but I'll have to try out a
>> few for our needs. We could even try to reuse the ASF CMS codebase) and see
>> if we can get a markdown-generated document going that we can create a nice
>> release-notes page from.
>>
>> [1] http://jekyllrb.com/
>>
>
>

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