You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@reef.apache.org by Mariia Mykhailova <ma...@microsoft.com> on 2016/02/04 20:26:41 UTC
Should we postpone 0.14 release?
Right now we have two issues with tests (apart from Mesos failures for which fixes are in progress):
* WatcherTest failures in Travis and Jenkins (https://issues.apache.org/jira/browse/REEF-1040) which has been going on for over 2 months
* CanRunClrBridgeExampleOnLocalRuntime failure (https://issues.apache.org/jira/browse/REEF-1185) which we have discovered this week, and we don't yet know when it was broken first, because mstest was masking the failures.
I think we shouldn't proceed with the release until these failures are investigated and fixed.
What do you think?
-Mariia
Re: Should we postpone 0.14 release?
Posted by Byung-Gon Chun <bg...@gmail.com>.
Hi Mariia,
Thanks for bring this up.
I agree with you that it's better to postpone 0.14 a bit.
Yunseong, thought?
Thanks.
-Gon
On Fri, Feb 5, 2016 at 4:26 AM, Mariia Mykhailova <ma...@microsoft.com>
wrote:
> Right now we have two issues with tests (apart from Mesos failures for
> which fixes are in progress):
>
>
> * WatcherTest failures in Travis and Jenkins (
> https://issues.apache.org/jira/browse/REEF-1040) which has been going on
> for over 2 months
>
> * CanRunClrBridgeExampleOnLocalRuntime failure (
> https://issues.apache.org/jira/browse/REEF-1185) which we have discovered
> this week, and we don't yet know when it was broken first, because mstest
> was masking the failures.
>
> I think we shouldn't proceed with the release until these failures are
> investigated and fixed.
> What do you think?
>
> -Mariia
>
--
Byung-Gon Chun
Re: Should we postpone 0.14 release?
Posted by Dongjoon Hyun <do...@apache.org>.
Thank you, Gon. :)
Dongjoon.
On Tue, Feb 23, 2016 at 5:37 PM, Byung-Gon Chun <bg...@gmail.com> wrote:
> I created 0.15. Thanks.
>
>
> On Wed, Feb 24, 2016 at 9:27 AM, Dongjoon Hyun <do...@apache.org>
> wrote:
>
> > Thank you, Yunseong!
> >
> > By the way, our JIRA does not have '0.15' yet.
> > Could you make that, Markus?
> >
> > Dongjoon.
> >
> >
> > On Tue, Feb 23, 2016 at 2:32 AM, Byung-Gon Chun <bg...@gmail.com>
> wrote:
> >
> > > Thanks!
> > >
> > >
> > > On Tue, Feb 23, 2016 at 3:11 PM, Yunseong Lee <yunseong.lee0@gmail.com
> >
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I've created release branch after REEF-1181 (83f905d), and pushed the
> > > > commit for rc1. I'll call a vote pretty soon.
> > > >
> > > > From now on, reviewers please mark '0.15' for "Fix version".
> > > >
> > > > Thanks,
> > > > Yunseong
> > > >
> > > >
> > > > On Tue, Feb 23, 2016 at 3:34 AM, Yunseong Lee <
> yunseong.lee0@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Thanks Markus,
> > > > > Please check the inline comments.
> > > > >
> > > > > On Tue, Feb 23, 2016 at 3:26 AM, Markus Weimer <ma...@weimo.de>
> > > wrote:
> > > > >
> > > > >> On 2016-02-22 09:36, Yunseong Lee wrote:
> > > > >> > Some tests in REEF-IO have failed sporadically. Strangely, tests
> > > > >> > pass in OSX when I turn off WIFI. *Is there anyone suffering the
> > > > >> > same problem?*
> > > > >>
> > > > >> Yes. Not right now, but in the past, I have experienced test
> failure
> > > > >> depending on the network environment I was in. For me, tests
> passed
> > on
> > > > >> my home network, but not in "managed" networks like at work or in
> > > coffee
> > > > >> shops. My working theory is that those networks are configured in
> > ways
> > > > >> that make loopback networking on the *public* IP impossible.
> > > > >>
> > > > >>
> > > > > 1. Adding the hostname (result of hostname on bash shell) to
> > /etc/hosts
> > > > > worked for me. Now the build succeeds on Mac OSX.
> > > > >
> > > > > 2. But still, some tests in reef-io have failed in Ubuntu. Logs
> from
> > > the
> > > > > first failure is as following:
> > > > >
> > > > > Tests run: 8, Failures: 0, Errors: 3, Skipped: 0, Time elapsed:
> 10.67
> > > sec
> > > > >>>> <<< FAILURE! - in
> > > > org.apache.reef.io.network.NetworkConnectionServiceTest
> > > > >>>
> > > > >>>
> > > >
> > >
> >
> testMultithreadedSharedConnMessagingNetworkConnServiceRate(org.apache.reef.io.network.NetworkConnectionServiceTest)
> > > > >>>> Time elapsed: 2.223 sec <<< ERROR!
> > > > >>>
> > > > >>> org.apache.reef.tang.exceptions.InjectionException: Could not
> > invoke
> > > > >>>> constructor: new
> > > > >>>> NetworkConnectionServiceImpl(NetworkConnectionServiceIdFactory =
> > > > >>>> [ClassNodeImpl
> > > > 'org.apache.reef.io.network.util.StringIdentifierFactory']:
> > > > >>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
> > > > >>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a
> ,
> > > > >>>> Integer NetworkConnectionServicePort = 0, TransportFactory = new
> > > > >>>> MessagingTransportFactory(LocalAddressProvider = [ClassNodeImpl
> > > > >>>>
> > > >
> > 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > > > ),
> > > > >>>> NameResolver = new NameClient(String NameResolverNameServerAddr
> =
> > > > >>>> 127.0.0.1, Integer NameResolverNameServerPort = 13671, Long
> > > > >>>> NameResolverCacheTimeout = 30000, NameResolverIdentifierFactory
> =
> > > > >>>> [ClassNodeImpl
> > > > 'org.apache.reef.io.network.util.StringIdentifierFactory']:
> > > > >>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
> > > > >>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a
> ,
> > > > >>>> Integer NameResolverRetryCount = 10, Integer
> > > NameResolverRetryTimeout
> > > > =
> > > > >>>> 100, LocalAddressProvider = [ClassNodeImpl
> > > > >>>>
> > > >
> > 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > > > ,
> > > > >>>> TransportFactory = new
> > > MessagingTransportFactory(LocalAddressProvider
> > > > =
> > > > >>>> [ClassNodeImpl
> > > > >>>>
> > > >
> > 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > > > ),
> > > > >>>> new NameLookupClient(String NameResolverNameServerAddr =
> > 127.0.0.1,
> > > > Integer
> > > > >>>> NameResolverNameServerPort = 13671, Long
> NameResolverCacheTimeout
> > =
> > > > 30000,
> > > > >>>> NameResolverIdentifierFactory = [ClassNodeImpl
> > > > >>>> 'org.apache.reef.io.network.util.StringIdentifierFactory']:
> > > > >>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
> > > > >>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a
> ,
> > > > >>>> Integer NameResolverRetryCount = 10, Integer
> > > NameResolverRetryTimeout
> > > > =
> > > > >>>> 100, LocalAddressProvider = [ClassNodeImpl
> > > > >>>>
> > > >
> > 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > > > ,
> > > > >>>> TransportFactory = new
> > > MessagingTransportFactory(LocalAddressProvider
> > > > =
> > > > >>>> [ClassNodeImpl
> > > > >>>>
> > > >
> > 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > > > >>>> ))))
> > > > >>>
> > > > >>> at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method)
> > > > >>>
> > > > >>> at
> sun.nio.ch.EPollArrayWrapper.<init>(EPollArrayWrapper.java:130)
> > > > >>>
> > > > >>> at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:68)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36)
> > > > >>>
> > > > >>> at
> > > > io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:126)
> > > > >>>
> > > > >>> at
> io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:120)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:87)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:64)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:49)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:61)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:52)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.wake.remote.transport.netty.NettyMessagingTransport.<init>(NettyMessagingTransport.java:133)
> > > > >>>
> > > > >>> at sun.reflect.GeneratedConstructorAccessor7.newInstance(Unknown
> > > > Source)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> > > > >>>
> > > > >>> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:637)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:515)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:533)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.wake.remote.transport.netty.MessagingTransportFactory.newInstance(MessagingTransportFactory.java:75)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.io.network.impl.NetworkConnectionServiceImpl.<init>(NetworkConnectionServiceImpl.java:114)
> > > > >>>
> > > > >>> at sun.reflect.GeneratedConstructorAccessor15.newInstance(Unknown
> > > > Source)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> > > > >>>
> > > > >>> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:637)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:661)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:515)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:533)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.io.network.util.NetworkMessagingTestService.<init>(NetworkMessagingTestService.java:69)
> > > > >>>
> > > > >>> at
> > > > >>>>
> > > >
> > >
> >
> org.apache.reef.io.network.NetworkConnectionServiceTest.testMultithreadedSharedConnMessagingNetworkConnServiceRate(NetworkConnectionServiceTest.java:290)
> > > > >>>
> > > > >>>
> > > > > Would it have something to do with "[REEF-1124
> > > > > <https://issues.apache.org/jira/browse/REEF-1124>] Remove
> deprecated
> > > > > constructors of NameLookupClient"? I've found that the build
> succeeds
> > > > when
> > > > > I check out one commit ahead of REEF-1124. In which case could this
> > > > problem
> > > > > occur?
> > > > >
> > > > >
> > > > >> > 4. I'm working on signing process. Once my key successfully
> > granted
> > > > >> > to the Apache LDAP, I'll create the release branch and try my
> best
> > > > >> > to finish the release.
> > > > >>
> > > > >> Can you please have your GPG key signed by Gon? That way, it
> becomes
> > > > >> attached to the Apache Web of Trust and will sign it, too :)
> > > > >>
> > > > >>
> > > > > I've successfully added mine to the Apache (
> > > > > https://people.apache.org/keys/committer/). I'll move to the next
> > > steps
> > > > > tomorrow. :)
> > > > >
> > > > >
> > > > >
> > > > >> Thanks,
> > > > >>
> > > > >> Markus
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Byung-Gon Chun
> > >
> >
>
>
>
> --
> Byung-Gon Chun
>
Re: Should we postpone 0.14 release?
Posted by Byung-Gon Chun <bg...@gmail.com>.
I created 0.15. Thanks.
On Wed, Feb 24, 2016 at 9:27 AM, Dongjoon Hyun <do...@apache.org> wrote:
> Thank you, Yunseong!
>
> By the way, our JIRA does not have '0.15' yet.
> Could you make that, Markus?
>
> Dongjoon.
>
>
> On Tue, Feb 23, 2016 at 2:32 AM, Byung-Gon Chun <bg...@gmail.com> wrote:
>
> > Thanks!
> >
> >
> > On Tue, Feb 23, 2016 at 3:11 PM, Yunseong Lee <yu...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I've created release branch after REEF-1181 (83f905d), and pushed the
> > > commit for rc1. I'll call a vote pretty soon.
> > >
> > > From now on, reviewers please mark '0.15' for "Fix version".
> > >
> > > Thanks,
> > > Yunseong
> > >
> > >
> > > On Tue, Feb 23, 2016 at 3:34 AM, Yunseong Lee <yunseong.lee0@gmail.com
> >
> > > wrote:
> > >
> > > > Thanks Markus,
> > > > Please check the inline comments.
> > > >
> > > > On Tue, Feb 23, 2016 at 3:26 AM, Markus Weimer <ma...@weimo.de>
> > wrote:
> > > >
> > > >> On 2016-02-22 09:36, Yunseong Lee wrote:
> > > >> > Some tests in REEF-IO have failed sporadically. Strangely, tests
> > > >> > pass in OSX when I turn off WIFI. *Is there anyone suffering the
> > > >> > same problem?*
> > > >>
> > > >> Yes. Not right now, but in the past, I have experienced test failure
> > > >> depending on the network environment I was in. For me, tests passed
> on
> > > >> my home network, but not in "managed" networks like at work or in
> > coffee
> > > >> shops. My working theory is that those networks are configured in
> ways
> > > >> that make loopback networking on the *public* IP impossible.
> > > >>
> > > >>
> > > > 1. Adding the hostname (result of hostname on bash shell) to
> /etc/hosts
> > > > worked for me. Now the build succeeds on Mac OSX.
> > > >
> > > > 2. But still, some tests in reef-io have failed in Ubuntu. Logs from
> > the
> > > > first failure is as following:
> > > >
> > > > Tests run: 8, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 10.67
> > sec
> > > >>>> <<< FAILURE! - in
> > > org.apache.reef.io.network.NetworkConnectionServiceTest
> > > >>>
> > > >>>
> > >
> >
> testMultithreadedSharedConnMessagingNetworkConnServiceRate(org.apache.reef.io.network.NetworkConnectionServiceTest)
> > > >>>> Time elapsed: 2.223 sec <<< ERROR!
> > > >>>
> > > >>> org.apache.reef.tang.exceptions.InjectionException: Could not
> invoke
> > > >>>> constructor: new
> > > >>>> NetworkConnectionServiceImpl(NetworkConnectionServiceIdFactory =
> > > >>>> [ClassNodeImpl
> > > 'org.apache.reef.io.network.util.StringIdentifierFactory']:
> > > >>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
> > > >>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
> > > >>>> Integer NetworkConnectionServicePort = 0, TransportFactory = new
> > > >>>> MessagingTransportFactory(LocalAddressProvider = [ClassNodeImpl
> > > >>>>
> > >
> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > > >>>>
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > > >>>>
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > > ),
> > > >>>> NameResolver = new NameClient(String NameResolverNameServerAddr =
> > > >>>> 127.0.0.1, Integer NameResolverNameServerPort = 13671, Long
> > > >>>> NameResolverCacheTimeout = 30000, NameResolverIdentifierFactory =
> > > >>>> [ClassNodeImpl
> > > 'org.apache.reef.io.network.util.StringIdentifierFactory']:
> > > >>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
> > > >>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
> > > >>>> Integer NameResolverRetryCount = 10, Integer
> > NameResolverRetryTimeout
> > > =
> > > >>>> 100, LocalAddressProvider = [ClassNodeImpl
> > > >>>>
> > >
> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > > >>>>
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > > >>>>
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > > ,
> > > >>>> TransportFactory = new
> > MessagingTransportFactory(LocalAddressProvider
> > > =
> > > >>>> [ClassNodeImpl
> > > >>>>
> > >
> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > > >>>>
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > > >>>>
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > > ),
> > > >>>> new NameLookupClient(String NameResolverNameServerAddr =
> 127.0.0.1,
> > > Integer
> > > >>>> NameResolverNameServerPort = 13671, Long NameResolverCacheTimeout
> =
> > > 30000,
> > > >>>> NameResolverIdentifierFactory = [ClassNodeImpl
> > > >>>> 'org.apache.reef.io.network.util.StringIdentifierFactory']:
> > > >>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
> > > >>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
> > > >>>> Integer NameResolverRetryCount = 10, Integer
> > NameResolverRetryTimeout
> > > =
> > > >>>> 100, LocalAddressProvider = [ClassNodeImpl
> > > >>>>
> > >
> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > > >>>>
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > > >>>>
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > > ,
> > > >>>> TransportFactory = new
> > MessagingTransportFactory(LocalAddressProvider
> > > =
> > > >>>> [ClassNodeImpl
> > > >>>>
> > >
> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > > >>>>
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > > >>>>
> > >
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > > >>>> ))))
> > > >>>
> > > >>> at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method)
> > > >>>
> > > >>> at sun.nio.ch.EPollArrayWrapper.<init>(EPollArrayWrapper.java:130)
> > > >>>
> > > >>> at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:68)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36)
> > > >>>
> > > >>> at
> > > io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:126)
> > > >>>
> > > >>> at io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:120)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:87)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:64)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:49)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:61)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:52)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> org.apache.reef.wake.remote.transport.netty.NettyMessagingTransport.<init>(NettyMessagingTransport.java:133)
> > > >>>
> > > >>> at sun.reflect.GeneratedConstructorAccessor7.newInstance(Unknown
> > > Source)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> > > >>>
> > > >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:637)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:515)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:533)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> org.apache.reef.wake.remote.transport.netty.MessagingTransportFactory.newInstance(MessagingTransportFactory.java:75)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> org.apache.reef.io.network.impl.NetworkConnectionServiceImpl.<init>(NetworkConnectionServiceImpl.java:114)
> > > >>>
> > > >>> at sun.reflect.GeneratedConstructorAccessor15.newInstance(Unknown
> > > Source)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> > > >>>
> > > >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:637)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:661)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:515)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:533)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> org.apache.reef.io.network.util.NetworkMessagingTestService.<init>(NetworkMessagingTestService.java:69)
> > > >>>
> > > >>> at
> > > >>>>
> > >
> >
> org.apache.reef.io.network.NetworkConnectionServiceTest.testMultithreadedSharedConnMessagingNetworkConnServiceRate(NetworkConnectionServiceTest.java:290)
> > > >>>
> > > >>>
> > > > Would it have something to do with "[REEF-1124
> > > > <https://issues.apache.org/jira/browse/REEF-1124>] Remove deprecated
> > > > constructors of NameLookupClient"? I've found that the build succeeds
> > > when
> > > > I check out one commit ahead of REEF-1124. In which case could this
> > > problem
> > > > occur?
> > > >
> > > >
> > > >> > 4. I'm working on signing process. Once my key successfully
> granted
> > > >> > to the Apache LDAP, I'll create the release branch and try my best
> > > >> > to finish the release.
> > > >>
> > > >> Can you please have your GPG key signed by Gon? That way, it becomes
> > > >> attached to the Apache Web of Trust and will sign it, too :)
> > > >>
> > > >>
> > > > I've successfully added mine to the Apache (
> > > > https://people.apache.org/keys/committer/). I'll move to the next
> > steps
> > > > tomorrow. :)
> > > >
> > > >
> > > >
> > > >> Thanks,
> > > >>
> > > >> Markus
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Byung-Gon Chun
> >
>
--
Byung-Gon Chun
Re: Should we postpone 0.14 release?
Posted by Dongjoon Hyun <do...@apache.org>.
Thank you, Yunseong!
By the way, our JIRA does not have '0.15' yet.
Could you make that, Markus?
Dongjoon.
On Tue, Feb 23, 2016 at 2:32 AM, Byung-Gon Chun <bg...@gmail.com> wrote:
> Thanks!
>
>
> On Tue, Feb 23, 2016 at 3:11 PM, Yunseong Lee <yu...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I've created release branch after REEF-1181 (83f905d), and pushed the
> > commit for rc1. I'll call a vote pretty soon.
> >
> > From now on, reviewers please mark '0.15' for "Fix version".
> >
> > Thanks,
> > Yunseong
> >
> >
> > On Tue, Feb 23, 2016 at 3:34 AM, Yunseong Lee <yu...@gmail.com>
> > wrote:
> >
> > > Thanks Markus,
> > > Please check the inline comments.
> > >
> > > On Tue, Feb 23, 2016 at 3:26 AM, Markus Weimer <ma...@weimo.de>
> wrote:
> > >
> > >> On 2016-02-22 09:36, Yunseong Lee wrote:
> > >> > Some tests in REEF-IO have failed sporadically. Strangely, tests
> > >> > pass in OSX when I turn off WIFI. *Is there anyone suffering the
> > >> > same problem?*
> > >>
> > >> Yes. Not right now, but in the past, I have experienced test failure
> > >> depending on the network environment I was in. For me, tests passed on
> > >> my home network, but not in "managed" networks like at work or in
> coffee
> > >> shops. My working theory is that those networks are configured in ways
> > >> that make loopback networking on the *public* IP impossible.
> > >>
> > >>
> > > 1. Adding the hostname (result of hostname on bash shell) to /etc/hosts
> > > worked for me. Now the build succeeds on Mac OSX.
> > >
> > > 2. But still, some tests in reef-io have failed in Ubuntu. Logs from
> the
> > > first failure is as following:
> > >
> > > Tests run: 8, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 10.67
> sec
> > >>>> <<< FAILURE! - in
> > org.apache.reef.io.network.NetworkConnectionServiceTest
> > >>>
> > >>>
> >
> testMultithreadedSharedConnMessagingNetworkConnServiceRate(org.apache.reef.io.network.NetworkConnectionServiceTest)
> > >>>> Time elapsed: 2.223 sec <<< ERROR!
> > >>>
> > >>> org.apache.reef.tang.exceptions.InjectionException: Could not invoke
> > >>>> constructor: new
> > >>>> NetworkConnectionServiceImpl(NetworkConnectionServiceIdFactory =
> > >>>> [ClassNodeImpl
> > 'org.apache.reef.io.network.util.StringIdentifierFactory']:
> > >>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
> > >>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
> > >>>> Integer NetworkConnectionServicePort = 0, TransportFactory = new
> > >>>> MessagingTransportFactory(LocalAddressProvider = [ClassNodeImpl
> > >>>>
> > 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > >>>>
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > >>>>
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > ),
> > >>>> NameResolver = new NameClient(String NameResolverNameServerAddr =
> > >>>> 127.0.0.1, Integer NameResolverNameServerPort = 13671, Long
> > >>>> NameResolverCacheTimeout = 30000, NameResolverIdentifierFactory =
> > >>>> [ClassNodeImpl
> > 'org.apache.reef.io.network.util.StringIdentifierFactory']:
> > >>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
> > >>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
> > >>>> Integer NameResolverRetryCount = 10, Integer
> NameResolverRetryTimeout
> > =
> > >>>> 100, LocalAddressProvider = [ClassNodeImpl
> > >>>>
> > 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > >>>>
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > >>>>
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > ,
> > >>>> TransportFactory = new
> MessagingTransportFactory(LocalAddressProvider
> > =
> > >>>> [ClassNodeImpl
> > >>>>
> > 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > >>>>
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > >>>>
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > ),
> > >>>> new NameLookupClient(String NameResolverNameServerAddr = 127.0.0.1,
> > Integer
> > >>>> NameResolverNameServerPort = 13671, Long NameResolverCacheTimeout =
> > 30000,
> > >>>> NameResolverIdentifierFactory = [ClassNodeImpl
> > >>>> 'org.apache.reef.io.network.util.StringIdentifierFactory']:
> > >>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
> > >>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
> > >>>> Integer NameResolverRetryCount = 10, Integer
> NameResolverRetryTimeout
> > =
> > >>>> 100, LocalAddressProvider = [ClassNodeImpl
> > >>>>
> > 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > >>>>
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > >>>>
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > ,
> > >>>> TransportFactory = new
> MessagingTransportFactory(LocalAddressProvider
> > =
> > >>>> [ClassNodeImpl
> > >>>>
> > 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> > >>>>
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> > >>>>
> >
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> > >>>> ))))
> > >>>
> > >>> at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method)
> > >>>
> > >>> at sun.nio.ch.EPollArrayWrapper.<init>(EPollArrayWrapper.java:130)
> > >>>
> > >>> at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:68)
> > >>>
> > >>> at
> > >>>>
> >
> sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36)
> > >>>
> > >>> at
> > io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:126)
> > >>>
> > >>> at io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:120)
> > >>>
> > >>> at
> > >>>>
> >
> io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:87)
> > >>>
> > >>> at
> > >>>>
> >
> io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:64)
> > >>>
> > >>> at
> > >>>>
> >
> io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:49)
> > >>>
> > >>> at
> > >>>>
> > io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:61)
> > >>>
> > >>> at
> > >>>>
> > io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:52)
> > >>>
> > >>> at
> > >>>>
> >
> org.apache.reef.wake.remote.transport.netty.NettyMessagingTransport.<init>(NettyMessagingTransport.java:133)
> > >>>
> > >>> at sun.reflect.GeneratedConstructorAccessor7.newInstance(Unknown
> > Source)
> > >>>
> > >>> at
> > >>>>
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> > >>>
> > >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> > >>>
> > >>> at
> > >>>>
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:637)
> > >>>
> > >>> at
> > >>>>
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:515)
> > >>>
> > >>> at
> > >>>>
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:533)
> > >>>
> > >>> at
> > >>>>
> >
> org.apache.reef.wake.remote.transport.netty.MessagingTransportFactory.newInstance(MessagingTransportFactory.java:75)
> > >>>
> > >>> at
> > >>>>
> >
> org.apache.reef.io.network.impl.NetworkConnectionServiceImpl.<init>(NetworkConnectionServiceImpl.java:114)
> > >>>
> > >>> at sun.reflect.GeneratedConstructorAccessor15.newInstance(Unknown
> > Source)
> > >>>
> > >>> at
> > >>>>
> >
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> > >>>
> > >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> > >>>
> > >>> at
> > >>>>
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:637)
> > >>>
> > >>> at
> > >>>>
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:661)
> > >>>
> > >>> at
> > >>>>
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:515)
> > >>>
> > >>> at
> > >>>>
> >
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:533)
> > >>>
> > >>> at
> > >>>>
> >
> org.apache.reef.io.network.util.NetworkMessagingTestService.<init>(NetworkMessagingTestService.java:69)
> > >>>
> > >>> at
> > >>>>
> >
> org.apache.reef.io.network.NetworkConnectionServiceTest.testMultithreadedSharedConnMessagingNetworkConnServiceRate(NetworkConnectionServiceTest.java:290)
> > >>>
> > >>>
> > > Would it have something to do with "[REEF-1124
> > > <https://issues.apache.org/jira/browse/REEF-1124>] Remove deprecated
> > > constructors of NameLookupClient"? I've found that the build succeeds
> > when
> > > I check out one commit ahead of REEF-1124. In which case could this
> > problem
> > > occur?
> > >
> > >
> > >> > 4. I'm working on signing process. Once my key successfully granted
> > >> > to the Apache LDAP, I'll create the release branch and try my best
> > >> > to finish the release.
> > >>
> > >> Can you please have your GPG key signed by Gon? That way, it becomes
> > >> attached to the Apache Web of Trust and will sign it, too :)
> > >>
> > >>
> > > I've successfully added mine to the Apache (
> > > https://people.apache.org/keys/committer/). I'll move to the next
> steps
> > > tomorrow. :)
> > >
> > >
> > >
> > >> Thanks,
> > >>
> > >> Markus
> > >>
> > >
> > >
> >
>
>
>
> --
> Byung-Gon Chun
>
Re: Should we postpone 0.14 release?
Posted by Byung-Gon Chun <bg...@gmail.com>.
Thanks!
On Tue, Feb 23, 2016 at 3:11 PM, Yunseong Lee <yu...@gmail.com>
wrote:
> Hi,
>
> I've created release branch after REEF-1181 (83f905d), and pushed the
> commit for rc1. I'll call a vote pretty soon.
>
> From now on, reviewers please mark '0.15' for "Fix version".
>
> Thanks,
> Yunseong
>
>
> On Tue, Feb 23, 2016 at 3:34 AM, Yunseong Lee <yu...@gmail.com>
> wrote:
>
> > Thanks Markus,
> > Please check the inline comments.
> >
> > On Tue, Feb 23, 2016 at 3:26 AM, Markus Weimer <ma...@weimo.de> wrote:
> >
> >> On 2016-02-22 09:36, Yunseong Lee wrote:
> >> > Some tests in REEF-IO have failed sporadically. Strangely, tests
> >> > pass in OSX when I turn off WIFI. *Is there anyone suffering the
> >> > same problem?*
> >>
> >> Yes. Not right now, but in the past, I have experienced test failure
> >> depending on the network environment I was in. For me, tests passed on
> >> my home network, but not in "managed" networks like at work or in coffee
> >> shops. My working theory is that those networks are configured in ways
> >> that make loopback networking on the *public* IP impossible.
> >>
> >>
> > 1. Adding the hostname (result of hostname on bash shell) to /etc/hosts
> > worked for me. Now the build succeeds on Mac OSX.
> >
> > 2. But still, some tests in reef-io have failed in Ubuntu. Logs from the
> > first failure is as following:
> >
> > Tests run: 8, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 10.67 sec
> >>>> <<< FAILURE! - in
> org.apache.reef.io.network.NetworkConnectionServiceTest
> >>>
> >>>
> testMultithreadedSharedConnMessagingNetworkConnServiceRate(org.apache.reef.io.network.NetworkConnectionServiceTest)
> >>>> Time elapsed: 2.223 sec <<< ERROR!
> >>>
> >>> org.apache.reef.tang.exceptions.InjectionException: Could not invoke
> >>>> constructor: new
> >>>> NetworkConnectionServiceImpl(NetworkConnectionServiceIdFactory =
> >>>> [ClassNodeImpl
> 'org.apache.reef.io.network.util.StringIdentifierFactory']:
> >>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
> >>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
> >>>> Integer NetworkConnectionServicePort = 0, TransportFactory = new
> >>>> MessagingTransportFactory(LocalAddressProvider = [ClassNodeImpl
> >>>>
> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> >>>>
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> >>>>
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> ),
> >>>> NameResolver = new NameClient(String NameResolverNameServerAddr =
> >>>> 127.0.0.1, Integer NameResolverNameServerPort = 13671, Long
> >>>> NameResolverCacheTimeout = 30000, NameResolverIdentifierFactory =
> >>>> [ClassNodeImpl
> 'org.apache.reef.io.network.util.StringIdentifierFactory']:
> >>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
> >>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
> >>>> Integer NameResolverRetryCount = 10, Integer NameResolverRetryTimeout
> =
> >>>> 100, LocalAddressProvider = [ClassNodeImpl
> >>>>
> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> >>>>
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> >>>>
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> ,
> >>>> TransportFactory = new MessagingTransportFactory(LocalAddressProvider
> =
> >>>> [ClassNodeImpl
> >>>>
> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> >>>>
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> >>>>
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> ),
> >>>> new NameLookupClient(String NameResolverNameServerAddr = 127.0.0.1,
> Integer
> >>>> NameResolverNameServerPort = 13671, Long NameResolverCacheTimeout =
> 30000,
> >>>> NameResolverIdentifierFactory = [ClassNodeImpl
> >>>> 'org.apache.reef.io.network.util.StringIdentifierFactory']:
> >>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
> >>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
> >>>> Integer NameResolverRetryCount = 10, Integer NameResolverRetryTimeout
> =
> >>>> 100, LocalAddressProvider = [ClassNodeImpl
> >>>>
> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> >>>>
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> >>>>
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> ,
> >>>> TransportFactory = new MessagingTransportFactory(LocalAddressProvider
> =
> >>>> [ClassNodeImpl
> >>>>
> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
> >>>>
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
> >>>>
> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
> >>>> ))))
> >>>
> >>> at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method)
> >>>
> >>> at sun.nio.ch.EPollArrayWrapper.<init>(EPollArrayWrapper.java:130)
> >>>
> >>> at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:68)
> >>>
> >>> at
> >>>>
> sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36)
> >>>
> >>> at
> io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:126)
> >>>
> >>> at io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:120)
> >>>
> >>> at
> >>>>
> io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:87)
> >>>
> >>> at
> >>>>
> io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:64)
> >>>
> >>> at
> >>>>
> io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:49)
> >>>
> >>> at
> >>>>
> io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:61)
> >>>
> >>> at
> >>>>
> io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:52)
> >>>
> >>> at
> >>>>
> org.apache.reef.wake.remote.transport.netty.NettyMessagingTransport.<init>(NettyMessagingTransport.java:133)
> >>>
> >>> at sun.reflect.GeneratedConstructorAccessor7.newInstance(Unknown
> Source)
> >>>
> >>> at
> >>>>
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> >>>
> >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> >>>
> >>> at
> >>>>
> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:637)
> >>>
> >>> at
> >>>>
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:515)
> >>>
> >>> at
> >>>>
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:533)
> >>>
> >>> at
> >>>>
> org.apache.reef.wake.remote.transport.netty.MessagingTransportFactory.newInstance(MessagingTransportFactory.java:75)
> >>>
> >>> at
> >>>>
> org.apache.reef.io.network.impl.NetworkConnectionServiceImpl.<init>(NetworkConnectionServiceImpl.java:114)
> >>>
> >>> at sun.reflect.GeneratedConstructorAccessor15.newInstance(Unknown
> Source)
> >>>
> >>> at
> >>>>
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> >>>
> >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> >>>
> >>> at
> >>>>
> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:637)
> >>>
> >>> at
> >>>>
> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:661)
> >>>
> >>> at
> >>>>
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:515)
> >>>
> >>> at
> >>>>
> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:533)
> >>>
> >>> at
> >>>>
> org.apache.reef.io.network.util.NetworkMessagingTestService.<init>(NetworkMessagingTestService.java:69)
> >>>
> >>> at
> >>>>
> org.apache.reef.io.network.NetworkConnectionServiceTest.testMultithreadedSharedConnMessagingNetworkConnServiceRate(NetworkConnectionServiceTest.java:290)
> >>>
> >>>
> > Would it have something to do with "[REEF-1124
> > <https://issues.apache.org/jira/browse/REEF-1124>] Remove deprecated
> > constructors of NameLookupClient"? I've found that the build succeeds
> when
> > I check out one commit ahead of REEF-1124. In which case could this
> problem
> > occur?
> >
> >
> >> > 4. I'm working on signing process. Once my key successfully granted
> >> > to the Apache LDAP, I'll create the release branch and try my best
> >> > to finish the release.
> >>
> >> Can you please have your GPG key signed by Gon? That way, it becomes
> >> attached to the Apache Web of Trust and will sign it, too :)
> >>
> >>
> > I've successfully added mine to the Apache (
> > https://people.apache.org/keys/committer/). I'll move to the next steps
> > tomorrow. :)
> >
> >
> >
> >> Thanks,
> >>
> >> Markus
> >>
> >
> >
>
--
Byung-Gon Chun
Re: Should we postpone 0.14 release?
Posted by Yunseong Lee <yu...@gmail.com>.
Hi,
I've created release branch after REEF-1181 (83f905d), and pushed the
commit for rc1. I'll call a vote pretty soon.
>From now on, reviewers please mark '0.15' for "Fix version".
Thanks,
Yunseong
On Tue, Feb 23, 2016 at 3:34 AM, Yunseong Lee <yu...@gmail.com>
wrote:
> Thanks Markus,
> Please check the inline comments.
>
> On Tue, Feb 23, 2016 at 3:26 AM, Markus Weimer <ma...@weimo.de> wrote:
>
>> On 2016-02-22 09:36, Yunseong Lee wrote:
>> > Some tests in REEF-IO have failed sporadically. Strangely, tests
>> > pass in OSX when I turn off WIFI. *Is there anyone suffering the
>> > same problem?*
>>
>> Yes. Not right now, but in the past, I have experienced test failure
>> depending on the network environment I was in. For me, tests passed on
>> my home network, but not in "managed" networks like at work or in coffee
>> shops. My working theory is that those networks are configured in ways
>> that make loopback networking on the *public* IP impossible.
>>
>>
> 1. Adding the hostname (result of hostname on bash shell) to /etc/hosts
> worked for me. Now the build succeeds on Mac OSX.
>
> 2. But still, some tests in reef-io have failed in Ubuntu. Logs from the
> first failure is as following:
>
> Tests run: 8, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 10.67 sec
>>>> <<< FAILURE! - in org.apache.reef.io.network.NetworkConnectionServiceTest
>>>
>>> testMultithreadedSharedConnMessagingNetworkConnServiceRate(org.apache.reef.io.network.NetworkConnectionServiceTest)
>>>> Time elapsed: 2.223 sec <<< ERROR!
>>>
>>> org.apache.reef.tang.exceptions.InjectionException: Could not invoke
>>>> constructor: new
>>>> NetworkConnectionServiceImpl(NetworkConnectionServiceIdFactory =
>>>> [ClassNodeImpl 'org.apache.reef.io.network.util.StringIdentifierFactory']:
>>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
>>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
>>>> Integer NetworkConnectionServicePort = 0, TransportFactory = new
>>>> MessagingTransportFactory(LocalAddressProvider = [ClassNodeImpl
>>>> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
>>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
>>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d),
>>>> NameResolver = new NameClient(String NameResolverNameServerAddr =
>>>> 127.0.0.1, Integer NameResolverNameServerPort = 13671, Long
>>>> NameResolverCacheTimeout = 30000, NameResolverIdentifierFactory =
>>>> [ClassNodeImpl 'org.apache.reef.io.network.util.StringIdentifierFactory']:
>>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
>>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
>>>> Integer NameResolverRetryCount = 10, Integer NameResolverRetryTimeout =
>>>> 100, LocalAddressProvider = [ClassNodeImpl
>>>> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
>>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
>>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d,
>>>> TransportFactory = new MessagingTransportFactory(LocalAddressProvider =
>>>> [ClassNodeImpl
>>>> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
>>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
>>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d),
>>>> new NameLookupClient(String NameResolverNameServerAddr = 127.0.0.1, Integer
>>>> NameResolverNameServerPort = 13671, Long NameResolverCacheTimeout = 30000,
>>>> NameResolverIdentifierFactory = [ClassNodeImpl
>>>> 'org.apache.reef.io.network.util.StringIdentifierFactory']:
>>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
>>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
>>>> Integer NameResolverRetryCount = 10, Integer NameResolverRetryTimeout =
>>>> 100, LocalAddressProvider = [ClassNodeImpl
>>>> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
>>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
>>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d,
>>>> TransportFactory = new MessagingTransportFactory(LocalAddressProvider =
>>>> [ClassNodeImpl
>>>> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
>>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
>>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
>>>> ))))
>>>
>>> at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method)
>>>
>>> at sun.nio.ch.EPollArrayWrapper.<init>(EPollArrayWrapper.java:130)
>>>
>>> at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:68)
>>>
>>> at
>>>> sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36)
>>>
>>> at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:126)
>>>
>>> at io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:120)
>>>
>>> at
>>>> io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:87)
>>>
>>> at
>>>> io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:64)
>>>
>>> at
>>>> io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:49)
>>>
>>> at
>>>> io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:61)
>>>
>>> at
>>>> io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:52)
>>>
>>> at
>>>> org.apache.reef.wake.remote.transport.netty.NettyMessagingTransport.<init>(NettyMessagingTransport.java:133)
>>>
>>> at sun.reflect.GeneratedConstructorAccessor7.newInstance(Unknown Source)
>>>
>>> at
>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>
>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>>>
>>> at
>>>> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:637)
>>>
>>> at
>>>> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:515)
>>>
>>> at
>>>> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:533)
>>>
>>> at
>>>> org.apache.reef.wake.remote.transport.netty.MessagingTransportFactory.newInstance(MessagingTransportFactory.java:75)
>>>
>>> at
>>>> org.apache.reef.io.network.impl.NetworkConnectionServiceImpl.<init>(NetworkConnectionServiceImpl.java:114)
>>>
>>> at sun.reflect.GeneratedConstructorAccessor15.newInstance(Unknown Source)
>>>
>>> at
>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>
>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>>>
>>> at
>>>> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:637)
>>>
>>> at
>>>> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:661)
>>>
>>> at
>>>> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:515)
>>>
>>> at
>>>> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:533)
>>>
>>> at
>>>> org.apache.reef.io.network.util.NetworkMessagingTestService.<init>(NetworkMessagingTestService.java:69)
>>>
>>> at
>>>> org.apache.reef.io.network.NetworkConnectionServiceTest.testMultithreadedSharedConnMessagingNetworkConnServiceRate(NetworkConnectionServiceTest.java:290)
>>>
>>>
> Would it have something to do with "[REEF-1124
> <https://issues.apache.org/jira/browse/REEF-1124>] Remove deprecated
> constructors of NameLookupClient"? I've found that the build succeeds when
> I check out one commit ahead of REEF-1124. In which case could this problem
> occur?
>
>
>> > 4. I'm working on signing process. Once my key successfully granted
>> > to the Apache LDAP, I'll create the release branch and try my best
>> > to finish the release.
>>
>> Can you please have your GPG key signed by Gon? That way, it becomes
>> attached to the Apache Web of Trust and will sign it, too :)
>>
>>
> I've successfully added mine to the Apache (
> https://people.apache.org/keys/committer/). I'll move to the next steps
> tomorrow. :)
>
>
>
>> Thanks,
>>
>> Markus
>>
>
>
Re: Should we postpone 0.14 release?
Posted by Yunseong Lee <yu...@gmail.com>.
Thanks Markus,
Please check the inline comments.
On Tue, Feb 23, 2016 at 3:26 AM, Markus Weimer <ma...@weimo.de> wrote:
> On 2016-02-22 09:36, Yunseong Lee wrote:
> > Some tests in REEF-IO have failed sporadically. Strangely, tests
> > pass in OSX when I turn off WIFI. *Is there anyone suffering the
> > same problem?*
>
> Yes. Not right now, but in the past, I have experienced test failure
> depending on the network environment I was in. For me, tests passed on
> my home network, but not in "managed" networks like at work or in coffee
> shops. My working theory is that those networks are configured in ways
> that make loopback networking on the *public* IP impossible.
>
>
1. Adding the hostname (result of hostname on bash shell) to /etc/hosts
worked for me. Now the build succeeds on Mac OSX.
2. But still, some tests in reef-io have failed in Ubuntu. Logs from the
first failure is as following:
Tests run: 8, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 10.67 sec
>>> <<< FAILURE! - in org.apache.reef.io.network.NetworkConnectionServiceTest
>>
>> testMultithreadedSharedConnMessagingNetworkConnServiceRate(org.apache.reef.io.network.NetworkConnectionServiceTest)
>>> Time elapsed: 2.223 sec <<< ERROR!
>>
>> org.apache.reef.tang.exceptions.InjectionException: Could not invoke
>>> constructor: new
>>> NetworkConnectionServiceImpl(NetworkConnectionServiceIdFactory =
>>> [ClassNodeImpl 'org.apache.reef.io.network.util.StringIdentifierFactory']:
>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
>>> Integer NetworkConnectionServicePort = 0, TransportFactory = new
>>> MessagingTransportFactory(LocalAddressProvider = [ClassNodeImpl
>>> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d),
>>> NameResolver = new NameClient(String NameResolverNameServerAddr =
>>> 127.0.0.1, Integer NameResolverNameServerPort = 13671, Long
>>> NameResolverCacheTimeout = 30000, NameResolverIdentifierFactory =
>>> [ClassNodeImpl 'org.apache.reef.io.network.util.StringIdentifierFactory']:
>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
>>> Integer NameResolverRetryCount = 10, Integer NameResolverRetryTimeout =
>>> 100, LocalAddressProvider = [ClassNodeImpl
>>> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d,
>>> TransportFactory = new MessagingTransportFactory(LocalAddressProvider =
>>> [ClassNodeImpl
>>> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d),
>>> new NameLookupClient(String NameResolverNameServerAddr = 127.0.0.1, Integer
>>> NameResolverNameServerPort = 13671, Long NameResolverCacheTimeout = 30000,
>>> NameResolverIdentifierFactory = [ClassNodeImpl
>>> 'org.apache.reef.io.network.util.StringIdentifierFactory']:
>>> org.apache.reef.io.network.util.StringIdentifierFactory(), =
>>> org.apache.reef.io.network.util.StringIdentifierFactory@37227f8a,
>>> Integer NameResolverRetryCount = 10, Integer NameResolverRetryTimeout =
>>> 100, LocalAddressProvider = [ClassNodeImpl
>>> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d,
>>> TransportFactory = new MessagingTransportFactory(LocalAddressProvider =
>>> [ClassNodeImpl
>>> 'org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider']:
>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider(), =
>>> org.apache.reef.wake.remote.address.HostnameBasedLocalAddressProvider@39e3594d
>>> ))))
>>
>> at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method)
>>
>> at sun.nio.ch.EPollArrayWrapper.<init>(EPollArrayWrapper.java:130)
>>
>> at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:68)
>>
>> at
>>> sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36)
>>
>> at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:126)
>>
>> at io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:120)
>>
>> at
>>> io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:87)
>>
>> at
>>> io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:64)
>>
>> at
>>> io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:49)
>>
>> at
>>> io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:61)
>>
>> at
>>> io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:52)
>>
>> at
>>> org.apache.reef.wake.remote.transport.netty.NettyMessagingTransport.<init>(NettyMessagingTransport.java:133)
>>
>> at sun.reflect.GeneratedConstructorAccessor7.newInstance(Unknown Source)
>>
>> at
>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>>
>> at
>>> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:637)
>>
>> at
>>> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:515)
>>
>> at
>>> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:533)
>>
>> at
>>> org.apache.reef.wake.remote.transport.netty.MessagingTransportFactory.newInstance(MessagingTransportFactory.java:75)
>>
>> at
>>> org.apache.reef.io.network.impl.NetworkConnectionServiceImpl.<init>(NetworkConnectionServiceImpl.java:114)
>>
>> at sun.reflect.GeneratedConstructorAccessor15.newInstance(Unknown Source)
>>
>> at
>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>>
>> at
>>> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:637)
>>
>> at
>>> org.apache.reef.tang.implementation.java.InjectorImpl.injectFromPlan(InjectorImpl.java:661)
>>
>> at
>>> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:515)
>>
>> at
>>> org.apache.reef.tang.implementation.java.InjectorImpl.getInstance(InjectorImpl.java:533)
>>
>> at
>>> org.apache.reef.io.network.util.NetworkMessagingTestService.<init>(NetworkMessagingTestService.java:69)
>>
>> at
>>> org.apache.reef.io.network.NetworkConnectionServiceTest.testMultithreadedSharedConnMessagingNetworkConnServiceRate(NetworkConnectionServiceTest.java:290)
>>
>>
Would it have something to do with "[REEF-1124
<https://issues.apache.org/jira/browse/REEF-1124>] Remove deprecated
constructors of NameLookupClient"? I've found that the build succeeds when
I check out one commit ahead of REEF-1124. In which case could this problem
occur?
> > 4. I'm working on signing process. Once my key successfully granted
> > to the Apache LDAP, I'll create the release branch and try my best
> > to finish the release.
>
> Can you please have your GPG key signed by Gon? That way, it becomes
> attached to the Apache Web of Trust and will sign it, too :)
>
>
I've successfully added mine to the Apache (
https://people.apache.org/keys/committer/). I'll move to the next steps
tomorrow. :)
> Thanks,
>
> Markus
>
Re: Should we postpone 0.14 release?
Posted by Markus Weimer <ma...@weimo.de>.
On 2016-02-22 09:36, Yunseong Lee wrote:
> Some tests in REEF-IO have failed sporadically. Strangely, tests
> pass in OSX when I turn off WIFI. *Is there anyone suffering the
> same problem?*
Yes. Not right now, but in the past, I have experienced test failure
depending on the network environment I was in. For me, tests passed on
my home network, but not in "managed" networks like at work or in coffee
shops. My working theory is that those networks are configured in ways
that make loopback networking on the *public* IP impossible.
> 4. I'm working on signing process. Once my key successfully granted
> to the Apache LDAP, I'll create the release branch and try my best
> to finish the release.
Can you please have your GPG key signed by Gon? That way, it becomes
attached to the Apache Web of Trust and will sign it, too :)
Thanks,
Markus
Re: Should we postpone 0.14 release?
Posted by Markus Weimer <ma...@weimo.de>.
On 2016-02-22 10:06, Boris Shulman wrote:
> Do we have a documentation of the release process?
Yes:
https://cwiki.apache.org/confluence/display/REEF/Release+Manager+Guide
Markus
Re: Should we postpone 0.14 release?
Posted by Yunseong Lee <yu...@gmail.com>.
Hi,
Heres are updates regarding 0.14:
1.
As we merged REEF-1040, which had been the last blocker for 0.14, we're now
good to proceed. Thanks Geon-Woo for fixing it, and thanks Andrew for
careful review and merge!
2.
I've tried to build the Java side at the current master (HEAD: [0]), but
the tests seems to be a bit flaky; I'm testing on my Mac OSX El Capitan and
a Ubuntu14.04 desktop. Some tests in REEF-IO have failed sporadically.
Strangely, tests pass in OSX when I turn off WIFI. *Is there anyone
suffering the same problem?*
3.
I think it is not critical to block the release, because at least the CI
still works correctly. Some people might lose the opportunity to check
whether the build is successful though.
4.
I'm working on signing process. Once my key successfully granted to the
Apache LDAP, I'll create the release branch and try my best to finish the
release.
Thanks,
Yunseong
[0] 7495f78, [REEF-1040] Fix a bug in WatcherTest
On Sat, Feb 20, 2016 at 3:50 PM, Brian Cho <ch...@gmail.com> wrote:
> Thanks Yunseong and Boris :)-Brian
>
> Sent from Outlook Mobile
>
>
>
>
> On Fri, Feb 19, 2016 at 7:18 PM -0800, "Markus Weimer" <ma...@weimo.de>
> wrote:
>
>
>
>
>
>
>
>
>
>
> +1
>
> Thanks, Boris!
>
> Typed on glass with my thumbs. so please excuse brvt and typso.
> On Feb 19, 2016 18:57, "Yunseong Lee" wrote:
>
> > Thanks everyone for the thoughtful comments! I agree with you all.
> >
> > Let's stick to the original schedule (REEF-1040 seems to be merged in
> > hours!) for 0.14 release.
> >
> > Also, thanks Boris for volunteering the next release manager!!
> >
> > Regards,
> > Yunseong
> >
> >
> > On Sat, Feb 20, 2016 at 11:52 AM, Byung-Gon Chun wrote:
> >
> > > Sounds good to me. Thanks.
> > >
> > >
> > > On Sat, Feb 20, 2016 at 11:50 AM, Boris Shulman
> > > wrote:
> > >
> > > > Sure, will do that. So I assume we all agree that we will target
> 0.15 ~
> > > two
> > > > weeks after 0.14 and it will be mostly driven by the multi-runtime
> > > feature.
> > > >
> > > > Boris.
> > > >
> > > > On Fri, Feb 19, 2016 at 6:45 PM, Markus Weimer
> > wrote:
> > > >
> > > > > That sounds like we have a volunteer for the release manager of
> 0.15
> > :)
> > > > >
> > > > > Markus
> > > > >
> > > > > On Fri, Feb 19, 2016 at 6:41 PM, Boris Shulman
> > > > wrote:
> > > > > > I agree not to postpone 0.14 but lets target next release it 2-3
> > > weeks.
> > > > > I don't mind if we do 0.15 or a minor release.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: "Byung-Gon Chun"
> > > > > > Sent: 2/19/2016 6:23 PM
> > > > > > To: "dev@reef.apache.org"
> > > > > > Subject: Re: Should we postpone 0.14 release?
> > > > > >
> > > > > > I agree with Markus and Julia.
> > > > > > Let's not postpone this release.
> > > > > >
> > > > > >
> > > > > > On Sat, Feb 20, 2016 at 11:03 AM, Julia Wang (QIUHE) <
> > > > > > Qiuhe.Wang@microsoft.com> wrote:
> > > > > >
> > > > > >> I agree. For test failure, we have to postpone. For feature, it
> > can
> > > > > always
> > > > > >> catch next train if our release frequency is reasonable and the
> > > > feature
> > > > > is
> > > > > >> not that critical.
> > > > > >>
> > > > > >> I believe we have resolved test failure about
> > > > > >> CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
> > > > > >>
> > > > > >> Julia
> > > > > >>
> > > > > >> -----Original Message-----
> > > > > >> From: Markus Weimer [mailto:markus@weimo.de]
> > > > > >> Sent: Friday, February 19, 2016 5:58 PM
> > > > > >> To: dev@reef.apache.org
> > > > > >> Subject: Re: Should we postpone 0.14 release?
> > > > > >>
> > > > > >> Hi,
> > > > > >>
> > > > > >> I'm against postponing releases. It just turns into a
> never-ending
> > > > story
> > > > > >> of postponements. Each release (even minor ones) have the same
> > > effort
> > > > > for
> > > > > >> us. Given that this one would be driven by a new feature, why
> not
> > > aim
> > > > > for a
> > > > > >> quick turnaround to 0.15? That way, we could also remove a lot
> of
> > > code
> > > > > we
> > > > > >> recently deprecated soon as well.
> > > > > >>
> > > > > >> Markus
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Byung-Gon Chun
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Byung-Gon Chun
> > >
> >
>
>
>
>
>
>
Re: Should we postpone 0.14 release?
Posted by Boris Shulman <sh...@gmail.com>.
Thanks Mariia
Do we have a documentation of the release process?
Boris.
On Mon, Feb 22, 2016 at 9:32 AM, Mariia Mykhailova <ma...@microsoft.com>
wrote:
> I've filed REEF-1215 to serve as umbrella JIRA for release 0.15. Boris,
> feel free to assign it to yourself, and thanks for volunteering :-)
>
> -Mariia
>
> -----Original Message-----
> From: Brian Cho [mailto:chobrian@gmail.com]
> Sent: Friday, February 19, 2016 10:51 PM
> To: dev@reef.apache.org
> Subject: Re: Should we postpone 0.14 release?
>
> Thanks Yunseong and Boris :)-Brian
>
> Sent from Outlook Mobile
>
>
>
>
> On Fri, Feb 19, 2016 at 7:18 PM -0800, "Markus Weimer" <ma...@weimo.de>
> wrote:
>
> +1
>
> Thanks, Boris!
>
> Typed on glass with my thumbs. so please excuse brvt and typso.
> On Feb 19, 2016 18:57, "Yunseong Lee" wrote:
>
> > Thanks everyone for the thoughtful comments! I agree with you all.
> >
> > Let's stick to the original schedule (REEF-1040 seems to be merged in
> > hours!) for 0.14 release.
> >
> > Also, thanks Boris for volunteering the next release manager!!
> >
> > Regards,
> > Yunseong
> >
> >
> > On Sat, Feb 20, 2016 at 11:52 AM, Byung-Gon Chun wrote:
> >
> > > Sounds good to me. Thanks.
> > >
> > >
> > > On Sat, Feb 20, 2016 at 11:50 AM, Boris Shulman
> > > wrote:
> > >
> > > > Sure, will do that. So I assume we all agree that we will target
> > > > 0.15 ~
> > > two
> > > > weeks after 0.14 and it will be mostly driven by the multi-runtime
> > > feature.
> > > >
> > > > Boris.
> > > >
> > > > On Fri, Feb 19, 2016 at 6:45 PM, Markus Weimer
> > wrote:
> > > >
> > > > > That sounds like we have a volunteer for the release manager of
> > > > > 0.15
> > :)
> > > > >
> > > > > Markus
> > > > >
> > > > > On Fri, Feb 19, 2016 at 6:41 PM, Boris Shulman
> > > > wrote:
> > > > > > I agree not to postpone 0.14 but lets target next release it
> > > > > > 2-3
> > > weeks.
> > > > > I don't mind if we do 0.15 or a minor release.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: "Byung-Gon Chun"
> > > > > > Sent: 2/19/2016 6:23 PM
> > > > > > To: "dev@reef.apache.org"
> > > > > > Subject: Re: Should we postpone 0.14 release?
> > > > > >
> > > > > > I agree with Markus and Julia.
> > > > > > Let's not postpone this release.
> > > > > >
> > > > > >
> > > > > > On Sat, Feb 20, 2016 at 11:03 AM, Julia Wang (QIUHE) <
> > > > > > Qiuhe.Wang@microsoft.com> wrote:
> > > > > >
> > > > > >> I agree. For test failure, we have to postpone. For feature,
> > > > > >> it
> > can
> > > > > always
> > > > > >> catch next train if our release frequency is reasonable and
> > > > > >> the
> > > > feature
> > > > > is
> > > > > >> not that critical.
> > > > > >>
> > > > > >> I believe we have resolved test failure about
> > > > > >> CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
> > > > > >>
> > > > > >> Julia
> > > > > >>
> > > > > >> -----Original Message-----
> > > > > >> From: Markus Weimer [mailto:markus@weimo.de]
> > > > > >> Sent: Friday, February 19, 2016 5:58 PM
> > > > > >> To: dev@reef.apache.org
> > > > > >> Subject: Re: Should we postpone 0.14 release?
> > > > > >>
> > > > > >> Hi,
> > > > > >>
> > > > > >> I'm against postponing releases. It just turns into a
> > > > > >> never-ending
> > > > story
> > > > > >> of postponements. Each release (even minor ones) have the
> > > > > >> same
> > > effort
> > > > > for
> > > > > >> us. Given that this one would be driven by a new feature, why
> > > > > >> not
> > > aim
> > > > > for a
> > > > > >> quick turnaround to 0.15? That way, we could also remove a
> > > > > >> lot of
> > > code
> > > > > we
> > > > > >> recently deprecated soon as well.
> > > > > >>
> > > > > >> Markus
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Byung-Gon Chun
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Byung-Gon Chun
> > >
> >
>
>
>
>
>
>
RE: Should we postpone 0.14 release?
Posted by Mariia Mykhailova <ma...@microsoft.com>.
I've filed REEF-1215 to serve as umbrella JIRA for release 0.15. Boris, feel free to assign it to yourself, and thanks for volunteering :-)
-Mariia
-----Original Message-----
From: Brian Cho [mailto:chobrian@gmail.com]
Sent: Friday, February 19, 2016 10:51 PM
To: dev@reef.apache.org
Subject: Re: Should we postpone 0.14 release?
Thanks Yunseong and Boris :)-Brian
Sent from Outlook Mobile
On Fri, Feb 19, 2016 at 7:18 PM -0800, "Markus Weimer" <ma...@weimo.de> wrote:
+1
Thanks, Boris!
Typed on glass with my thumbs. so please excuse brvt and typso.
On Feb 19, 2016 18:57, "Yunseong Lee" wrote:
> Thanks everyone for the thoughtful comments! I agree with you all.
>
> Let's stick to the original schedule (REEF-1040 seems to be merged in
> hours!) for 0.14 release.
>
> Also, thanks Boris for volunteering the next release manager!!
>
> Regards,
> Yunseong
>
>
> On Sat, Feb 20, 2016 at 11:52 AM, Byung-Gon Chun wrote:
>
> > Sounds good to me. Thanks.
> >
> >
> > On Sat, Feb 20, 2016 at 11:50 AM, Boris Shulman
> > wrote:
> >
> > > Sure, will do that. So I assume we all agree that we will target
> > > 0.15 ~
> > two
> > > weeks after 0.14 and it will be mostly driven by the multi-runtime
> > feature.
> > >
> > > Boris.
> > >
> > > On Fri, Feb 19, 2016 at 6:45 PM, Markus Weimer
> wrote:
> > >
> > > > That sounds like we have a volunteer for the release manager of
> > > > 0.15
> :)
> > > >
> > > > Markus
> > > >
> > > > On Fri, Feb 19, 2016 at 6:41 PM, Boris Shulman
> > > wrote:
> > > > > I agree not to postpone 0.14 but lets target next release it
> > > > > 2-3
> > weeks.
> > > > I don't mind if we do 0.15 or a minor release.
> > > > >
> > > > > -----Original Message-----
> > > > > From: "Byung-Gon Chun"
> > > > > Sent: 2/19/2016 6:23 PM
> > > > > To: "dev@reef.apache.org"
> > > > > Subject: Re: Should we postpone 0.14 release?
> > > > >
> > > > > I agree with Markus and Julia.
> > > > > Let's not postpone this release.
> > > > >
> > > > >
> > > > > On Sat, Feb 20, 2016 at 11:03 AM, Julia Wang (QIUHE) <
> > > > > Qiuhe.Wang@microsoft.com> wrote:
> > > > >
> > > > >> I agree. For test failure, we have to postpone. For feature,
> > > > >> it
> can
> > > > always
> > > > >> catch next train if our release frequency is reasonable and
> > > > >> the
> > > feature
> > > > is
> > > > >> not that critical.
> > > > >>
> > > > >> I believe we have resolved test failure about
> > > > >> CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
> > > > >>
> > > > >> Julia
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Markus Weimer [mailto:markus@weimo.de]
> > > > >> Sent: Friday, February 19, 2016 5:58 PM
> > > > >> To: dev@reef.apache.org
> > > > >> Subject: Re: Should we postpone 0.14 release?
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I'm against postponing releases. It just turns into a
> > > > >> never-ending
> > > story
> > > > >> of postponements. Each release (even minor ones) have the
> > > > >> same
> > effort
> > > > for
> > > > >> us. Given that this one would be driven by a new feature, why
> > > > >> not
> > aim
> > > > for a
> > > > >> quick turnaround to 0.15? That way, we could also remove a
> > > > >> lot of
> > code
> > > > we
> > > > >> recently deprecated soon as well.
> > > > >>
> > > > >> Markus
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Byung-Gon Chun
> > > >
> > >
> >
> >
> >
> > --
> > Byung-Gon Chun
> >
>
Re: Should we postpone 0.14 release?
Posted by Brian Cho <ch...@gmail.com>.
Thanks Yunseong and Boris :)-Brian
Sent from Outlook Mobile
On Fri, Feb 19, 2016 at 7:18 PM -0800, "Markus Weimer" <ma...@weimo.de> wrote:
+1
Thanks, Boris!
Typed on glass with my thumbs. so please excuse brvt and typso.
On Feb 19, 2016 18:57, "Yunseong Lee" wrote:
> Thanks everyone for the thoughtful comments! I agree with you all.
>
> Let's stick to the original schedule (REEF-1040 seems to be merged in
> hours!) for 0.14 release.
>
> Also, thanks Boris for volunteering the next release manager!!
>
> Regards,
> Yunseong
>
>
> On Sat, Feb 20, 2016 at 11:52 AM, Byung-Gon Chun wrote:
>
> > Sounds good to me. Thanks.
> >
> >
> > On Sat, Feb 20, 2016 at 11:50 AM, Boris Shulman
> > wrote:
> >
> > > Sure, will do that. So I assume we all agree that we will target 0.15 ~
> > two
> > > weeks after 0.14 and it will be mostly driven by the multi-runtime
> > feature.
> > >
> > > Boris.
> > >
> > > On Fri, Feb 19, 2016 at 6:45 PM, Markus Weimer
> wrote:
> > >
> > > > That sounds like we have a volunteer for the release manager of 0.15
> :)
> > > >
> > > > Markus
> > > >
> > > > On Fri, Feb 19, 2016 at 6:41 PM, Boris Shulman
> > > wrote:
> > > > > I agree not to postpone 0.14 but lets target next release it 2-3
> > weeks.
> > > > I don't mind if we do 0.15 or a minor release.
> > > > >
> > > > > -----Original Message-----
> > > > > From: "Byung-Gon Chun"
> > > > > Sent: 2/19/2016 6:23 PM
> > > > > To: "dev@reef.apache.org"
> > > > > Subject: Re: Should we postpone 0.14 release?
> > > > >
> > > > > I agree with Markus and Julia.
> > > > > Let's not postpone this release.
> > > > >
> > > > >
> > > > > On Sat, Feb 20, 2016 at 11:03 AM, Julia Wang (QIUHE) <
> > > > > Qiuhe.Wang@microsoft.com> wrote:
> > > > >
> > > > >> I agree. For test failure, we have to postpone. For feature, it
> can
> > > > always
> > > > >> catch next train if our release frequency is reasonable and the
> > > feature
> > > > is
> > > > >> not that critical.
> > > > >>
> > > > >> I believe we have resolved test failure about
> > > > >> CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
> > > > >>
> > > > >> Julia
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Markus Weimer [mailto:markus@weimo.de]
> > > > >> Sent: Friday, February 19, 2016 5:58 PM
> > > > >> To: dev@reef.apache.org
> > > > >> Subject: Re: Should we postpone 0.14 release?
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I'm against postponing releases. It just turns into a never-ending
> > > story
> > > > >> of postponements. Each release (even minor ones) have the same
> > effort
> > > > for
> > > > >> us. Given that this one would be driven by a new feature, why not
> > aim
> > > > for a
> > > > >> quick turnaround to 0.15? That way, we could also remove a lot of
> > code
> > > > we
> > > > >> recently deprecated soon as well.
> > > > >>
> > > > >> Markus
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Byung-Gon Chun
> > > >
> > >
> >
> >
> >
> > --
> > Byung-Gon Chun
> >
>
Re: Should we postpone 0.14 release?
Posted by Markus Weimer <ma...@weimo.de>.
+1
Thanks, Boris!
Typed on glass with my thumbs. so please excuse brvt and typso.
On Feb 19, 2016 18:57, "Yunseong Lee" <yu...@gmail.com> wrote:
> Thanks everyone for the thoughtful comments! I agree with you all.
>
> Let's stick to the original schedule (REEF-1040 seems to be merged in
> hours!) for 0.14 release.
>
> Also, thanks Boris for volunteering the next release manager!!
>
> Regards,
> Yunseong
>
>
> On Sat, Feb 20, 2016 at 11:52 AM, Byung-Gon Chun <bg...@gmail.com> wrote:
>
> > Sounds good to me. Thanks.
> >
> >
> > On Sat, Feb 20, 2016 at 11:50 AM, Boris Shulman <sh...@gmail.com>
> > wrote:
> >
> > > Sure, will do that. So I assume we all agree that we will target 0.15 ~
> > two
> > > weeks after 0.14 and it will be mostly driven by the multi-runtime
> > feature.
> > >
> > > Boris.
> > >
> > > On Fri, Feb 19, 2016 at 6:45 PM, Markus Weimer <ma...@weimo.de>
> wrote:
> > >
> > > > That sounds like we have a volunteer for the release manager of 0.15
> :)
> > > >
> > > > Markus
> > > >
> > > > On Fri, Feb 19, 2016 at 6:41 PM, Boris Shulman <sh...@gmail.com>
> > > wrote:
> > > > > I agree not to postpone 0.14 but lets target next release it 2-3
> > weeks.
> > > > I don't mind if we do 0.15 or a minor release.
> > > > >
> > > > > -----Original Message-----
> > > > > From: "Byung-Gon Chun" <bg...@gmail.com>
> > > > > Sent: 2/19/2016 6:23 PM
> > > > > To: "dev@reef.apache.org" <de...@reef.apache.org>
> > > > > Subject: Re: Should we postpone 0.14 release?
> > > > >
> > > > > I agree with Markus and Julia.
> > > > > Let's not postpone this release.
> > > > >
> > > > >
> > > > > On Sat, Feb 20, 2016 at 11:03 AM, Julia Wang (QIUHE) <
> > > > > Qiuhe.Wang@microsoft.com> wrote:
> > > > >
> > > > >> I agree. For test failure, we have to postpone. For feature, it
> can
> > > > always
> > > > >> catch next train if our release frequency is reasonable and the
> > > feature
> > > > is
> > > > >> not that critical.
> > > > >>
> > > > >> I believe we have resolved test failure about
> > > > >> CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
> > > > >>
> > > > >> Julia
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Markus Weimer [mailto:markus@weimo.de]
> > > > >> Sent: Friday, February 19, 2016 5:58 PM
> > > > >> To: dev@reef.apache.org
> > > > >> Subject: Re: Should we postpone 0.14 release?
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I'm against postponing releases. It just turns into a never-ending
> > > story
> > > > >> of postponements. Each release (even minor ones) have the same
> > effort
> > > > for
> > > > >> us. Given that this one would be driven by a new feature, why not
> > aim
> > > > for a
> > > > >> quick turnaround to 0.15? That way, we could also remove a lot of
> > code
> > > > we
> > > > >> recently deprecated soon as well.
> > > > >>
> > > > >> Markus
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Byung-Gon Chun
> > > >
> > >
> >
> >
> >
> > --
> > Byung-Gon Chun
> >
>
Re: Should we postpone 0.14 release?
Posted by Yunseong Lee <yu...@gmail.com>.
Thanks everyone for the thoughtful comments! I agree with you all.
Let's stick to the original schedule (REEF-1040 seems to be merged in
hours!) for 0.14 release.
Also, thanks Boris for volunteering the next release manager!!
Regards,
Yunseong
On Sat, Feb 20, 2016 at 11:52 AM, Byung-Gon Chun <bg...@gmail.com> wrote:
> Sounds good to me. Thanks.
>
>
> On Sat, Feb 20, 2016 at 11:50 AM, Boris Shulman <sh...@gmail.com>
> wrote:
>
> > Sure, will do that. So I assume we all agree that we will target 0.15 ~
> two
> > weeks after 0.14 and it will be mostly driven by the multi-runtime
> feature.
> >
> > Boris.
> >
> > On Fri, Feb 19, 2016 at 6:45 PM, Markus Weimer <ma...@weimo.de> wrote:
> >
> > > That sounds like we have a volunteer for the release manager of 0.15 :)
> > >
> > > Markus
> > >
> > > On Fri, Feb 19, 2016 at 6:41 PM, Boris Shulman <sh...@gmail.com>
> > wrote:
> > > > I agree not to postpone 0.14 but lets target next release it 2-3
> weeks.
> > > I don't mind if we do 0.15 or a minor release.
> > > >
> > > > -----Original Message-----
> > > > From: "Byung-Gon Chun" <bg...@gmail.com>
> > > > Sent: 2/19/2016 6:23 PM
> > > > To: "dev@reef.apache.org" <de...@reef.apache.org>
> > > > Subject: Re: Should we postpone 0.14 release?
> > > >
> > > > I agree with Markus and Julia.
> > > > Let's not postpone this release.
> > > >
> > > >
> > > > On Sat, Feb 20, 2016 at 11:03 AM, Julia Wang (QIUHE) <
> > > > Qiuhe.Wang@microsoft.com> wrote:
> > > >
> > > >> I agree. For test failure, we have to postpone. For feature, it can
> > > always
> > > >> catch next train if our release frequency is reasonable and the
> > feature
> > > is
> > > >> not that critical.
> > > >>
> > > >> I believe we have resolved test failure about
> > > >> CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
> > > >>
> > > >> Julia
> > > >>
> > > >> -----Original Message-----
> > > >> From: Markus Weimer [mailto:markus@weimo.de]
> > > >> Sent: Friday, February 19, 2016 5:58 PM
> > > >> To: dev@reef.apache.org
> > > >> Subject: Re: Should we postpone 0.14 release?
> > > >>
> > > >> Hi,
> > > >>
> > > >> I'm against postponing releases. It just turns into a never-ending
> > story
> > > >> of postponements. Each release (even minor ones) have the same
> effort
> > > for
> > > >> us. Given that this one would be driven by a new feature, why not
> aim
> > > for a
> > > >> quick turnaround to 0.15? That way, we could also remove a lot of
> code
> > > we
> > > >> recently deprecated soon as well.
> > > >>
> > > >> Markus
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Byung-Gon Chun
> > >
> >
>
>
>
> --
> Byung-Gon Chun
>
Re: Should we postpone 0.14 release?
Posted by Byung-Gon Chun <bg...@gmail.com>.
Sounds good to me. Thanks.
On Sat, Feb 20, 2016 at 11:50 AM, Boris Shulman <sh...@gmail.com> wrote:
> Sure, will do that. So I assume we all agree that we will target 0.15 ~ two
> weeks after 0.14 and it will be mostly driven by the multi-runtime feature.
>
> Boris.
>
> On Fri, Feb 19, 2016 at 6:45 PM, Markus Weimer <ma...@weimo.de> wrote:
>
> > That sounds like we have a volunteer for the release manager of 0.15 :)
> >
> > Markus
> >
> > On Fri, Feb 19, 2016 at 6:41 PM, Boris Shulman <sh...@gmail.com>
> wrote:
> > > I agree not to postpone 0.14 but lets target next release it 2-3 weeks.
> > I don't mind if we do 0.15 or a minor release.
> > >
> > > -----Original Message-----
> > > From: "Byung-Gon Chun" <bg...@gmail.com>
> > > Sent: 2/19/2016 6:23 PM
> > > To: "dev@reef.apache.org" <de...@reef.apache.org>
> > > Subject: Re: Should we postpone 0.14 release?
> > >
> > > I agree with Markus and Julia.
> > > Let's not postpone this release.
> > >
> > >
> > > On Sat, Feb 20, 2016 at 11:03 AM, Julia Wang (QIUHE) <
> > > Qiuhe.Wang@microsoft.com> wrote:
> > >
> > >> I agree. For test failure, we have to postpone. For feature, it can
> > always
> > >> catch next train if our release frequency is reasonable and the
> feature
> > is
> > >> not that critical.
> > >>
> > >> I believe we have resolved test failure about
> > >> CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
> > >>
> > >> Julia
> > >>
> > >> -----Original Message-----
> > >> From: Markus Weimer [mailto:markus@weimo.de]
> > >> Sent: Friday, February 19, 2016 5:58 PM
> > >> To: dev@reef.apache.org
> > >> Subject: Re: Should we postpone 0.14 release?
> > >>
> > >> Hi,
> > >>
> > >> I'm against postponing releases. It just turns into a never-ending
> story
> > >> of postponements. Each release (even minor ones) have the same effort
> > for
> > >> us. Given that this one would be driven by a new feature, why not aim
> > for a
> > >> quick turnaround to 0.15? That way, we could also remove a lot of code
> > we
> > >> recently deprecated soon as well.
> > >>
> > >> Markus
> > >>
> > >
> > >
> > >
> > > --
> > > Byung-Gon Chun
> >
>
--
Byung-Gon Chun
Re: Should we postpone 0.14 release?
Posted by Boris Shulman <sh...@gmail.com>.
Sure, will do that. So I assume we all agree that we will target 0.15 ~ two
weeks after 0.14 and it will be mostly driven by the multi-runtime feature.
Boris.
On Fri, Feb 19, 2016 at 6:45 PM, Markus Weimer <ma...@weimo.de> wrote:
> That sounds like we have a volunteer for the release manager of 0.15 :)
>
> Markus
>
> On Fri, Feb 19, 2016 at 6:41 PM, Boris Shulman <sh...@gmail.com> wrote:
> > I agree not to postpone 0.14 but lets target next release it 2-3 weeks.
> I don't mind if we do 0.15 or a minor release.
> >
> > -----Original Message-----
> > From: "Byung-Gon Chun" <bg...@gmail.com>
> > Sent: 2/19/2016 6:23 PM
> > To: "dev@reef.apache.org" <de...@reef.apache.org>
> > Subject: Re: Should we postpone 0.14 release?
> >
> > I agree with Markus and Julia.
> > Let's not postpone this release.
> >
> >
> > On Sat, Feb 20, 2016 at 11:03 AM, Julia Wang (QIUHE) <
> > Qiuhe.Wang@microsoft.com> wrote:
> >
> >> I agree. For test failure, we have to postpone. For feature, it can
> always
> >> catch next train if our release frequency is reasonable and the feature
> is
> >> not that critical.
> >>
> >> I believe we have resolved test failure about
> >> CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
> >>
> >> Julia
> >>
> >> -----Original Message-----
> >> From: Markus Weimer [mailto:markus@weimo.de]
> >> Sent: Friday, February 19, 2016 5:58 PM
> >> To: dev@reef.apache.org
> >> Subject: Re: Should we postpone 0.14 release?
> >>
> >> Hi,
> >>
> >> I'm against postponing releases. It just turns into a never-ending story
> >> of postponements. Each release (even minor ones) have the same effort
> for
> >> us. Given that this one would be driven by a new feature, why not aim
> for a
> >> quick turnaround to 0.15? That way, we could also remove a lot of code
> we
> >> recently deprecated soon as well.
> >>
> >> Markus
> >>
> >
> >
> >
> > --
> > Byung-Gon Chun
>
Re: Should we postpone 0.14 release?
Posted by Markus Weimer <ma...@weimo.de>.
That sounds like we have a volunteer for the release manager of 0.15 :)
Markus
On Fri, Feb 19, 2016 at 6:41 PM, Boris Shulman <sh...@gmail.com> wrote:
> I agree not to postpone 0.14 but lets target next release it 2-3 weeks. I don't mind if we do 0.15 or a minor release.
>
> -----Original Message-----
> From: "Byung-Gon Chun" <bg...@gmail.com>
> Sent: 2/19/2016 6:23 PM
> To: "dev@reef.apache.org" <de...@reef.apache.org>
> Subject: Re: Should we postpone 0.14 release?
>
> I agree with Markus and Julia.
> Let's not postpone this release.
>
>
> On Sat, Feb 20, 2016 at 11:03 AM, Julia Wang (QIUHE) <
> Qiuhe.Wang@microsoft.com> wrote:
>
>> I agree. For test failure, we have to postpone. For feature, it can always
>> catch next train if our release frequency is reasonable and the feature is
>> not that critical.
>>
>> I believe we have resolved test failure about
>> CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
>>
>> Julia
>>
>> -----Original Message-----
>> From: Markus Weimer [mailto:markus@weimo.de]
>> Sent: Friday, February 19, 2016 5:58 PM
>> To: dev@reef.apache.org
>> Subject: Re: Should we postpone 0.14 release?
>>
>> Hi,
>>
>> I'm against postponing releases. It just turns into a never-ending story
>> of postponements. Each release (even minor ones) have the same effort for
>> us. Given that this one would be driven by a new feature, why not aim for a
>> quick turnaround to 0.15? That way, we could also remove a lot of code we
>> recently deprecated soon as well.
>>
>> Markus
>>
>
>
>
> --
> Byung-Gon Chun
RE: Should we postpone 0.14 release?
Posted by Boris Shulman <sh...@gmail.com>.
I agree not to postpone 0.14 but lets target next release it 2-3 weeks. I don't mind if we do 0.15 or a minor release.
-----Original Message-----
From: "Byung-Gon Chun" <bg...@gmail.com>
Sent: 2/19/2016 6:23 PM
To: "dev@reef.apache.org" <de...@reef.apache.org>
Subject: Re: Should we postpone 0.14 release?
I agree with Markus and Julia.
Let's not postpone this release.
On Sat, Feb 20, 2016 at 11:03 AM, Julia Wang (QIUHE) <
Qiuhe.Wang@microsoft.com> wrote:
> I agree. For test failure, we have to postpone. For feature, it can always
> catch next train if our release frequency is reasonable and the feature is
> not that critical.
>
> I believe we have resolved test failure about
> CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
>
> Julia
>
> -----Original Message-----
> From: Markus Weimer [mailto:markus@weimo.de]
> Sent: Friday, February 19, 2016 5:58 PM
> To: dev@reef.apache.org
> Subject: Re: Should we postpone 0.14 release?
>
> Hi,
>
> I'm against postponing releases. It just turns into a never-ending story
> of postponements. Each release (even minor ones) have the same effort for
> us. Given that this one would be driven by a new feature, why not aim for a
> quick turnaround to 0.15? That way, we could also remove a lot of code we
> recently deprecated soon as well.
>
> Markus
>
--
Byung-Gon Chun
Re: Should we postpone 0.14 release?
Posted by Byung-Gon Chun <bg...@gmail.com>.
I agree with Markus and Julia.
Let's not postpone this release.
On Sat, Feb 20, 2016 at 11:03 AM, Julia Wang (QIUHE) <
Qiuhe.Wang@microsoft.com> wrote:
> I agree. For test failure, we have to postpone. For feature, it can always
> catch next train if our release frequency is reasonable and the feature is
> not that critical.
>
> I believe we have resolved test failure about
> CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
>
> Julia
>
> -----Original Message-----
> From: Markus Weimer [mailto:markus@weimo.de]
> Sent: Friday, February 19, 2016 5:58 PM
> To: dev@reef.apache.org
> Subject: Re: Should we postpone 0.14 release?
>
> Hi,
>
> I'm against postponing releases. It just turns into a never-ending story
> of postponements. Each release (even minor ones) have the same effort for
> us. Given that this one would be driven by a new feature, why not aim for a
> quick turnaround to 0.15? That way, we could also remove a lot of code we
> recently deprecated soon as well.
>
> Markus
>
--
Byung-Gon Chun
RE: Should we postpone 0.14 release?
Posted by "Julia Wang (QIUHE)" <Qi...@microsoft.com>.
I agree. For test failure, we have to postpone. For feature, it can always catch next train if our release frequency is reasonable and the feature is not that critical.
I believe we have resolved test failure about CanRunClrBridgeExampleOnLocalRuntime which is a E2E test.
Julia
-----Original Message-----
From: Markus Weimer [mailto:markus@weimo.de]
Sent: Friday, February 19, 2016 5:58 PM
To: dev@reef.apache.org
Subject: Re: Should we postpone 0.14 release?
Hi,
I'm against postponing releases. It just turns into a never-ending story of postponements. Each release (even minor ones) have the same effort for us. Given that this one would be driven by a new feature, why not aim for a quick turnaround to 0.15? That way, we could also remove a lot of code we recently deprecated soon as well.
Markus
Re: Should we postpone 0.14 release?
Posted by Markus Weimer <ma...@weimo.de>.
Hi,
I'm against postponing releases. It just turns into a never-ending
story of postponements. Each release (even minor ones) have the same
effort for us. Given that this one would be driven by a new feature,
why not aim for a quick turnaround to 0.15? That way, we could also
remove a lot of code we recently deprecated soon as well.
Markus
Re: Should we postpone 0.14 release?
Posted by Yunseong Lee <yu...@gmail.com>.
Hi Boris,
thanks for the input.
AFAIK, we have never discussed minor releases (e.g., 0.x.y). I'm fine with
it, but I think we need to hear others' thoughts from the community first.
When are you expecting the feature to be implemented? If it can be done
very quickly, should we postpone the release one more time?
Regards,
Yunseong
On Sat, Feb 20, 2016 at 4:36 AM, Boris Shulman <sh...@gmail.com> wrote:
> Will we be able to create another release right after that, maybe 0.14.1? I
> will need the multi-runtime released as soon as it is ready, and it is in
> PR now (and I will need few more PRs).
>
> Boris.
>
> On Wed, Feb 17, 2016 at 8:19 PM, Byung-Gon Chun <bg...@gmail.com> wrote:
>
> > Thanks for the update, Yunseong.
> >
> > This sounds good to me.
> >
> > -Gon
> >
> >
> > On Wed, Feb 17, 2016 at 7:28 PM, Yunseong Lee <yu...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Sorry for making you wait long, and thanks a lot for your patience to
> > wait
> > > our release :-)
> > >
> > > Here are some updates:
> > > 1) Blockers regarding .Net tests have been resolved.
> > > 2) Another blocker, *WatcherTest*, seems to be resolved very soon.
> > Geon-Woo
> > > has figured out the main cause of the sporadic failure, and has some
> idea
> > > to fix it. The problem & solution is simple, but a bit debatable. He'll
> > > share the findings and possible solutions soon.
> > > 3) As there has been no response from other issues on the list above, I
> > > think the items can be moved to the next release.
> > >
> > > So, I'm tentatively planning to set the new release cut-off about *end
> of
> > > this week*, opportunistically hoping that 2) is resolved until then.
> > >
> > >
> > > Does anybody have comment or suggestion?
> > >
> > > Thanks,
> > > Yunseong
> > >
> > >
> > > On Sat, Feb 6, 2016 at 10:09 AM, Yunseong Lee <yunseong.lee0@gmail.com
> >
> > > wrote:
> > >
> > > > Sure! Thanks for the great suggestion, Markus!
> > > >
> > > > Currently we have 11 blockers for releasing 0.14. I classified them
> > into
> > > 4
> > > > categories:
> > > >
> > > > 1. Should be fixed; we can release 0.14 only after resolving those.
> > > > a) [REEF-1040 <https://issues.apache.org/jira/browse/REEF-1040>]
> > Fix a
> > > > bug in WatcherTest
> > > > b) [REEF-1185 <https://issues.apache.org/jira/browse/REEF-1185>]
> Fix
> > > > CanRunClrBridgeExampleOnLocalRuntime test
> > > >
> > > > 2. Will be closed soon. Only minor changes are left.
> > > > a) [REEF-974 <https://issues.apache.org/jira/browse/REEF-974>]
> > > > Post-Graduation work
> > > > b) [REEF-1163 <https://issues.apache.org/jira/browse/REEF-1163>]
> > > > Replace Apache feather logo on website with 2016 version
> > > >
> > > > 3. Blocked by Avro version, so will be included in the next release.
> > > > a) [REEF-400 <https://issues.apache.org/jira/browse/REEF-400>]
> Make
> > > use
> > > > of AvroClassHierarchySerializer both on the Java and the .Net side
> > > >
> > > > 4. Not sure how we will include in release 0.14 (tentatively include
> > them
> > > > in the next release?).
> > > > a) [REEF-548 <https://issues.apache.org/jira/browse/REEF-548>]
> > Remove
> > > > APIs deprecated since 0.11 from REEF-IO
> > > > b) [REEF-551 <https://issues.apache.org/jira/browse/REEF-551>]
> > Remove
> > > > use of RemoteManagerFactory from Mesos and deprecate
> > > > c) [REEF-552 <https://issues.apache.org/jira/browse/REEF-552>]
> > Remove
> > > > Wake classes and methods with short deprecation-chains since 0.11
> > > > d) [REEF-1124 <https://issues.apache.org/jira/browse/REEF-1124>]
> > > Remove
> > > > deprecated constructors of NameLookupClient
> > > > e) [REEF-195 <https://issues.apache.org/jira/browse/REEF-195>] DLL
> > and
> > > > NuGet versions are not synchronized
> > > > (Sub: [REEF-281 <
> https://issues.apache.org/jira/browse/REEF-281
> > >]
> > > > Automatically sync the assembly version from NuGet and POM)
> > > > f) [REEF-330 <https://issues.apache.org/jira/browse/REEF-330>]
> Port
> > > the
> > > > REEF.NET integration tests to the new client API
> > > >
> > > >
> > > > Please let me know if you have any question or suggestion.
> > > > It will be great if the owners (or participants) update the status
> > > > especially for the items marked as 4.
> > > >
> > > > Thanks,
> > > > Yunseong
> > > >
> > > > On Sat, Feb 6, 2016 at 3:56 AM, Markus Weimer <ma...@weimo.de>
> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> we have a whole lot of issues marked as blockers of 0.14 over at
> > > >>
> > > >> https://issues.apache.org/jira/browse/REEF-811
> > > >>
> > > >> It seems unrealistic to solve them all prior to a release. Yunseong,
> > can
> > > >> you drive some triage around that?
> > > >>
> > > >> Markus
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Byung-Gon Chun
> >
>
Re: Should we postpone 0.14 release?
Posted by Boris Shulman <sh...@gmail.com>.
Will we be able to create another release right after that, maybe 0.14.1? I
will need the multi-runtime released as soon as it is ready, and it is in
PR now (and I will need few more PRs).
Boris.
On Wed, Feb 17, 2016 at 8:19 PM, Byung-Gon Chun <bg...@gmail.com> wrote:
> Thanks for the update, Yunseong.
>
> This sounds good to me.
>
> -Gon
>
>
> On Wed, Feb 17, 2016 at 7:28 PM, Yunseong Lee <yu...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Sorry for making you wait long, and thanks a lot for your patience to
> wait
> > our release :-)
> >
> > Here are some updates:
> > 1) Blockers regarding .Net tests have been resolved.
> > 2) Another blocker, *WatcherTest*, seems to be resolved very soon.
> Geon-Woo
> > has figured out the main cause of the sporadic failure, and has some idea
> > to fix it. The problem & solution is simple, but a bit debatable. He'll
> > share the findings and possible solutions soon.
> > 3) As there has been no response from other issues on the list above, I
> > think the items can be moved to the next release.
> >
> > So, I'm tentatively planning to set the new release cut-off about *end of
> > this week*, opportunistically hoping that 2) is resolved until then.
> >
> >
> > Does anybody have comment or suggestion?
> >
> > Thanks,
> > Yunseong
> >
> >
> > On Sat, Feb 6, 2016 at 10:09 AM, Yunseong Lee <yu...@gmail.com>
> > wrote:
> >
> > > Sure! Thanks for the great suggestion, Markus!
> > >
> > > Currently we have 11 blockers for releasing 0.14. I classified them
> into
> > 4
> > > categories:
> > >
> > > 1. Should be fixed; we can release 0.14 only after resolving those.
> > > a) [REEF-1040 <https://issues.apache.org/jira/browse/REEF-1040>]
> Fix a
> > > bug in WatcherTest
> > > b) [REEF-1185 <https://issues.apache.org/jira/browse/REEF-1185>] Fix
> > > CanRunClrBridgeExampleOnLocalRuntime test
> > >
> > > 2. Will be closed soon. Only minor changes are left.
> > > a) [REEF-974 <https://issues.apache.org/jira/browse/REEF-974>]
> > > Post-Graduation work
> > > b) [REEF-1163 <https://issues.apache.org/jira/browse/REEF-1163>]
> > > Replace Apache feather logo on website with 2016 version
> > >
> > > 3. Blocked by Avro version, so will be included in the next release.
> > > a) [REEF-400 <https://issues.apache.org/jira/browse/REEF-400>] Make
> > use
> > > of AvroClassHierarchySerializer both on the Java and the .Net side
> > >
> > > 4. Not sure how we will include in release 0.14 (tentatively include
> them
> > > in the next release?).
> > > a) [REEF-548 <https://issues.apache.org/jira/browse/REEF-548>]
> Remove
> > > APIs deprecated since 0.11 from REEF-IO
> > > b) [REEF-551 <https://issues.apache.org/jira/browse/REEF-551>]
> Remove
> > > use of RemoteManagerFactory from Mesos and deprecate
> > > c) [REEF-552 <https://issues.apache.org/jira/browse/REEF-552>]
> Remove
> > > Wake classes and methods with short deprecation-chains since 0.11
> > > d) [REEF-1124 <https://issues.apache.org/jira/browse/REEF-1124>]
> > Remove
> > > deprecated constructors of NameLookupClient
> > > e) [REEF-195 <https://issues.apache.org/jira/browse/REEF-195>] DLL
> and
> > > NuGet versions are not synchronized
> > > (Sub: [REEF-281 <https://issues.apache.org/jira/browse/REEF-281
> >]
> > > Automatically sync the assembly version from NuGet and POM)
> > > f) [REEF-330 <https://issues.apache.org/jira/browse/REEF-330>] Port
> > the
> > > REEF.NET integration tests to the new client API
> > >
> > >
> > > Please let me know if you have any question or suggestion.
> > > It will be great if the owners (or participants) update the status
> > > especially for the items marked as 4.
> > >
> > > Thanks,
> > > Yunseong
> > >
> > > On Sat, Feb 6, 2016 at 3:56 AM, Markus Weimer <ma...@weimo.de> wrote:
> > >
> > >> Hi,
> > >>
> > >> we have a whole lot of issues marked as blockers of 0.14 over at
> > >>
> > >> https://issues.apache.org/jira/browse/REEF-811
> > >>
> > >> It seems unrealistic to solve them all prior to a release. Yunseong,
> can
> > >> you drive some triage around that?
> > >>
> > >> Markus
> > >>
> > >
> > >
> >
>
>
>
> --
> Byung-Gon Chun
>
Re: Should we postpone 0.14 release?
Posted by Byung-Gon Chun <bg...@gmail.com>.
Thanks for the update, Yunseong.
This sounds good to me.
-Gon
On Wed, Feb 17, 2016 at 7:28 PM, Yunseong Lee <yu...@gmail.com>
wrote:
> Hi,
>
> Sorry for making you wait long, and thanks a lot for your patience to wait
> our release :-)
>
> Here are some updates:
> 1) Blockers regarding .Net tests have been resolved.
> 2) Another blocker, *WatcherTest*, seems to be resolved very soon. Geon-Woo
> has figured out the main cause of the sporadic failure, and has some idea
> to fix it. The problem & solution is simple, but a bit debatable. He'll
> share the findings and possible solutions soon.
> 3) As there has been no response from other issues on the list above, I
> think the items can be moved to the next release.
>
> So, I'm tentatively planning to set the new release cut-off about *end of
> this week*, opportunistically hoping that 2) is resolved until then.
>
>
> Does anybody have comment or suggestion?
>
> Thanks,
> Yunseong
>
>
> On Sat, Feb 6, 2016 at 10:09 AM, Yunseong Lee <yu...@gmail.com>
> wrote:
>
> > Sure! Thanks for the great suggestion, Markus!
> >
> > Currently we have 11 blockers for releasing 0.14. I classified them into
> 4
> > categories:
> >
> > 1. Should be fixed; we can release 0.14 only after resolving those.
> > a) [REEF-1040 <https://issues.apache.org/jira/browse/REEF-1040>] Fix a
> > bug in WatcherTest
> > b) [REEF-1185 <https://issues.apache.org/jira/browse/REEF-1185>] Fix
> > CanRunClrBridgeExampleOnLocalRuntime test
> >
> > 2. Will be closed soon. Only minor changes are left.
> > a) [REEF-974 <https://issues.apache.org/jira/browse/REEF-974>]
> > Post-Graduation work
> > b) [REEF-1163 <https://issues.apache.org/jira/browse/REEF-1163>]
> > Replace Apache feather logo on website with 2016 version
> >
> > 3. Blocked by Avro version, so will be included in the next release.
> > a) [REEF-400 <https://issues.apache.org/jira/browse/REEF-400>] Make
> use
> > of AvroClassHierarchySerializer both on the Java and the .Net side
> >
> > 4. Not sure how we will include in release 0.14 (tentatively include them
> > in the next release?).
> > a) [REEF-548 <https://issues.apache.org/jira/browse/REEF-548>] Remove
> > APIs deprecated since 0.11 from REEF-IO
> > b) [REEF-551 <https://issues.apache.org/jira/browse/REEF-551>] Remove
> > use of RemoteManagerFactory from Mesos and deprecate
> > c) [REEF-552 <https://issues.apache.org/jira/browse/REEF-552>] Remove
> > Wake classes and methods with short deprecation-chains since 0.11
> > d) [REEF-1124 <https://issues.apache.org/jira/browse/REEF-1124>]
> Remove
> > deprecated constructors of NameLookupClient
> > e) [REEF-195 <https://issues.apache.org/jira/browse/REEF-195>] DLL and
> > NuGet versions are not synchronized
> > (Sub: [REEF-281 <https://issues.apache.org/jira/browse/REEF-281>]
> > Automatically sync the assembly version from NuGet and POM)
> > f) [REEF-330 <https://issues.apache.org/jira/browse/REEF-330>] Port
> the
> > REEF.NET integration tests to the new client API
> >
> >
> > Please let me know if you have any question or suggestion.
> > It will be great if the owners (or participants) update the status
> > especially for the items marked as 4.
> >
> > Thanks,
> > Yunseong
> >
> > On Sat, Feb 6, 2016 at 3:56 AM, Markus Weimer <ma...@weimo.de> wrote:
> >
> >> Hi,
> >>
> >> we have a whole lot of issues marked as blockers of 0.14 over at
> >>
> >> https://issues.apache.org/jira/browse/REEF-811
> >>
> >> It seems unrealistic to solve them all prior to a release. Yunseong, can
> >> you drive some triage around that?
> >>
> >> Markus
> >>
> >
> >
>
--
Byung-Gon Chun
Re: Should we postpone 0.14 release?
Posted by Markus Weimer <ma...@weimo.de>.
On 2016-02-17 02:28, Yunseong Lee wrote:
> Does anybody have comment or suggestion?
Sounds good to me. Having a release is a value in its own right, even if
there are known issues remaining. As some on the list remember, we
endlessly moved the goals for our first OSS release by "just this one
thing" increments each time. Once we switched to time based releases,
life got a lot better :)
Markus
Re: Should we postpone 0.14 release?
Posted by Yunseong Lee <yu...@gmail.com>.
Hi,
Sorry for making you wait long, and thanks a lot for your patience to wait
our release :-)
Here are some updates:
1) Blockers regarding .Net tests have been resolved.
2) Another blocker, *WatcherTest*, seems to be resolved very soon. Geon-Woo
has figured out the main cause of the sporadic failure, and has some idea
to fix it. The problem & solution is simple, but a bit debatable. He'll
share the findings and possible solutions soon.
3) As there has been no response from other issues on the list above, I
think the items can be moved to the next release.
So, I'm tentatively planning to set the new release cut-off about *end of
this week*, opportunistically hoping that 2) is resolved until then.
Does anybody have comment or suggestion?
Thanks,
Yunseong
On Sat, Feb 6, 2016 at 10:09 AM, Yunseong Lee <yu...@gmail.com>
wrote:
> Sure! Thanks for the great suggestion, Markus!
>
> Currently we have 11 blockers for releasing 0.14. I classified them into 4
> categories:
>
> 1. Should be fixed; we can release 0.14 only after resolving those.
> a) [REEF-1040 <https://issues.apache.org/jira/browse/REEF-1040>] Fix a
> bug in WatcherTest
> b) [REEF-1185 <https://issues.apache.org/jira/browse/REEF-1185>] Fix
> CanRunClrBridgeExampleOnLocalRuntime test
>
> 2. Will be closed soon. Only minor changes are left.
> a) [REEF-974 <https://issues.apache.org/jira/browse/REEF-974>]
> Post-Graduation work
> b) [REEF-1163 <https://issues.apache.org/jira/browse/REEF-1163>]
> Replace Apache feather logo on website with 2016 version
>
> 3. Blocked by Avro version, so will be included in the next release.
> a) [REEF-400 <https://issues.apache.org/jira/browse/REEF-400>] Make use
> of AvroClassHierarchySerializer both on the Java and the .Net side
>
> 4. Not sure how we will include in release 0.14 (tentatively include them
> in the next release?).
> a) [REEF-548 <https://issues.apache.org/jira/browse/REEF-548>] Remove
> APIs deprecated since 0.11 from REEF-IO
> b) [REEF-551 <https://issues.apache.org/jira/browse/REEF-551>] Remove
> use of RemoteManagerFactory from Mesos and deprecate
> c) [REEF-552 <https://issues.apache.org/jira/browse/REEF-552>] Remove
> Wake classes and methods with short deprecation-chains since 0.11
> d) [REEF-1124 <https://issues.apache.org/jira/browse/REEF-1124>] Remove
> deprecated constructors of NameLookupClient
> e) [REEF-195 <https://issues.apache.org/jira/browse/REEF-195>] DLL and
> NuGet versions are not synchronized
> (Sub: [REEF-281 <https://issues.apache.org/jira/browse/REEF-281>]
> Automatically sync the assembly version from NuGet and POM)
> f) [REEF-330 <https://issues.apache.org/jira/browse/REEF-330>] Port the
> REEF.NET integration tests to the new client API
>
>
> Please let me know if you have any question or suggestion.
> It will be great if the owners (or participants) update the status
> especially for the items marked as 4.
>
> Thanks,
> Yunseong
>
> On Sat, Feb 6, 2016 at 3:56 AM, Markus Weimer <ma...@weimo.de> wrote:
>
>> Hi,
>>
>> we have a whole lot of issues marked as blockers of 0.14 over at
>>
>> https://issues.apache.org/jira/browse/REEF-811
>>
>> It seems unrealistic to solve them all prior to a release. Yunseong, can
>> you drive some triage around that?
>>
>> Markus
>>
>
>
Re: Should we postpone 0.14 release?
Posted by Yunseong Lee <yu...@gmail.com>.
Sure! Thanks for the great suggestion, Markus!
Currently we have 11 blockers for releasing 0.14. I classified them into 4
categories:
1. Should be fixed; we can release 0.14 only after resolving those.
a) [REEF-1040 <https://issues.apache.org/jira/browse/REEF-1040>] Fix a
bug in WatcherTest
b) [REEF-1185 <https://issues.apache.org/jira/browse/REEF-1185>] Fix
CanRunClrBridgeExampleOnLocalRuntime test
2. Will be closed soon. Only minor changes are left.
a) [REEF-974 <https://issues.apache.org/jira/browse/REEF-974>]
Post-Graduation work
b) [REEF-1163 <https://issues.apache.org/jira/browse/REEF-1163>] Replace
Apache feather logo on website with 2016 version
3. Blocked by Avro version, so will be included in the next release.
a) [REEF-400 <https://issues.apache.org/jira/browse/REEF-400>] Make use
of AvroClassHierarchySerializer both on the Java and the .Net side
4. Not sure how we will include in release 0.14 (tentatively include them
in the next release?).
a) [REEF-548 <https://issues.apache.org/jira/browse/REEF-548>] Remove
APIs deprecated since 0.11 from REEF-IO
b) [REEF-551 <https://issues.apache.org/jira/browse/REEF-551>] Remove use
of RemoteManagerFactory from Mesos and deprecate
c) [REEF-552 <https://issues.apache.org/jira/browse/REEF-552>] Remove
Wake classes and methods with short deprecation-chains since 0.11
d) [REEF-1124 <https://issues.apache.org/jira/browse/REEF-1124>] Remove
deprecated constructors of NameLookupClient
e) [REEF-195 <https://issues.apache.org/jira/browse/REEF-195>] DLL and
NuGet versions are not synchronized
(Sub: [REEF-281 <https://issues.apache.org/jira/browse/REEF-281>]
Automatically sync the assembly version from NuGet and POM)
f) [REEF-330 <https://issues.apache.org/jira/browse/REEF-330>] Port the
REEF.NET integration tests to the new client API
Please let me know if you have any question or suggestion.
It will be great if the owners (or participants) update the status
especially for the items marked as 4.
Thanks,
Yunseong
On Sat, Feb 6, 2016 at 3:56 AM, Markus Weimer <ma...@weimo.de> wrote:
> Hi,
>
> we have a whole lot of issues marked as blockers of 0.14 over at
>
> https://issues.apache.org/jira/browse/REEF-811
>
> It seems unrealistic to solve them all prior to a release. Yunseong, can
> you drive some triage around that?
>
> Markus
>
Re: Should we postpone 0.14 release?
Posted by Markus Weimer <ma...@weimo.de>.
Hi,
we have a whole lot of issues marked as blockers of 0.14 over at
https://issues.apache.org/jira/browse/REEF-811
It seems unrealistic to solve them all prior to a release. Yunseong, can
you drive some triage around that?
Markus
Re: Should we postpone 0.14 release?
Posted by Byung-Gon Chun <bg...@gmail.com>.
Thanks, Yunseong. Yunseong has been working at MSRA for the last five
months. Today's his last day. I'm sure he has more time to work on REEF
when he's back to SNU. :-)
On Fri, Feb 5, 2016 at 10:21 AM, Yunseong Lee <yu...@gmail.com>
wrote:
> Thanks Mariia. I definitely agree that we need to postpone the release
> until our tests are stabilized.
>
> I'll also work on the failures which currently blocks our release :)
>
>
> Thanks,
> Yunseong
>
>
> On Friday, February 5, 2016, Julia Wang (QIUHE) <Qi...@microsoft.com>
> wrote:
>
> > Agree. Our testing for release is just simply re-run the testing with
> > released bits. The quantity is actually guarded by test cases. If we know
> > some test failures, we should fix unless it turns out to be test issue
> not
> > prod code issue.
> >
> > Thanks,
> > Julia
> >
> > -----Original Message-----
> > From: Markus Weimer [mailto:markus@weimo.de <javascript:;>]
> > Sent: Thursday, February 4, 2016 3:36 PM
> > To: dev@reef.apache.org <javascript:;>
> > Subject: Re: Should we postpone 0.14 release?
> >
> > On 2016-02-04 11:26, Mariia Mykhailova wrote:
> > > I think we shouldn't proceed with the release until these failures are
> > > investigated and fixed. What do you think?
> >
> > +1 We shouldn't release with known test failures.
> >
> > Markus
> >
>
--
Byung-Gon Chun
Re: Should we postpone 0.14 release?
Posted by Yunseong Lee <yu...@gmail.com>.
Thanks Mariia. I definitely agree that we need to postpone the release
until our tests are stabilized.
I'll also work on the failures which currently blocks our release :)
Thanks,
Yunseong
On Friday, February 5, 2016, Julia Wang (QIUHE) <Qi...@microsoft.com>
wrote:
> Agree. Our testing for release is just simply re-run the testing with
> released bits. The quantity is actually guarded by test cases. If we know
> some test failures, we should fix unless it turns out to be test issue not
> prod code issue.
>
> Thanks,
> Julia
>
> -----Original Message-----
> From: Markus Weimer [mailto:markus@weimo.de <javascript:;>]
> Sent: Thursday, February 4, 2016 3:36 PM
> To: dev@reef.apache.org <javascript:;>
> Subject: Re: Should we postpone 0.14 release?
>
> On 2016-02-04 11:26, Mariia Mykhailova wrote:
> > I think we shouldn't proceed with the release until these failures are
> > investigated and fixed. What do you think?
>
> +1 We shouldn't release with known test failures.
>
> Markus
>
RE: Should we postpone 0.14 release?
Posted by "Julia Wang (QIUHE)" <Qi...@microsoft.com>.
Agree. Our testing for release is just simply re-run the testing with released bits. The quantity is actually guarded by test cases. If we know some test failures, we should fix unless it turns out to be test issue not prod code issue.
Thanks,
Julia
-----Original Message-----
From: Markus Weimer [mailto:markus@weimo.de]
Sent: Thursday, February 4, 2016 3:36 PM
To: dev@reef.apache.org
Subject: Re: Should we postpone 0.14 release?
On 2016-02-04 11:26, Mariia Mykhailova wrote:
> I think we shouldn't proceed with the release until these failures are
> investigated and fixed. What do you think?
+1 We shouldn't release with known test failures.
Markus
Re: Should we postpone 0.14 release?
Posted by Markus Weimer <ma...@weimo.de>.
On 2016-02-04 11:26, Mariia Mykhailova wrote:
> I think we shouldn't proceed with the release until these failures
> are investigated and fixed. What do you think?
+1 We shouldn't release with known test failures.
Markus