If the tooling is in one place where will it live? As an RM I like not needing to checkout more then the repo I'm trying to get a release out on.
In particular my release machine is slow on disk and so updates to the main git repo when trying to release something not in the main repo will be painful. For the most part this is also why I usually manually build RCs that I run for the main repo, because I can do a shallow clone of the release branch instead of needing to get updates to all the active branches. For testing RCs I guess it's currently all some combination of the foundation policies that should be the same and maybe maven profiles? Iirc there was already some confusion about using the testing script that came in the main repo source bundle vs the one on master. What issue are we trying to solve? On Wed, Sep 18, 2019, 11:50 Nick Dimiduk <[email protected]> wrote: > Heya, > > Looks like we have quite a few repos now, each of which must produce > artifacts that follow the Apache protocols. I also see we have some nice > tools built up in dev-support in the main repo for RM's who build release > candidates and community members to vote on them. I tried to use our > hbase-vote.sh on this operator-tools RC and found it mostly works. I think > a few adjustments on each end would allow these tools to work across repos, > so I filed HBASE-23048. However, I now see that operator-tools has its own > dev-support/create-release, so I wonder what direction we want to take with > this automation, so here I come to the list. > > Do we want to have independent tooling for each repo? Are the processes of > building RC's different enough to warrant separate tools? Is a single tool > that can build an RC for all of them not worth the trouble? At the very > least, I think the hbase-vote.sh can be made to work with releases > generated from each of the repos, as it's not doing all that much. > > Thoughts? > > Thanks, > Nick > > On Wed, Sep 18, 2019 at 9:42 AM Nick Dimiduk <[email protected]> wrote: > > > +1 > > > > - Verified signatures. > > - Verified checksums. > > - Built from source tarball successfully. > > - Ran unit tests from source tarball, pass. > > - Ran rat check from source tarball, pass. > > > > > > On Mon, Sep 16, 2019 at 11:31 AM Peter Somogyi <[email protected]> > > wrote: > > > >> Please vote on this Apache HBase Operator Tools Release Candidate (RC), > >> 1.0.0. > >> > >> The VOTE will remain open for at least 72 hours. > >> > >> [ ] +1 Release this package as Apache HBase Operator Tools 1.0.0 > >> [ ] -1 Do not release this package because ... > >> > >> The tag to be voted on is 1.0.0RC0: > >> > >> https://github.com/apache/hbase-operator-tools/tree/1.0.0RC0 > >> > >> The release files, including signatures, digests, as well as CHANGES.md > >> and RELEASENOTES.md included in this RC can be found at: > >> > >> https://dist.apache.org/repos/dist/dev/hbase/1.0.0RC0/ > >> > >> Maven artifacts are available in a staging repository at: > >> > >> > https://repository.apache.org/content/repositories/orgapachehbase-1348/ > >> > >> Artifacts were signed with the [email protected] key which can be > found > >> in: > >> > >> https://dist.apache.org/repos/dist/release/hbase/KEYS > >> > >> To learn more about Apache HBase Operator Tools, please see > >> http://hbase.apache.org/ > >> > >> Thanks, > >> Your HBase Release Manager > >> > > >
