You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Nick Dimiduk <nd...@apache.org> on 2020/11/09 21:34:44 UTC
[DISCUSS] Consider truncating CHANGES.md files on new release branches
Heya,
The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big for
Github to render. Its content covers back to 0.99. This isn't really usable
by someone who wants to easily see what's new in the latest patch release.
I propose we truncate these changes files to what's new for the release
branch. It probably needs some more work, but the git-jira audit script [0]
is able to generate a report of what's new (never previously released) for
a target release-line branch. We could use this as the basis for the
CHANGES file when starting a new release-line branch. From then on, Yetus
takes care of the patch release updates.
What do you think?
Thanks,
Nick
[0]:
https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Stack <st...@duboce.net>.
Idea was CHANGEs.md + RELEASENOTES.md would have all changes listed, not
some subset, per Seans' text diagram. Should be accumulative. The build
scripts take care of making the new additions for you.
If the files have become large, lets add links to files that list changes
<1.0.0 and then changes between 1.0.0 and 2.0.0 on the tail of these files?
S
On Tue, Nov 10, 2020 at 3:37 AM Sean Busbey <bu...@apache.org> wrote:
> I thought we had written up a guide before for what goes in the changes
> file, but I can't find it at the moment.
>
> For branch 2.3 I am surprised at 0.99 stuff. I would expect:
>
> * 2.0.0
> * 2.1.0
> * 2.2.0
> * 2.3.[0-z]
>
> Because that would be enough that if I was coming from the prior major
> release I could see everything that might matter getting to the release.
>
> If we just include 2.3.z changes then I have to go look at each of the
> previous minor releases on the release line as well.
>
> We've talked for some time about possibly including release notes / changes
> for just those things in each individual release on the website before.
> Would adding something like that be sufficient for the use you're thinking
> of?
>
>
>
>
> On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <nd...@apache.org> wrote:
>
> > Heya,
> >
> > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big
> for
> > Github to render. Its content covers back to 0.99. This isn't really
> usable
> > by someone who wants to easily see what's new in the latest patch
> release.
> >
> > I propose we truncate these changes files to what's new for the release
> > branch. It probably needs some more work, but the git-jira audit script
> [0]
> > is able to generate a report of what's new (never previously released)
> for
> > a target release-line branch. We could use this as the basis for the
> > CHANGES file when starting a new release-line branch. From then on, Yetus
> > takes care of the patch release updates.
> >
> > What do you think?
> >
> > Thanks,
> > Nick
> >
> > [0]:
> >
> >
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
> >
>
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Stack <st...@duboce.net>.
On Wed, Dec 2, 2020 at 11:16 AM Andrew Purtell <ap...@apache.org> wrote:
> Like this?
>
> https://gist.github.com/apurtell/f5959f36b0b13d5e92f35b22549020cc
>
>
>
Looks good to me. 2.3.0 CHANGELOG doesn't display because it is too big --
it is an accumulation of all changes up to 2.3 (good IMO) whereas 2.2+2.1,
etc. are just the changes in those releases versus the previous version --
but you can view the 'raw version' of the 2.3 doc which is good enough I
think.
S
> On Wed, Dec 2, 2020 at 10:04 AM Nick Dimiduk <nd...@apache.org> wrote:
>
> > On Tue, Dec 1, 2020 at 12:16 PM Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> >> I think by git tag would work. Given the URL can be different from the
> >> visible anchor text we could use an exact git sha too, if there is
> concern
> >> that tags might be changed either accidentally or intentionally in a way
> >> that breaks embedded links in old changelogs.
> >>
> >
> > A link back to the CHANGES file in GitHub of a release tag, along with
> the
> > tag's sha at the time of link generation, would achieve my request that
> the
> > point to a rendered version of the changes file where possible. Thank
> you!
> >
> > On Tue, Dec 1, 2020 at 11:57 AM Nick Dimiduk <nd...@apache.org>
> wrote:
> >>
> >> > I am in favor of referring off to the changes files of older releases.
> >> > Would that be by git tag, or to the files in the distribution
> archives?
> >> >
> >> > I don’t think these changes files are for marketing as such. However,
> I
> >> > think they are intended to be human-readable (if not for humans, then
> >> > who/what, and why?). Not having a rendered version easily discoverable
> >> is a
> >> > barrier to this goal, and shrinking the file such that it renders in
> >> GitHub
> >> > is a low-cost approach to achieve that goal.
> >> >
> >> > Thanks,
> >> > Nick
> >> >
> >> > On Mon, Nov 30, 2020 at 20:04 Andrew Purtell <
> andrew.purtell@gmail.com>
> >> > wrote:
> >> >
> >> > > Unless there is an objection to the plan I described below, it will
> >> > happen
> >> > > tomorrow on branch-2 in prep for RC.
> >> > >
> >> > >
> >> > > > On Nov 30, 2020, at 4:46 PM, Andrew Purtell <ap...@apache.org>
> >> > wrote:
> >> > > >
> >> > > >
> >> > > > I'm glad I checked email before beginning the RC.
> >> > > >
> >> > > > How about this:
> >> > > >
> >> > > > CHANGES.md file that ships in 2.4.0 will contain URLs pointing to
> >> older
> >> > > CHANGES.md for 1.0.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0.
> >> > > >
> >> > > > CHANGES.md file that ships with 2.4.0 will list all issues
> completed
> >> > for
> >> > > 2.4.0
> >> > > >
> >> > > > CHANGES.md file that ships with 2.4.1 will list all issues
> completed
> >> > for
> >> > > 2.4.0 and 2.4.1.
> >> > > >
> >> > > > etc. until 2.5.0, at which point the CHANGES.md file that ships in
> >> > 2.5.0
> >> > > will contain URLs pointing to older CHANGES.md for 1.0.0, 2.0.0,
> >> 2.1.0,
> >> > > 2.2.0, 2.3.0, and 2.4.0, and will list all issues completed for
> 2.5.0.
> >> > > >
> >> > > > I have felt traditionally the changes file is not where we do
> >> release
> >> > > upgrade marketing.
> >> > > >
> >> > > > If the objective is giving user-friendly and self-service answers
> >> to an
> >> > > operator or developer asking, "why should I upgrade? / what's new in
> >> this
> >> > > release?", then I humbly submit we should bring back the practice of
> >> > > writing blog posts for blogs.apache.org/hbase. Speaking of which,
> >> that
> >> > > blog is in a somewhat sad state of disrepair with a lot of broken
> >> image
> >> > > links.
> >> > > >
> >> > > >
> >> > > >> On Mon, Nov 30, 2020 at 1:02 PM Stack <st...@duboce.net> wrote:
> >> > > >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk <
> ndimiduk@apache.org
> >> >
> >> > > wrote:
> >> > > >>
> >> > > >> > So concretely, the conclusion here is that the CHANGES.md file
> >> that
> >> > > ships
> >> > > >> > in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0,
> >> and
> >> > > 2.4.0?
> >> > > >> > The CHANGES.md file that ships in 2.4.1 will contain all of the
> >> > > above, plus
> >> > > >> > entries for 2.4.1.
> >> > > >> >
> >> > > >> >
> >> > > >> And the 1.0.0 changes.
> >> > > >>
> >> > > >> Point at a 1.0.0 CHANGES.md file rather than list the 1.0.0
> >> changes.
> >> > > Ditto
> >> > > >> for 2.0.0 changes. Could do pointer for older minor releases too
> if
> >> > too
> >> > > >> many items to list... 2.1 and maybe 2.2.
> >> > > >>
> >> > > >> S
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> > Are you sure that's what you want? That seems like more than we
> >> > need.
> >> > > >> >
> >> > > >> > Thanks,
> >> > > >> > Nick
> >> > > >> >
> >> > > >> > On Tue, Nov 10, 2020 at 5:47 PM 张铎(Duo Zhang) <
> >> > palomino219@gmail.com>
> >> > > >> > wrote:
> >> > > >> >
> >> > > >> > > +1 on what Sean proposed to include the changes started from
> >> the
> >> > > first
> >> > > >> > > major release.
> >> > > >> > >
> >> > > >> > > Sean Busbey <bu...@apache.org> 于2020年11月10日周二 下午7:37写道：
> >> > > >> > >
> >> > > >> > > > I thought we had written up a guide before for what goes in
> >> the
> >> > > changes
> >> > > >> > > > file, but I can't find it at the moment.
> >> > > >> > > >
> >> > > >> > > > For branch 2.3 I am surprised at 0.99 stuff. I would
> expect:
> >> > > >> > > >
> >> > > >> > > > * 2.0.0
> >> > > >> > > > * 2.1.0
> >> > > >> > > > * 2.2.0
> >> > > >> > > > * 2.3.[0-z]
> >> > > >> > > >
> >> > > >> > > > Because that would be enough that if I was coming from the
> >> prior
> >> > > major
> >> > > >> > > > release I could see everything that might matter getting to
> >> the
> >> > > >> > release.
> >> > > >> > > >
> >> > > >> > > > If we just include 2.3.z changes then I have to go look at
> >> each
> >> > > of the
> >> > > >> > > > previous minor releases on the release line as well.
> >> > > >> > > >
> >> > > >> > > > We've talked for some time about possibly including release
> >> > notes
> >> > > /
> >> > > >> > > changes
> >> > > >> > > > for just those things in each individual release on the
> >> website
> >> > > before.
> >> > > >> > > > Would adding something like that be sufficient for the use
> >> > you're
> >> > > >> > > thinking
> >> > > >> > > > of?
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > > On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <
> ndimiduk@apache.org
> >> >
> >> > > wrote:
> >> > > >> > > >
> >> > > >> > > > > Heya,
> >> > > >> > > > >
> >> > > >> > > > > The CHANGES.md file on branch-2.3 weighs in at over 1mb
> >> and is
> >> > > too
> >> > > >> > big
> >> > > >> > > > for
> >> > > >> > > > > Github to render. Its content covers back to 0.99. This
> >> isn't
> >> > > really
> >> > > >> > > > usable
> >> > > >> > > > > by someone who wants to easily see what's new in the
> latest
> >> > > patch
> >> > > >> > > > release.
> >> > > >> > > > >
> >> > > >> > > > > I propose we truncate these changes files to what's new
> for
> >> > the
> >> > > >> > release
> >> > > >> > > > > branch. It probably needs some more work, but the
> git-jira
> >> > audit
> >> > > >> > script
> >> > > >> > > > [0]
> >> > > >> > > > > is able to generate a report of what's new (never
> >> previously
> >> > > >> > released)
> >> > > >> > > > for
> >> > > >> > > > > a target release-line branch. We could use this as the
> >> basis
> >> > > for the
> >> > > >> > > > > CHANGES file when starting a new release-line branch.
> From
> >> > then
> >> > > on,
> >> > > >> > > Yetus
> >> > > >> > > > > takes care of the patch release updates.
> >> > > >> > > > >
> >> > > >> > > > > What do you think?
> >> > > >> > > > >
> >> > > >> > > > > Thanks,
> >> > > >> > > > > Nick
> >> > > >> > > > >
> >> > > >> > > > > [0]:
> >> > > >> > > > >
> >> > > >> > > > >
> >> > > >> > > >
> >> > > >> > >
> >> > > >> >
> >> > >
> >> >
> >>
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
> >> > > >> > > > >
> >> > > >> > > >
> >> > > >> > >
> >> > > >> >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Best regards,
> >> > > > Andrew
> >> > > >
> >> > > > Words like orphans lost among the crosstalk, meaning torn from
> >> truth's
> >> > > decrepit hands
> >> > > > - A23, Crosstalk
> >> > >
> >> >
> >>
> >>
> >> --
> >> Best regards,
> >> Andrew
> >>
> >> Words like orphans lost among the crosstalk, meaning torn from truth's
> >> decrepit hands
> >> - A23, Crosstalk
> >>
> >
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> - A23, Crosstalk
>
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Nick Dimiduk <nd...@apache.org>.
On Wed, Dec 2, 2020 at 11:16 AM Andrew Purtell <ap...@apache.org> wrote:
> Like this?
>
> https://gist.github.com/apurtell/f5959f36b0b13d5e92f35b22549020cc
>
+1 !
On Wed, Dec 2, 2020 at 10:04 AM Nick Dimiduk <nd...@apache.org> wrote:
>
>> On Tue, Dec 1, 2020 at 12:16 PM Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>>> I think by git tag would work. Given the URL can be different from the
>>> visible anchor text we could use an exact git sha too, if there is
>>> concern
>>> that tags might be changed either accidentally or intentionally in a way
>>> that breaks embedded links in old changelogs.
>>>
>>
>> A link back to the CHANGES file in GitHub of a release tag, along with
>> the tag's sha at the time of link generation, would achieve my request that
>> the point to a rendered version of the changes file where possible. Thank
>> you!
>>
>> On Tue, Dec 1, 2020 at 11:57 AM Nick Dimiduk <nd...@apache.org> wrote:
>>>
>>> > I am in favor of referring off to the changes files of older releases.
>>> > Would that be by git tag, or to the files in the distribution archives?
>>> >
>>> > I don’t think these changes files are for marketing as such. However, I
>>> > think they are intended to be human-readable (if not for humans, then
>>> > who/what, and why?). Not having a rendered version easily discoverable
>>> is a
>>> > barrier to this goal, and shrinking the file such that it renders in
>>> GitHub
>>> > is a low-cost approach to achieve that goal.
>>> >
>>> > Thanks,
>>> > Nick
>>> >
>>> > On Mon, Nov 30, 2020 at 20:04 Andrew Purtell <andrew.purtell@gmail.com
>>> >
>>> > wrote:
>>> >
>>> > > Unless there is an objection to the plan I described below, it will
>>> > happen
>>> > > tomorrow on branch-2 in prep for RC.
>>> > >
>>> > >
>>> > > > On Nov 30, 2020, at 4:46 PM, Andrew Purtell <ap...@apache.org>
>>> > wrote:
>>> > > >
>>> > > >
>>> > > > I'm glad I checked email before beginning the RC.
>>> > > >
>>> > > > How about this:
>>> > > >
>>> > > > CHANGES.md file that ships in 2.4.0 will contain URLs pointing to
>>> older
>>> > > CHANGES.md for 1.0.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0.
>>> > > >
>>> > > > CHANGES.md file that ships with 2.4.0 will list all issues
>>> completed
>>> > for
>>> > > 2.4.0
>>> > > >
>>> > > > CHANGES.md file that ships with 2.4.1 will list all issues
>>> completed
>>> > for
>>> > > 2.4.0 and 2.4.1.
>>> > > >
>>> > > > etc. until 2.5.0, at which point the CHANGES.md file that ships in
>>> > 2.5.0
>>> > > will contain URLs pointing to older CHANGES.md for 1.0.0, 2.0.0,
>>> 2.1.0,
>>> > > 2.2.0, 2.3.0, and 2.4.0, and will list all issues completed for
>>> 2.5.0.
>>> > > >
>>> > > > I have felt traditionally the changes file is not where we do
>>> release
>>> > > upgrade marketing.
>>> > > >
>>> > > > If the objective is giving user-friendly and self-service answers
>>> to an
>>> > > operator or developer asking, "why should I upgrade? / what's new in
>>> this
>>> > > release?", then I humbly submit we should bring back the practice of
>>> > > writing blog posts for blogs.apache.org/hbase. Speaking of which,
>>> that
>>> > > blog is in a somewhat sad state of disrepair with a lot of broken
>>> image
>>> > > links.
>>> > > >
>>> > > >
>>> > > >> On Mon, Nov 30, 2020 at 1:02 PM Stack <st...@duboce.net> wrote:
>>> > > >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk <
>>> ndimiduk@apache.org>
>>> > > wrote:
>>> > > >>
>>> > > >> > So concretely, the conclusion here is that the CHANGES.md file
>>> that
>>> > > ships
>>> > > >> > in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0,
>>> and
>>> > > 2.4.0?
>>> > > >> > The CHANGES.md file that ships in 2.4.1 will contain all of the
>>> > > above, plus
>>> > > >> > entries for 2.4.1.
>>> > > >> >
>>> > > >> >
>>> > > >> And the 1.0.0 changes.
>>> > > >>
>>> > > >> Point at a 1.0.0 CHANGES.md file rather than list the 1.0.0
>>> changes.
>>> > > Ditto
>>> > > >> for 2.0.0 changes. Could do pointer for older minor releases too
>>> if
>>> > too
>>> > > >> many items to list... 2.1 and maybe 2.2.
>>> > > >>
>>> > > >> S
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >> > Are you sure that's what you want? That seems like more than we
>>> > need.
>>> > > >> >
>>> > > >> > Thanks,
>>> > > >> > Nick
>>> > > >> >
>>> > > >> > On Tue, Nov 10, 2020 at 5:47 PM 张铎(Duo Zhang) <
>>> > palomino219@gmail.com>
>>> > > >> > wrote:
>>> > > >> >
>>> > > >> > > +1 on what Sean proposed to include the changes started from
>>> the
>>> > > first
>>> > > >> > > major release.
>>> > > >> > >
>>> > > >> > > Sean Busbey <bu...@apache.org> 于2020年11月10日周二 下午7:37写道：
>>> > > >> > >
>>> > > >> > > > I thought we had written up a guide before for what goes in
>>> the
>>> > > changes
>>> > > >> > > > file, but I can't find it at the moment.
>>> > > >> > > >
>>> > > >> > > > For branch 2.3 I am surprised at 0.99 stuff. I would expect:
>>> > > >> > > >
>>> > > >> > > > * 2.0.0
>>> > > >> > > > * 2.1.0
>>> > > >> > > > * 2.2.0
>>> > > >> > > > * 2.3.[0-z]
>>> > > >> > > >
>>> > > >> > > > Because that would be enough that if I was coming from the
>>> prior
>>> > > major
>>> > > >> > > > release I could see everything that might matter getting to
>>> the
>>> > > >> > release.
>>> > > >> > > >
>>> > > >> > > > If we just include 2.3.z changes then I have to go look at
>>> each
>>> > > of the
>>> > > >> > > > previous minor releases on the release line as well.
>>> > > >> > > >
>>> > > >> > > > We've talked for some time about possibly including release
>>> > notes
>>> > > /
>>> > > >> > > changes
>>> > > >> > > > for just those things in each individual release on the
>>> website
>>> > > before.
>>> > > >> > > > Would adding something like that be sufficient for the use
>>> > you're
>>> > > >> > > thinking
>>> > > >> > > > of?
>>> > > >> > > >
>>> > > >> > > >
>>> > > >> > > >
>>> > > >> > > >
>>> > > >> > > > On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <
>>> ndimiduk@apache.org>
>>> > > wrote:
>>> > > >> > > >
>>> > > >> > > > > Heya,
>>> > > >> > > > >
>>> > > >> > > > > The CHANGES.md file on branch-2.3 weighs in at over 1mb
>>> and is
>>> > > too
>>> > > >> > big
>>> > > >> > > > for
>>> > > >> > > > > Github to render. Its content covers back to 0.99. This
>>> isn't
>>> > > really
>>> > > >> > > > usable
>>> > > >> > > > > by someone who wants to easily see what's new in the
>>> latest
>>> > > patch
>>> > > >> > > > release.
>>> > > >> > > > >
>>> > > >> > > > > I propose we truncate these changes files to what's new
>>> for
>>> > the
>>> > > >> > release
>>> > > >> > > > > branch. It probably needs some more work, but the git-jira
>>> > audit
>>> > > >> > script
>>> > > >> > > > [0]
>>> > > >> > > > > is able to generate a report of what's new (never
>>> previously
>>> > > >> > released)
>>> > > >> > > > for
>>> > > >> > > > > a target release-line branch. We could use this as the
>>> basis
>>> > > for the
>>> > > >> > > > > CHANGES file when starting a new release-line branch. From
>>> > then
>>> > > on,
>>> > > >> > > Yetus
>>> > > >> > > > > takes care of the patch release updates.
>>> > > >> > > > >
>>> > > >> > > > > What do you think?
>>> > > >> > > > >
>>> > > >> > > > > Thanks,
>>> > > >> > > > > Nick
>>> > > >> > > > >
>>> > > >> > > > > [0]:
>>> > > >> > > > >
>>> > > >> > > > >
>>> > > >> > > >
>>> > > >> > >
>>> > > >> >
>>> > >
>>> >
>>> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
>>> > > >> > > > >
>>> > > >> > > >
>>> > > >> > >
>>> > > >> >
>>> > > >
>>> > > >
>>> > > > --
>>> > > > Best regards,
>>> > > > Andrew
>>> > > >
>>> > > > Words like orphans lost among the crosstalk, meaning torn from
>>> truth's
>>> > > decrepit hands
>>> > > > - A23, Crosstalk
>>> > >
>>> >
>>>
>>>
>>> --
>>> Best regards,
>>> Andrew
>>>
>>> Words like orphans lost among the crosstalk, meaning torn from truth's
>>> decrepit hands
>>> - A23, Crosstalk
>>>
>>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> - A23, Crosstalk
>
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Andrew Purtell <ap...@apache.org>.
Like this?
https://gist.github.com/apurtell/f5959f36b0b13d5e92f35b22549020cc
On Wed, Dec 2, 2020 at 10:04 AM Nick Dimiduk <nd...@apache.org> wrote:
> On Tue, Dec 1, 2020 at 12:16 PM Andrew Purtell <ap...@apache.org>
> wrote:
>
>> I think by git tag would work. Given the URL can be different from the
>> visible anchor text we could use an exact git sha too, if there is concern
>> that tags might be changed either accidentally or intentionally in a way
>> that breaks embedded links in old changelogs.
>>
>
> A link back to the CHANGES file in GitHub of a release tag, along with the
> tag's sha at the time of link generation, would achieve my request that the
> point to a rendered version of the changes file where possible. Thank you!
>
> On Tue, Dec 1, 2020 at 11:57 AM Nick Dimiduk <nd...@apache.org> wrote:
>>
>> > I am in favor of referring off to the changes files of older releases.
>> > Would that be by git tag, or to the files in the distribution archives?
>> >
>> > I don’t think these changes files are for marketing as such. However, I
>> > think they are intended to be human-readable (if not for humans, then
>> > who/what, and why?). Not having a rendered version easily discoverable
>> is a
>> > barrier to this goal, and shrinking the file such that it renders in
>> GitHub
>> > is a low-cost approach to achieve that goal.
>> >
>> > Thanks,
>> > Nick
>> >
>> > On Mon, Nov 30, 2020 at 20:04 Andrew Purtell <an...@gmail.com>
>> > wrote:
>> >
>> > > Unless there is an objection to the plan I described below, it will
>> > happen
>> > > tomorrow on branch-2 in prep for RC.
>> > >
>> > >
>> > > > On Nov 30, 2020, at 4:46 PM, Andrew Purtell <ap...@apache.org>
>> > wrote:
>> > > >
>> > > >
>> > > > I'm glad I checked email before beginning the RC.
>> > > >
>> > > > How about this:
>> > > >
>> > > > CHANGES.md file that ships in 2.4.0 will contain URLs pointing to
>> older
>> > > CHANGES.md for 1.0.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0.
>> > > >
>> > > > CHANGES.md file that ships with 2.4.0 will list all issues completed
>> > for
>> > > 2.4.0
>> > > >
>> > > > CHANGES.md file that ships with 2.4.1 will list all issues completed
>> > for
>> > > 2.4.0 and 2.4.1.
>> > > >
>> > > > etc. until 2.5.0, at which point the CHANGES.md file that ships in
>> > 2.5.0
>> > > will contain URLs pointing to older CHANGES.md for 1.0.0, 2.0.0,
>> 2.1.0,
>> > > 2.2.0, 2.3.0, and 2.4.0, and will list all issues completed for 2.5.0.
>> > > >
>> > > > I have felt traditionally the changes file is not where we do
>> release
>> > > upgrade marketing.
>> > > >
>> > > > If the objective is giving user-friendly and self-service answers
>> to an
>> > > operator or developer asking, "why should I upgrade? / what's new in
>> this
>> > > release?", then I humbly submit we should bring back the practice of
>> > > writing blog posts for blogs.apache.org/hbase. Speaking of which,
>> that
>> > > blog is in a somewhat sad state of disrepair with a lot of broken
>> image
>> > > links.
>> > > >
>> > > >
>> > > >> On Mon, Nov 30, 2020 at 1:02 PM Stack <st...@duboce.net> wrote:
>> > > >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk <ndimiduk@apache.org
>> >
>> > > wrote:
>> > > >>
>> > > >> > So concretely, the conclusion here is that the CHANGES.md file
>> that
>> > > ships
>> > > >> > in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0,
>> and
>> > > 2.4.0?
>> > > >> > The CHANGES.md file that ships in 2.4.1 will contain all of the
>> > > above, plus
>> > > >> > entries for 2.4.1.
>> > > >> >
>> > > >> >
>> > > >> And the 1.0.0 changes.
>> > > >>
>> > > >> Point at a 1.0.0 CHANGES.md file rather than list the 1.0.0
>> changes.
>> > > Ditto
>> > > >> for 2.0.0 changes. Could do pointer for older minor releases too if
>> > too
>> > > >> many items to list... 2.1 and maybe 2.2.
>> > > >>
>> > > >> S
>> > > >>
>> > > >>
>> > > >>
>> > > >> > Are you sure that's what you want? That seems like more than we
>> > need.
>> > > >> >
>> > > >> > Thanks,
>> > > >> > Nick
>> > > >> >
>> > > >> > On Tue, Nov 10, 2020 at 5:47 PM 张铎(Duo Zhang) <
>> > palomino219@gmail.com>
>> > > >> > wrote:
>> > > >> >
>> > > >> > > +1 on what Sean proposed to include the changes started from
>> the
>> > > first
>> > > >> > > major release.
>> > > >> > >
>> > > >> > > Sean Busbey <bu...@apache.org> 于2020年11月10日周二 下午7:37写道：
>> > > >> > >
>> > > >> > > > I thought we had written up a guide before for what goes in
>> the
>> > > changes
>> > > >> > > > file, but I can't find it at the moment.
>> > > >> > > >
>> > > >> > > > For branch 2.3 I am surprised at 0.99 stuff. I would expect:
>> > > >> > > >
>> > > >> > > > * 2.0.0
>> > > >> > > > * 2.1.0
>> > > >> > > > * 2.2.0
>> > > >> > > > * 2.3.[0-z]
>> > > >> > > >
>> > > >> > > > Because that would be enough that if I was coming from the
>> prior
>> > > major
>> > > >> > > > release I could see everything that might matter getting to
>> the
>> > > >> > release.
>> > > >> > > >
>> > > >> > > > If we just include 2.3.z changes then I have to go look at
>> each
>> > > of the
>> > > >> > > > previous minor releases on the release line as well.
>> > > >> > > >
>> > > >> > > > We've talked for some time about possibly including release
>> > notes
>> > > /
>> > > >> > > changes
>> > > >> > > > for just those things in each individual release on the
>> website
>> > > before.
>> > > >> > > > Would adding something like that be sufficient for the use
>> > you're
>> > > >> > > thinking
>> > > >> > > > of?
>> > > >> > > >
>> > > >> > > >
>> > > >> > > >
>> > > >> > > >
>> > > >> > > > On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <ndimiduk@apache.org
>> >
>> > > wrote:
>> > > >> > > >
>> > > >> > > > > Heya,
>> > > >> > > > >
>> > > >> > > > > The CHANGES.md file on branch-2.3 weighs in at over 1mb
>> and is
>> > > too
>> > > >> > big
>> > > >> > > > for
>> > > >> > > > > Github to render. Its content covers back to 0.99. This
>> isn't
>> > > really
>> > > >> > > > usable
>> > > >> > > > > by someone who wants to easily see what's new in the latest
>> > > patch
>> > > >> > > > release.
>> > > >> > > > >
>> > > >> > > > > I propose we truncate these changes files to what's new for
>> > the
>> > > >> > release
>> > > >> > > > > branch. It probably needs some more work, but the git-jira
>> > audit
>> > > >> > script
>> > > >> > > > [0]
>> > > >> > > > > is able to generate a report of what's new (never
>> previously
>> > > >> > released)
>> > > >> > > > for
>> > > >> > > > > a target release-line branch. We could use this as the
>> basis
>> > > for the
>> > > >> > > > > CHANGES file when starting a new release-line branch. From
>> > then
>> > > on,
>> > > >> > > Yetus
>> > > >> > > > > takes care of the patch release updates.
>> > > >> > > > >
>> > > >> > > > > What do you think?
>> > > >> > > > >
>> > > >> > > > > Thanks,
>> > > >> > > > > Nick
>> > > >> > > > >
>> > > >> > > > > [0]:
>> > > >> > > > >
>> > > >> > > > >
>> > > >> > > >
>> > > >> > >
>> > > >> >
>> > >
>> >
>> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
>> > > >> > > > >
>> > > >> > > >
>> > > >> > >
>> > > >> >
>> > > >
>> > > >
>> > > > --
>> > > > Best regards,
>> > > > Andrew
>> > > >
>> > > > Words like orphans lost among the crosstalk, meaning torn from
>> truth's
>> > > decrepit hands
>> > > > - A23, Crosstalk
>> > >
>> >
>>
>>
>> --
>> Best regards,
>> Andrew
>>
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>> - A23, Crosstalk
>>
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Nick Dimiduk <nd...@apache.org>.
On Tue, Dec 1, 2020 at 12:16 PM Andrew Purtell <ap...@apache.org> wrote:
> I think by git tag would work. Given the URL can be different from the
> visible anchor text we could use an exact git sha too, if there is concern
> that tags might be changed either accidentally or intentionally in a way
> that breaks embedded links in old changelogs.
>
A link back to the CHANGES file in GitHub of a release tag, along with the
tag's sha at the time of link generation, would achieve my request that the
point to a rendered version of the changes file where possible. Thank you!
On Tue, Dec 1, 2020 at 11:57 AM Nick Dimiduk <nd...@apache.org> wrote:
>
> > I am in favor of referring off to the changes files of older releases.
> > Would that be by git tag, or to the files in the distribution archives?
> >
> > I don’t think these changes files are for marketing as such. However, I
> > think they are intended to be human-readable (if not for humans, then
> > who/what, and why?). Not having a rendered version easily discoverable
> is a
> > barrier to this goal, and shrinking the file such that it renders in
> GitHub
> > is a low-cost approach to achieve that goal.
> >
> > Thanks,
> > Nick
> >
> > On Mon, Nov 30, 2020 at 20:04 Andrew Purtell <an...@gmail.com>
> > wrote:
> >
> > > Unless there is an objection to the plan I described below, it will
> > happen
> > > tomorrow on branch-2 in prep for RC.
> > >
> > >
> > > > On Nov 30, 2020, at 4:46 PM, Andrew Purtell <ap...@apache.org>
> > wrote:
> > > >
> > > >
> > > > I'm glad I checked email before beginning the RC.
> > > >
> > > > How about this:
> > > >
> > > > CHANGES.md file that ships in 2.4.0 will contain URLs pointing to
> older
> > > CHANGES.md for 1.0.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0.
> > > >
> > > > CHANGES.md file that ships with 2.4.0 will list all issues completed
> > for
> > > 2.4.0
> > > >
> > > > CHANGES.md file that ships with 2.4.1 will list all issues completed
> > for
> > > 2.4.0 and 2.4.1.
> > > >
> > > > etc. until 2.5.0, at which point the CHANGES.md file that ships in
> > 2.5.0
> > > will contain URLs pointing to older CHANGES.md for 1.0.0, 2.0.0, 2.1.0,
> > > 2.2.0, 2.3.0, and 2.4.0, and will list all issues completed for 2.5.0.
> > > >
> > > > I have felt traditionally the changes file is not where we do release
> > > upgrade marketing.
> > > >
> > > > If the objective is giving user-friendly and self-service answers to
> an
> > > operator or developer asking, "why should I upgrade? / what's new in
> this
> > > release?", then I humbly submit we should bring back the practice of
> > > writing blog posts for blogs.apache.org/hbase. Speaking of which, that
> > > blog is in a somewhat sad state of disrepair with a lot of broken image
> > > links.
> > > >
> > > >
> > > >> On Mon, Nov 30, 2020 at 1:02 PM Stack <st...@duboce.net> wrote:
> > > >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk <nd...@apache.org>
> > > wrote:
> > > >>
> > > >> > So concretely, the conclusion here is that the CHANGES.md file
> that
> > > ships
> > > >> > in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0,
> and
> > > 2.4.0?
> > > >> > The CHANGES.md file that ships in 2.4.1 will contain all of the
> > > above, plus
> > > >> > entries for 2.4.1.
> > > >> >
> > > >> >
> > > >> And the 1.0.0 changes.
> > > >>
> > > >> Point at a 1.0.0 CHANGES.md file rather than list the 1.0.0 changes.
> > > Ditto
> > > >> for 2.0.0 changes. Could do pointer for older minor releases too if
> > too
> > > >> many items to list... 2.1 and maybe 2.2.
> > > >>
> > > >> S
> > > >>
> > > >>
> > > >>
> > > >> > Are you sure that's what you want? That seems like more than we
> > need.
> > > >> >
> > > >> > Thanks,
> > > >> > Nick
> > > >> >
> > > >> > On Tue, Nov 10, 2020 at 5:47 PM 张铎(Duo Zhang) <
> > palomino219@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > +1 on what Sean proposed to include the changes started from the
> > > first
> > > >> > > major release.
> > > >> > >
> > > >> > > Sean Busbey <bu...@apache.org> 于2020年11月10日周二 下午7:37写道：
> > > >> > >
> > > >> > > > I thought we had written up a guide before for what goes in
> the
> > > changes
> > > >> > > > file, but I can't find it at the moment.
> > > >> > > >
> > > >> > > > For branch 2.3 I am surprised at 0.99 stuff. I would expect:
> > > >> > > >
> > > >> > > > * 2.0.0
> > > >> > > > * 2.1.0
> > > >> > > > * 2.2.0
> > > >> > > > * 2.3.[0-z]
> > > >> > > >
> > > >> > > > Because that would be enough that if I was coming from the
> prior
> > > major
> > > >> > > > release I could see everything that might matter getting to
> the
> > > >> > release.
> > > >> > > >
> > > >> > > > If we just include 2.3.z changes then I have to go look at
> each
> > > of the
> > > >> > > > previous minor releases on the release line as well.
> > > >> > > >
> > > >> > > > We've talked for some time about possibly including release
> > notes
> > > /
> > > >> > > changes
> > > >> > > > for just those things in each individual release on the
> website
> > > before.
> > > >> > > > Would adding something like that be sufficient for the use
> > you're
> > > >> > > thinking
> > > >> > > > of?
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <nd...@apache.org>
> > > wrote:
> > > >> > > >
> > > >> > > > > Heya,
> > > >> > > > >
> > > >> > > > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and
> is
> > > too
> > > >> > big
> > > >> > > > for
> > > >> > > > > Github to render. Its content covers back to 0.99. This
> isn't
> > > really
> > > >> > > > usable
> > > >> > > > > by someone who wants to easily see what's new in the latest
> > > patch
> > > >> > > > release.
> > > >> > > > >
> > > >> > > > > I propose we truncate these changes files to what's new for
> > the
> > > >> > release
> > > >> > > > > branch. It probably needs some more work, but the git-jira
> > audit
> > > >> > script
> > > >> > > > [0]
> > > >> > > > > is able to generate a report of what's new (never previously
> > > >> > released)
> > > >> > > > for
> > > >> > > > > a target release-line branch. We could use this as the basis
> > > for the
> > > >> > > > > CHANGES file when starting a new release-line branch. From
> > then
> > > on,
> > > >> > > Yetus
> > > >> > > > > takes care of the patch release updates.
> > > >> > > > >
> > > >> > > > > What do you think?
> > > >> > > > >
> > > >> > > > > Thanks,
> > > >> > > > > Nick
> > > >> > > > >
> > > >> > > > > [0]:
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > >
> >
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew
> > > >
> > > > Words like orphans lost among the crosstalk, meaning torn from
> truth's
> > > decrepit hands
> > > > - A23, Crosstalk
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> - A23, Crosstalk
>
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Andrew Purtell <ap...@apache.org>.
I think by git tag would work. Given the URL can be different from the
visible anchor text we could use an exact git sha too, if there is concern
that tags might be changed either accidentally or intentionally in a way
that breaks embedded links in old changelogs.
On Tue, Dec 1, 2020 at 11:57 AM Nick Dimiduk <nd...@apache.org> wrote:
> I am in favor of referring off to the changes files of older releases.
> Would that be by git tag, or to the files in the distribution archives?
>
> I don’t think these changes files are for marketing as such. However, I
> think they are intended to be human-readable (if not for humans, then
> who/what, and why?). Not having a rendered version easily discoverable is a
> barrier to this goal, and shrinking the file such that it renders in GitHub
> is a low-cost approach to achieve that goal.
>
> Thanks,
> Nick
>
> On Mon, Nov 30, 2020 at 20:04 Andrew Purtell <an...@gmail.com>
> wrote:
>
> > Unless there is an objection to the plan I described below, it will
> happen
> > tomorrow on branch-2 in prep for RC.
> >
> >
> > > On Nov 30, 2020, at 4:46 PM, Andrew Purtell <ap...@apache.org>
> wrote:
> > >
> > >
> > > I'm glad I checked email before beginning the RC.
> > >
> > > How about this:
> > >
> > > CHANGES.md file that ships in 2.4.0 will contain URLs pointing to older
> > CHANGES.md for 1.0.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0.
> > >
> > > CHANGES.md file that ships with 2.4.0 will list all issues completed
> for
> > 2.4.0
> > >
> > > CHANGES.md file that ships with 2.4.1 will list all issues completed
> for
> > 2.4.0 and 2.4.1.
> > >
> > > etc. until 2.5.0, at which point the CHANGES.md file that ships in
> 2.5.0
> > will contain URLs pointing to older CHANGES.md for 1.0.0, 2.0.0, 2.1.0,
> > 2.2.0, 2.3.0, and 2.4.0, and will list all issues completed for 2.5.0.
> > >
> > > I have felt traditionally the changes file is not where we do release
> > upgrade marketing.
> > >
> > > If the objective is giving user-friendly and self-service answers to an
> > operator or developer asking, "why should I upgrade? / what's new in this
> > release?", then I humbly submit we should bring back the practice of
> > writing blog posts for blogs.apache.org/hbase. Speaking of which, that
> > blog is in a somewhat sad state of disrepair with a lot of broken image
> > links.
> > >
> > >
> > >> On Mon, Nov 30, 2020 at 1:02 PM Stack <st...@duboce.net> wrote:
> > >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk <nd...@apache.org>
> > wrote:
> > >>
> > >> > So concretely, the conclusion here is that the CHANGES.md file that
> > ships
> > >> > in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0, and
> > 2.4.0?
> > >> > The CHANGES.md file that ships in 2.4.1 will contain all of the
> > above, plus
> > >> > entries for 2.4.1.
> > >> >
> > >> >
> > >> And the 1.0.0 changes.
> > >>
> > >> Point at a 1.0.0 CHANGES.md file rather than list the 1.0.0 changes.
> > Ditto
> > >> for 2.0.0 changes. Could do pointer for older minor releases too if
> too
> > >> many items to list... 2.1 and maybe 2.2.
> > >>
> > >> S
> > >>
> > >>
> > >>
> > >> > Are you sure that's what you want? That seems like more than we
> need.
> > >> >
> > >> > Thanks,
> > >> > Nick
> > >> >
> > >> > On Tue, Nov 10, 2020 at 5:47 PM 张铎(Duo Zhang) <
> palomino219@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > +1 on what Sean proposed to include the changes started from the
> > first
> > >> > > major release.
> > >> > >
> > >> > > Sean Busbey <bu...@apache.org> 于2020年11月10日周二 下午7:37写道：
> > >> > >
> > >> > > > I thought we had written up a guide before for what goes in the
> > changes
> > >> > > > file, but I can't find it at the moment.
> > >> > > >
> > >> > > > For branch 2.3 I am surprised at 0.99 stuff. I would expect:
> > >> > > >
> > >> > > > * 2.0.0
> > >> > > > * 2.1.0
> > >> > > > * 2.2.0
> > >> > > > * 2.3.[0-z]
> > >> > > >
> > >> > > > Because that would be enough that if I was coming from the prior
> > major
> > >> > > > release I could see everything that might matter getting to the
> > >> > release.
> > >> > > >
> > >> > > > If we just include 2.3.z changes then I have to go look at each
> > of the
> > >> > > > previous minor releases on the release line as well.
> > >> > > >
> > >> > > > We've talked for some time about possibly including release
> notes
> > /
> > >> > > changes
> > >> > > > for just those things in each individual release on the website
> > before.
> > >> > > > Would adding something like that be sufficient for the use
> you're
> > >> > > thinking
> > >> > > > of?
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <nd...@apache.org>
> > wrote:
> > >> > > >
> > >> > > > > Heya,
> > >> > > > >
> > >> > > > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is
> > too
> > >> > big
> > >> > > > for
> > >> > > > > Github to render. Its content covers back to 0.99. This isn't
> > really
> > >> > > > usable
> > >> > > > > by someone who wants to easily see what's new in the latest
> > patch
> > >> > > > release.
> > >> > > > >
> > >> > > > > I propose we truncate these changes files to what's new for
> the
> > >> > release
> > >> > > > > branch. It probably needs some more work, but the git-jira
> audit
> > >> > script
> > >> > > > [0]
> > >> > > > > is able to generate a report of what's new (never previously
> > >> > released)
> > >> > > > for
> > >> > > > > a target release-line branch. We could use this as the basis
> > for the
> > >> > > > > CHANGES file when starting a new release-line branch. From
> then
> > on,
> > >> > > Yetus
> > >> > > > > takes care of the patch release updates.
> > >> > > > >
> > >> > > > > What do you think?
> > >> > > > >
> > >> > > > > Thanks,
> > >> > > > > Nick
> > >> > > > >
> > >> > > > > [0]:
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> >
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> > > - A23, Crosstalk
> >
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Nick Dimiduk <nd...@apache.org>.
I am in favor of referring off to the changes files of older releases.
Would that be by git tag, or to the files in the distribution archives?
I don’t think these changes files are for marketing as such. However, I
think they are intended to be human-readable (if not for humans, then
who/what, and why?). Not having a rendered version easily discoverable is a
barrier to this goal, and shrinking the file such that it renders in GitHub
is a low-cost approach to achieve that goal.
Thanks,
Nick
On Mon, Nov 30, 2020 at 20:04 Andrew Purtell <an...@gmail.com>
wrote:
> Unless there is an objection to the plan I described below, it will happen
> tomorrow on branch-2 in prep for RC.
>
>
> > On Nov 30, 2020, at 4:46 PM, Andrew Purtell <ap...@apache.org> wrote:
> >
> >
> > I'm glad I checked email before beginning the RC.
> >
> > How about this:
> >
> > CHANGES.md file that ships in 2.4.0 will contain URLs pointing to older
> CHANGES.md for 1.0.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0.
> >
> > CHANGES.md file that ships with 2.4.0 will list all issues completed for
> 2.4.0
> >
> > CHANGES.md file that ships with 2.4.1 will list all issues completed for
> 2.4.0 and 2.4.1.
> >
> > etc. until 2.5.0, at which point the CHANGES.md file that ships in 2.5.0
> will contain URLs pointing to older CHANGES.md for 1.0.0, 2.0.0, 2.1.0,
> 2.2.0, 2.3.0, and 2.4.0, and will list all issues completed for 2.5.0.
> >
> > I have felt traditionally the changes file is not where we do release
> upgrade marketing.
> >
> > If the objective is giving user-friendly and self-service answers to an
> operator or developer asking, "why should I upgrade? / what's new in this
> release?", then I humbly submit we should bring back the practice of
> writing blog posts for blogs.apache.org/hbase. Speaking of which, that
> blog is in a somewhat sad state of disrepair with a lot of broken image
> links.
> >
> >
> >> On Mon, Nov 30, 2020 at 1:02 PM Stack <st...@duboce.net> wrote:
> >> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk <nd...@apache.org>
> wrote:
> >>
> >> > So concretely, the conclusion here is that the CHANGES.md file that
> ships
> >> > in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0, and
> 2.4.0?
> >> > The CHANGES.md file that ships in 2.4.1 will contain all of the
> above, plus
> >> > entries for 2.4.1.
> >> >
> >> >
> >> And the 1.0.0 changes.
> >>
> >> Point at a 1.0.0 CHANGES.md file rather than list the 1.0.0 changes.
> Ditto
> >> for 2.0.0 changes. Could do pointer for older minor releases too if too
> >> many items to list... 2.1 and maybe 2.2.
> >>
> >> S
> >>
> >>
> >>
> >> > Are you sure that's what you want? That seems like more than we need.
> >> >
> >> > Thanks,
> >> > Nick
> >> >
> >> > On Tue, Nov 10, 2020 at 5:47 PM 张铎(Duo Zhang) <pa...@gmail.com>
> >> > wrote:
> >> >
> >> > > +1 on what Sean proposed to include the changes started from the
> first
> >> > > major release.
> >> > >
> >> > > Sean Busbey <bu...@apache.org> 于2020年11月10日周二 下午7:37写道：
> >> > >
> >> > > > I thought we had written up a guide before for what goes in the
> changes
> >> > > > file, but I can't find it at the moment.
> >> > > >
> >> > > > For branch 2.3 I am surprised at 0.99 stuff. I would expect:
> >> > > >
> >> > > > * 2.0.0
> >> > > > * 2.1.0
> >> > > > * 2.2.0
> >> > > > * 2.3.[0-z]
> >> > > >
> >> > > > Because that would be enough that if I was coming from the prior
> major
> >> > > > release I could see everything that might matter getting to the
> >> > release.
> >> > > >
> >> > > > If we just include 2.3.z changes then I have to go look at each
> of the
> >> > > > previous minor releases on the release line as well.
> >> > > >
> >> > > > We've talked for some time about possibly including release notes
> /
> >> > > changes
> >> > > > for just those things in each individual release on the website
> before.
> >> > > > Would adding something like that be sufficient for the use you're
> >> > > thinking
> >> > > > of?
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <nd...@apache.org>
> wrote:
> >> > > >
> >> > > > > Heya,
> >> > > > >
> >> > > > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is
> too
> >> > big
> >> > > > for
> >> > > > > Github to render. Its content covers back to 0.99. This isn't
> really
> >> > > > usable
> >> > > > > by someone who wants to easily see what's new in the latest
> patch
> >> > > > release.
> >> > > > >
> >> > > > > I propose we truncate these changes files to what's new for the
> >> > release
> >> > > > > branch. It probably needs some more work, but the git-jira audit
> >> > script
> >> > > > [0]
> >> > > > > is able to generate a report of what's new (never previously
> >> > released)
> >> > > > for
> >> > > > > a target release-line branch. We could use this as the basis
> for the
> >> > > > > CHANGES file when starting a new release-line branch. From then
> on,
> >> > > Yetus
> >> > > > > takes care of the patch release updates.
> >> > > > >
> >> > > > > What do you think?
> >> > > > >
> >> > > > > Thanks,
> >> > > > > Nick
> >> > > > >
> >> > > > > [0]:
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
> >> > > > >
> >> > > >
> >> > >
> >> >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
> > - A23, Crosstalk
>
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Andrew Purtell <an...@gmail.com>.
Unless there is an objection to the plan I described below, it will happen tomorrow on branch-2 in prep for RC.
> On Nov 30, 2020, at 4:46 PM, Andrew Purtell <ap...@apache.org> wrote:
>
>
> I'm glad I checked email before beginning the RC.
>
> How about this:
>
> CHANGES.md file that ships in 2.4.0 will contain URLs pointing to older CHANGES.md for 1.0.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0.
>
> CHANGES.md file that ships with 2.4.0 will list all issues completed for 2.4.0
>
> CHANGES.md file that ships with 2.4.1 will list all issues completed for 2.4.0 and 2.4.1.
>
> etc. until 2.5.0, at which point the CHANGES.md file that ships in 2.5.0 will contain URLs pointing to older CHANGES.md for 1.0.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0, and 2.4.0, and will list all issues completed for 2.5.0.
>
> I have felt traditionally the changes file is not where we do release upgrade marketing.
>
> If the objective is giving user-friendly and self-service answers to an operator or developer asking, "why should I upgrade? / what's new in this release?", then I humbly submit we should bring back the practice of writing blog posts for blogs.apache.org/hbase. Speaking of which, that blog is in a somewhat sad state of disrepair with a lot of broken image links.
>
>
>> On Mon, Nov 30, 2020 at 1:02 PM Stack <st...@duboce.net> wrote:
>> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk <nd...@apache.org> wrote:
>>
>> > So concretely, the conclusion here is that the CHANGES.md file that ships
>> > in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0, and 2.4.0?
>> > The CHANGES.md file that ships in 2.4.1 will contain all of the above, plus
>> > entries for 2.4.1.
>> >
>> >
>> And the 1.0.0 changes.
>>
>> Point at a 1.0.0 CHANGES.md file rather than list the 1.0.0 changes. Ditto
>> for 2.0.0 changes. Could do pointer for older minor releases too if too
>> many items to list... 2.1 and maybe 2.2.
>>
>> S
>>
>>
>>
>> > Are you sure that's what you want? That seems like more than we need.
>> >
>> > Thanks,
>> > Nick
>> >
>> > On Tue, Nov 10, 2020 at 5:47 PM 张铎(Duo Zhang) <pa...@gmail.com>
>> > wrote:
>> >
>> > > +1 on what Sean proposed to include the changes started from the first
>> > > major release.
>> > >
>> > > Sean Busbey <bu...@apache.org> 于2020年11月10日周二 下午7:37写道：
>> > >
>> > > > I thought we had written up a guide before for what goes in the changes
>> > > > file, but I can't find it at the moment.
>> > > >
>> > > > For branch 2.3 I am surprised at 0.99 stuff. I would expect:
>> > > >
>> > > > * 2.0.0
>> > > > * 2.1.0
>> > > > * 2.2.0
>> > > > * 2.3.[0-z]
>> > > >
>> > > > Because that would be enough that if I was coming from the prior major
>> > > > release I could see everything that might matter getting to the
>> > release.
>> > > >
>> > > > If we just include 2.3.z changes then I have to go look at each of the
>> > > > previous minor releases on the release line as well.
>> > > >
>> > > > We've talked for some time about possibly including release notes /
>> > > changes
>> > > > for just those things in each individual release on the website before.
>> > > > Would adding something like that be sufficient for the use you're
>> > > thinking
>> > > > of?
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <nd...@apache.org> wrote:
>> > > >
>> > > > > Heya,
>> > > > >
>> > > > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too
>> > big
>> > > > for
>> > > > > Github to render. Its content covers back to 0.99. This isn't really
>> > > > usable
>> > > > > by someone who wants to easily see what's new in the latest patch
>> > > > release.
>> > > > >
>> > > > > I propose we truncate these changes files to what's new for the
>> > release
>> > > > > branch. It probably needs some more work, but the git-jira audit
>> > script
>> > > > [0]
>> > > > > is able to generate a report of what's new (never previously
>> > released)
>> > > > for
>> > > > > a target release-line branch. We could use this as the basis for the
>> > > > > CHANGES file when starting a new release-line branch. From then on,
>> > > Yetus
>> > > > > takes care of the patch release updates.
>> > > > >
>> > > > > What do you think?
>> > > > >
>> > > > > Thanks,
>> > > > > Nick
>> > > > >
>> > > > > [0]:
>> > > > >
>> > > > >
>> > > >
>> > >
>> > https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
>> > > > >
>> > > >
>> > >
>> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands
> - A23, Crosstalk
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Andrew Purtell <ap...@apache.org>.
I'm glad I checked email before beginning the RC.
How about this:
CHANGES.md file that ships in 2.4.0 will contain URLs pointing to older
CHANGES.md for 1.0.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0.
CHANGES.md file that ships with 2.4.0 will list all issues completed for
2.4.0
CHANGES.md file that ships with 2.4.1 will list all issues completed for
2.4.0 and 2.4.1.
etc. until 2.5.0, at which point the CHANGES.md file that ships in 2.5.0
will contain URLs pointing to older CHANGES.md for 1.0.0, 2.0.0, 2.1.0,
2.2.0, 2.3.0, and 2.4.0, and will list all issues completed for 2.5.0.
I have felt traditionally the changes file is not where we do release
upgrade marketing.
If the objective is giving user-friendly and self-service answers to an
operator or developer asking, "why should I upgrade? / what's new in this
release?", then I humbly submit we should bring back the practice of
writing blog posts for blogs.apache.org/hbase. Speaking of which, that blog
is in a somewhat sad state of disrepair with a lot of broken image links.
On Mon, Nov 30, 2020 at 1:02 PM Stack <st...@duboce.net> wrote:
> On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk <nd...@apache.org> wrote:
>
> > So concretely, the conclusion here is that the CHANGES.md file that ships
> > in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0, and
> 2.4.0?
> > The CHANGES.md file that ships in 2.4.1 will contain all of the above,
> plus
> > entries for 2.4.1.
> >
> >
> And the 1.0.0 changes.
>
> Point at a 1.0.0 CHANGES.md file rather than list the 1.0.0 changes. Ditto
> for 2.0.0 changes. Could do pointer for older minor releases too if too
> many items to list... 2.1 and maybe 2.2.
>
> S
>
>
>
> > Are you sure that's what you want? That seems like more than we need.
> >
> > Thanks,
> > Nick
> >
> > On Tue, Nov 10, 2020 at 5:47 PM 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> >
> > > +1 on what Sean proposed to include the changes started from the first
> > > major release.
> > >
> > > Sean Busbey <bu...@apache.org> 于2020年11月10日周二 下午7:37写道：
> > >
> > > > I thought we had written up a guide before for what goes in the
> changes
> > > > file, but I can't find it at the moment.
> > > >
> > > > For branch 2.3 I am surprised at 0.99 stuff. I would expect:
> > > >
> > > > * 2.0.0
> > > > * 2.1.0
> > > > * 2.2.0
> > > > * 2.3.[0-z]
> > > >
> > > > Because that would be enough that if I was coming from the prior
> major
> > > > release I could see everything that might matter getting to the
> > release.
> > > >
> > > > If we just include 2.3.z changes then I have to go look at each of
> the
> > > > previous minor releases on the release line as well.
> > > >
> > > > We've talked for some time about possibly including release notes /
> > > changes
> > > > for just those things in each individual release on the website
> before.
> > > > Would adding something like that be sufficient for the use you're
> > > thinking
> > > > of?
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <nd...@apache.org> wrote:
> > > >
> > > > > Heya,
> > > > >
> > > > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too
> > big
> > > > for
> > > > > Github to render. Its content covers back to 0.99. This isn't
> really
> > > > usable
> > > > > by someone who wants to easily see what's new in the latest patch
> > > > release.
> > > > >
> > > > > I propose we truncate these changes files to what's new for the
> > release
> > > > > branch. It probably needs some more work, but the git-jira audit
> > script
> > > > [0]
> > > > > is able to generate a report of what's new (never previously
> > released)
> > > > for
> > > > > a target release-line branch. We could use this as the basis for
> the
> > > > > CHANGES file when starting a new release-line branch. From then on,
> > > Yetus
> > > > > takes care of the patch release updates.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Thanks,
> > > > > Nick
> > > > >
> > > > > [0]:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
> > > > >
> > > >
> > >
> >
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Stack <st...@duboce.net>.
On Mon, Nov 30, 2020 at 12:34 PM Nick Dimiduk <nd...@apache.org> wrote:
> So concretely, the conclusion here is that the CHANGES.md file that ships
> in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0, and 2.4.0?
> The CHANGES.md file that ships in 2.4.1 will contain all of the above, plus
> entries for 2.4.1.
>
>
And the 1.0.0 changes.
Point at a 1.0.0 CHANGES.md file rather than list the 1.0.0 changes. Ditto
for 2.0.0 changes. Could do pointer for older minor releases too if too
many items to list... 2.1 and maybe 2.2.
S
> Are you sure that's what you want? That seems like more than we need.
>
> Thanks,
> Nick
>
> On Tue, Nov 10, 2020 at 5:47 PM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
> > +1 on what Sean proposed to include the changes started from the first
> > major release.
> >
> > Sean Busbey <bu...@apache.org> 于2020年11月10日周二 下午7:37写道：
> >
> > > I thought we had written up a guide before for what goes in the changes
> > > file, but I can't find it at the moment.
> > >
> > > For branch 2.3 I am surprised at 0.99 stuff. I would expect:
> > >
> > > * 2.0.0
> > > * 2.1.0
> > > * 2.2.0
> > > * 2.3.[0-z]
> > >
> > > Because that would be enough that if I was coming from the prior major
> > > release I could see everything that might matter getting to the
> release.
> > >
> > > If we just include 2.3.z changes then I have to go look at each of the
> > > previous minor releases on the release line as well.
> > >
> > > We've talked for some time about possibly including release notes /
> > changes
> > > for just those things in each individual release on the website before.
> > > Would adding something like that be sufficient for the use you're
> > thinking
> > > of?
> > >
> > >
> > >
> > >
> > > On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <nd...@apache.org> wrote:
> > >
> > > > Heya,
> > > >
> > > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too
> big
> > > for
> > > > Github to render. Its content covers back to 0.99. This isn't really
> > > usable
> > > > by someone who wants to easily see what's new in the latest patch
> > > release.
> > > >
> > > > I propose we truncate these changes files to what's new for the
> release
> > > > branch. It probably needs some more work, but the git-jira audit
> script
> > > [0]
> > > > is able to generate a report of what's new (never previously
> released)
> > > for
> > > > a target release-line branch. We could use this as the basis for the
> > > > CHANGES file when starting a new release-line branch. From then on,
> > Yetus
> > > > takes care of the patch release updates.
> > > >
> > > > What do you think?
> > > >
> > > > Thanks,
> > > > Nick
> > > >
> > > > [0]:
> > > >
> > > >
> > >
> >
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
> > > >
> > >
> >
>
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Nick Dimiduk <nd...@apache.org>.
So concretely, the conclusion here is that the CHANGES.md file that ships
in 2.4.0 should contain entries for 2.0.0, 2.1.0, 2.2.0, 2.3.0, and 2.4.0?
The CHANGES.md file that ships in 2.4.1 will contain all of the above, plus
entries for 2.4.1.
Are you sure that's what you want? That seems like more than we need.
Thanks,
Nick
On Tue, Nov 10, 2020 at 5:47 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
> +1 on what Sean proposed to include the changes started from the first
> major release.
>
> Sean Busbey <bu...@apache.org> 于2020年11月10日周二 下午7:37写道：
>
> > I thought we had written up a guide before for what goes in the changes
> > file, but I can't find it at the moment.
> >
> > For branch 2.3 I am surprised at 0.99 stuff. I would expect:
> >
> > * 2.0.0
> > * 2.1.0
> > * 2.2.0
> > * 2.3.[0-z]
> >
> > Because that would be enough that if I was coming from the prior major
> > release I could see everything that might matter getting to the release.
> >
> > If we just include 2.3.z changes then I have to go look at each of the
> > previous minor releases on the release line as well.
> >
> > We've talked for some time about possibly including release notes /
> changes
> > for just those things in each individual release on the website before.
> > Would adding something like that be sufficient for the use you're
> thinking
> > of?
> >
> >
> >
> >
> > On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <nd...@apache.org> wrote:
> >
> > > Heya,
> > >
> > > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big
> > for
> > > Github to render. Its content covers back to 0.99. This isn't really
> > usable
> > > by someone who wants to easily see what's new in the latest patch
> > release.
> > >
> > > I propose we truncate these changes files to what's new for the release
> > > branch. It probably needs some more work, but the git-jira audit script
> > [0]
> > > is able to generate a report of what's new (never previously released)
> > for
> > > a target release-line branch. We could use this as the basis for the
> > > CHANGES file when starting a new release-line branch. From then on,
> Yetus
> > > takes care of the patch release updates.
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > Nick
> > >
> > > [0]:
> > >
> > >
> >
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
> > >
> >
>
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by "张铎 (Duo Zhang)" <pa...@gmail.com>.
+1 on what Sean proposed to include the changes started from the first
major release.
Sean Busbey <bu...@apache.org> 于2020年11月10日周二 下午7:37写道：
> I thought we had written up a guide before for what goes in the changes
> file, but I can't find it at the moment.
>
> For branch 2.3 I am surprised at 0.99 stuff. I would expect:
>
> * 2.0.0
> * 2.1.0
> * 2.2.0
> * 2.3.[0-z]
>
> Because that would be enough that if I was coming from the prior major
> release I could see everything that might matter getting to the release.
>
> If we just include 2.3.z changes then I have to go look at each of the
> previous minor releases on the release line as well.
>
> We've talked for some time about possibly including release notes / changes
> for just those things in each individual release on the website before.
> Would adding something like that be sufficient for the use you're thinking
> of?
>
>
>
>
> On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <nd...@apache.org> wrote:
>
> > Heya,
> >
> > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big
> for
> > Github to render. Its content covers back to 0.99. This isn't really
> usable
> > by someone who wants to easily see what's new in the latest patch
> release.
> >
> > I propose we truncate these changes files to what's new for the release
> > branch. It probably needs some more work, but the git-jira audit script
> [0]
> > is able to generate a report of what's new (never previously released)
> for
> > a target release-line branch. We could use this as the basis for the
> > CHANGES file when starting a new release-line branch. From then on, Yetus
> > takes care of the patch release updates.
> >
> > What do you think?
> >
> > Thanks,
> > Nick
> >
> > [0]:
> >
> >
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
> >
>
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Nick Dimiduk <nd...@apache.org>.
On Tue, Nov 10, 2020 at 3:37 AM Sean Busbey <bu...@apache.org> wrote:
> We've talked for some time about possibly including release notes / changes
> for just those things in each individual release on the website before.
> Would adding something like that be sufficient for the use you're thinking
> of?
>
Having a page on the site dedicated to this would suit my needs, but maybe
it's overkill if we can just "get it right" for the release tags visible on
github. My objective is giving a user-friendly and self-service answer to
an operator or developer asking, "why should I upgrade? / what's new in
this release?" The existing CHANGES.md file on the release tag would work,
except that the markdown doesn't render on Github due to size.
On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <nd...@apache.org> wrote:
>
> > Heya,
> >
> > The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big
> for
> > Github to render. Its content covers back to 0.99. This isn't really
> usable
> > by someone who wants to easily see what's new in the latest patch
> release.
> >
> > I propose we truncate these changes files to what's new for the release
> > branch. It probably needs some more work, but the git-jira audit script
> [0]
> > is able to generate a report of what's new (never previously released)
> for
> > a target release-line branch. We could use this as the basis for the
> > CHANGES file when starting a new release-line branch. From then on, Yetus
> > takes care of the patch release updates.
> >
> > What do you think?
> >
> > Thanks,
> > Nick
> >
> > [0]:
> >
> >
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
> >
>
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Sean Busbey <bu...@apache.org>.
I thought we had written up a guide before for what goes in the changes
file, but I can't find it at the moment.
For branch 2.3 I am surprised at 0.99 stuff. I would expect:
* 2.0.0
* 2.1.0
* 2.2.0
* 2.3.[0-z]
Because that would be enough that if I was coming from the prior major
release I could see everything that might matter getting to the release.
If we just include 2.3.z changes then I have to go look at each of the
previous minor releases on the release line as well.
We've talked for some time about possibly including release notes / changes
for just those things in each individual release on the website before.
Would adding something like that be sufficient for the use you're thinking
of?
On Mon, Nov 9, 2020, 15:35 Nick Dimiduk <nd...@apache.org> wrote:
> Heya,
>
> The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big for
> Github to render. Its content covers back to 0.99. This isn't really usable
> by someone who wants to easily see what's new in the latest patch release.
>
> I propose we truncate these changes files to what's new for the release
> branch. It probably needs some more work, but the git-jira audit script [0]
> is able to generate a report of what's new (never previously released) for
> a target release-line branch. We could use this as the basis for the
> CHANGES file when starting a new release-line branch. From then on, Yetus
> takes care of the patch release updates.
>
> What do you think?
>
> Thanks,
> Nick
>
> [0]:
>
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
>
Re: [DISCUSS] Consider truncating CHANGES.md files on new release branches
Posted by Viraj Jasani <vj...@apache.org>.
+1 for restricting CHANGES.md contents with what’s new after latest release
on the respective release line.
On Tue, 10 Nov 2020 at 3:05 AM, Nick Dimiduk <nd...@apache.org> wrote:
> Heya,
>
> The CHANGES.md file on branch-2.3 weighs in at over 1mb and is too big for
> Github to render. Its content covers back to 0.99. This isn't really usable
> by someone who wants to easily see what's new in the latest patch release.
>
> I propose we truncate these changes files to what's new for the release
> branch. It probably needs some more work, but the git-jira audit script [0]
> is able to generate a report of what's new (never previously released) for
> a target release-line branch. We could use this as the basis for the
> CHANGES file when starting a new release-line branch. From then on, Yetus
> takes care of the patch release updates.
>
> What do you think?
>
> Thanks,
> Nick
>
> [0]:
>
> https://github.com/apache/hbase/tree/master/dev-support/git-jira-release-audit
>