Evans,
the location of the binaries' shouldn't be affecting the release IMO. Here's
the reason why: when the release is done we don't know where the binaries
will be hosted. Thus we have this chicken and egg issue here. Do you think we
should think of how to fix it past 1.0 time? Perhaps using some sort of
universal _latest_ link would do or similar.
I can respin the release - no problem with it: it is an easy process now. But
do you think you can reconsider your -1? I am fine either way.
Thanks for being so thorough with the checks!
Cos
On Fri, Aug 07, 2015 at 02:02AM, Evans Ye wrote:
> -1.
> I'm sorry to block the 1.0 release because the default repositories in
> bigtop-deploy are still in 0.8.
> It's my mistake that I didn't aware of it during the long time before the
> release. I apologise.
>
> I discovered this when doing RC tests on bigtop provisioners and puppet
> recipes.
> Actaully the functionality are all good, but we just need to point the repo
> to 1.0 so that user can get 1.0 cluster deployed right out of the box.
> If we do not update the repos, it's ok since no single function is broken.
> We just have a wired release with 0.8 content mixed in...
> To conclude, I think we better upgrade those default stuff in bigtop-deploy
> so that we have same semantic across all the module in the 1.0 release.
> I've fired BIGTOP-1958 <https://issues.apache.org/jira/browse/BIGTOP-1958> to
> apply the fix. Will upload patch soon.
> Sorry again, folks.
>
> 2015-08-07 1:05 GMT+08:00 RJ Nowling <[email protected]>:
>
> > +1 to release
> >
> > On Thu, Aug 6, 2015 at 10:03 AM, Sean Mackrory <[email protected]>
> > wrote:
> >
> > > +1. Checked hashes, some minor sanity testing.
> > >
> > > On Wed, Aug 5, 2015 at 11:22 PM, Edward J. Yoon <[email protected]>
> > > wrote:
> > >
> > > > As I mentioned above, I don't want to block the release because of
> > > > this feature. I don't care either way so please keep the process of
> > > > releasing! We can put it into next release. :-)
> > > >
> > > > On Thu, Aug 6, 2015 at 3:14 PM, Konstantin Boudnik <[email protected]>
> > > wrote:
> > > > > Sorry, is it for 1.0 or for pushing Hama to the next one?
> > > > >
> > > > > On Thu, Aug 06, 2015 at 03:03PM, Edward J. Yoon wrote:
> > > > >> Yup, +1
> > > > >>
> > > > >> On Thu, Aug 6, 2015 at 2:37 PM, Konstantin Boudnik <[email protected]>
> > > > wrote:
> > > > >> > Hello Edward.
> > > > >> >
> > > > >> > The vote is underway and the BOM for this release has been set and
> > > > agreed
> > > > >> > upon. 1.0 is a major step for this project and it'd be great to
> > have
> > > > it out of
> > > > >> > the door without anymore delays.
> > > > >> >
> > > > >> > Past 1.0 the release process should be easier, considering that
> > the
> > > > CI work is
> > > > >> > getting finished and we have wrapped a lot of major stuff into
> > 1.0.
> > > > I'd rather
> > > > >> > have Hama upgrade in the following release, which we can cut
> > pretty
> > > > soon.
> > > > >> >
> > > > >> > Does it make sense?
> > > > >> > Cos
> > > > >> >
> > > > >> > On Thu, Aug 06, 2015 at 01:14PM, Edward J. Yoon wrote:
> > > > >> >> Hi community,
> > > > >> >>
> > > > >> >> Please check whether BIGTOP-1126 can be added to 1.0 release. I
> > > would
> > > > >> >> say that the Hama 0.7 is stable enough and so should be added. Of
> > > > >> >> course, this shouldn't be a blocker!
> > > > >> >>
> > > > >> >> Thanks.
> > > > >> >>
> > > > >> >> On Thu, Aug 6, 2015 at 6:53 AM, Jay Vyas <
> > > > [email protected]> wrote:
> > > > >> >> > +1
> > > > >> >> >
> > > > >> >> >> On Aug 4, 2015, at 8:13 PM, Konstantin Boudnik <
> > [email protected]>
> > > > wrote:
> > > > >> >> >>
> > > > >> >> >> This is the vote for release 1.0.0 of Apache Bigtop.
> > > > >> >> >>
> > > > >> >> >> It fixes the following issues:
> > > > >> >> >>
> > > >
> > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326837&styleName=Text&projectId=12311420
> > > > >> >> >>
> > > > >> >> >> This is the respin of RC2, addressing an inclusion of a build
> > > > directory into
> > > > >> >> >> the release artifact. The rest of the release is the same.
> > > > Because of that
> > > > >> >> >> let's run a shorter (2 days) vote.
> > > > >> >> >>
> > > > >> >> >> The vote will be going for at least 48 hours and will be
> > closed
> > > > on Thursday
> > > > >> >> >> August 5th, 2015 at 1800 PDT. Please download, test and vote
> > > with
> > > > >> >> >>
> > > > >> >> >> [ ] +1, accept RC3 as the official 1.0.0 release of Apache
> > > Bigtop
> > > > >> >> >> [ ] +0, I don't care either way,
> > > > >> >> >> [ ] -1, do not accept RC3 as the official 1.0.0 release of
> > > Apache
> > > > Bigtop, because...
> > > > >> >> >>
> > > > >> >> >> Source and binary files:
> > > > >> >> >> http://people.apache.org/~cos/bigtop-1.0.0-RC3
> > > > >> >> >>
> > > > >> >> >> Maven staging repo:
> > > > >> >> >>
> > > >
> > https://repository.apache.org/content/repositories/orgapachebigtop-1003
> > > > >> >> >>
> > > > >> >> >> The git tag to be voted upon is release-1.0.0
> > > > >> >> >>
> > > > >> >> >> Bigtop's KEYS file containing PGP keys we use to sign the
> > > release:
> > > > >> >> >> http://svn.apache.org/repos/asf/bigtop/dist/KEYS
> > > > >> >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> --
> > > > >> >> Best Regards, Edward J. Yoon
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Best Regards, Edward J. Yoon
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Edward J. Yoon
> > > >
> > >
> >