[
https://issues.apache.org/jira/browse/HBASE-21935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778558#comment-16778558
]
stack commented on HBASE-21935:
-------------------------------
bq. This means there'll be an open JIRA with the relevant fix version, no?
Yeah. Thats how its been done in past. Need to carry on in this manner or
suggest something different....
bq. Some time ago I set up a nightly test that followed the steps in the book
....
I see. Yeah, would be good to slot this script in if we can. Will look into it.
> Replace make_rc.sh with customized spark/dev/create-release
> -----------------------------------------------------------
>
> Key: HBASE-21935
> URL: https://issues.apache.org/jira/browse/HBASE-21935
> Project: HBase
> Issue Type: Task
> Components: rm
> Reporter: stack
> Assignee: stack
> Priority: Minor
> Labels: rm
> Attachments: HBASE-21935.branch-2.1.001.patch,
> HBASE-21935.branch-2.1.002.patch
>
>
> The spark/dev/create-release is more comprehensive than our hokey make_rc.sh
> script. It codifies the bulk of the RM process from tagging, version-setting,
> building, signing, and pushing. It does it in a container so environment is
> same each time. It has a bunch of spark-specifics as is -- naturally -- but
> should be possible to pull it around to suit hbase RM'ing. It'd save a bunch
> of time and would allow us to get to a place where RM'ing is canned,
> evolvable, and consistent.
> I've been hacking on the tooling before the filing of this JIRA and was
> polluting branch-2.0 w/ tagging and reverts. Let me make a branch named for
> this JIRA to play with (There is a dry-run flag but it too needs work...).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
