It is and I haven't been really arguing about the validity of the point ;)

Ok, as the -1 stands I will try to re-spin it once again tonight, but the
timing might be a bit of an issue - I am dealing with some maintenance
emergency at my house as we speak...

Cos

On Fri, Aug 07, 2015 at 02:45AM, Evans Ye wrote:
> Yes. I'm very much agree with you.
> My way is just to hard code a fixed location of binaries in our code
> repository.
> I imaging by the time we reach about 90% complete of our new CI infra, we
> should have a location to store the newest binaries and either use a fixed
> latest link or use DNS to switch between the binaries.
> That would be much more elegant than mine. :)
> But in reality, we're limited by what we currently have, so I think we
> should still upgrade those repos in our code.
> Otherwise, users may get confused why they're getting an old packages
> deployed when using the new 1.0 release.
> I'm doing the -1 from the user point of view. Do you think this is
> reasonable?
> 
> 
> 
> 2015-08-07 2:24 GMT+08:00 Konstantin Boudnik <[email protected]>:
> 
> > 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
> > > > > >
> > > > >
> > > >
> >

Reply via email to