Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc0

[Zach Kimberg]

Hi Justin,

We will replace the file CC-BY-SA documentation file with a pointer then.
Because it is a submodule, we can't change it in the code and will just
replace it as part of our release process.

Per you suggestion, I also added copyright owners to the license file in
addition to fixing the various problems. Hopefully that makes it easier to
review. I think our license should be correct now. Can you help take a look
at our master branch (
https://github.com/apache/incubator-mxnet/blob/master/LICENSE) to see if
there are any problems that I have missed before we continue with our 1.4
release?

Thanks,
Zach

On Thu, Jan 10, 2019 at 1:27 AM Justin Mclean 
wrote:

> Hi,
>
> > Hi Justin, it would be great if we can clarify the policy the submodule
> dependencies.
>
> Basically follow the guiding principle [1] what states anything that is
> bundled in a release need to be mentioned in LICENSE. If it not in the
> release then it doesn’t need to be included.
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/licensing-howto.html#guiding-principle
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Hudi Incubation Proposal

[Thomas Weise]

I will start the VOTE in a day or two if there are no further comments.


On Fri, Jan 11, 2019 at 2:59 PM Vinoth Chandar 
wrote:

> Hi all,
>
> Added Suneel Marthi as another mentor to the project. Thanks Suneel!
>
> Thanks
> Vinoth
>
> On Fri, Jan 11, 2019 at 8:09 AM Thomas Weise  wrote:
>
> > I think that's a fair point.
> >
> > If we can make sure we have one more experienced mentor with sufficient
> > time commitment for at least advisory capacity.
> >
> > I'm happy to pick up more of the legwork for initial setup etc.
> >
> > Thomas
> >
> > On Thu, Jan 10, 2019 at 7:48 PM Justin Mclean 
> wrote:
> >
> > > Hi,
> > >
> > > While I would not oppose it going forward I think the podling could
> still
> > > do with another experienced mentor. Any takers?
> > >
> > > Reason why I think this is below, please don’t take this personally or
> if
> > > you think it’s inaccurate speak up, I just want to give this new
> podling
> > a
> > > good chance at success..
> > >
> > > > * Luciano Resende (lresende at apache dot org)
> > >
> > > Experienced mentor, but may have a few too many podlings to be able to
> > > spend a lot of time mentoring this podling.
> > >
> > > > * Thomas Weise (thw at apache dot org
> > >
> > > First time mentor and new IPMC member.
> > >
> > > > * Kishore Gopalakrishna (kishoreg at apache dot org)
> > >
> > >
> > > First time mentor and new IPMC member.who not been that active.
> (Podling
> > > missed report and missed last report missed signoff).
> > >
> > > Thanks,
> > > Justin
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] Hudi Incubation Proposal

[Vinoth Chandar]

Hi all,

Added Suneel Marthi as another mentor to the project. Thanks Suneel!

Thanks
Vinoth

On Fri, Jan 11, 2019 at 8:09 AM Thomas Weise  wrote:

> I think that's a fair point.
>
> If we can make sure we have one more experienced mentor with sufficient
> time commitment for at least advisory capacity.
>
> I'm happy to pick up more of the legwork for initial setup etc.
>
> Thomas
>
> On Thu, Jan 10, 2019 at 7:48 PM Justin Mclean  wrote:
>
> > Hi,
> >
> > While I would not oppose it going forward I think the podling could still
> > do with another experienced mentor. Any takers?
> >
> > Reason why I think this is below, please don’t take this personally or if
> > you think it’s inaccurate speak up, I just want to give this new podling
> a
> > good chance at success..
> >
> > > * Luciano Resende (lresende at apache dot org)
> >
> > Experienced mentor, but may have a few too many podlings to be able to
> > spend a lot of time mentoring this podling.
> >
> > > * Thomas Weise (thw at apache dot org
> >
> > First time mentor and new IPMC member.
> >
> > > * Kishore Gopalakrishna (kishoreg at apache dot org)
> >
> >
> > First time mentor and new IPMC member.who not been that active. (Podling
> > missed report and missed last report missed signoff).
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Using GPLv3 in the build?

[Christofer Dutz]

Unfortunately the till in question turned out to support serialisation only 
theoretically, only in Java and that only POC quality ... Will stick with 
helping that Daffodil pulling write a code generator.

But good to know the "GPL in the build" thing :-)

Chris

Outlook for Android herunterladen


From: Matt Sicker 
Sent: Friday, January 11, 2019 6:06:25 PM
To: general@incubator.apache.org
Subject: Re: Using GPLv3 in the build?

Let's also not forget that OpenJDK is also GPLv2 with CP, though we
use it everywhere instead of continuing development on Harmony. And
then who knows how many GPL utilities were used in the original
version of httpd? ;)

On Fri, 11 Jan 2019 at 00:17, William A Rowe Jr  wrote:
>
> Yup. This seems concordant with most of the GPL exception clauses on
> generated output. That is fine, we don't prohibit through use of GPL for
> target architecture buildable tarballs of sources, so long as the consumers
> of those source tarballs are not imposed restrictions beyond the AL 2.0.
>
> Many projects generate tarballs from AutoMake/AutoConf, and this seems to
> sort in that category, but to be sure, present this as a legal-discuss@a.o
> inquiry with a corresponding Jira to have a binding conclusion.
>
> On Wed, Jan 9, 2019, 10:04 Christofer Dutz 
> > Ok ... so that was quick,
> >
> > I looked up the guy doing most of the commits and asked him. Here his
> > reply:
> >
> > "As with majority of the compilers (gcc, clang, etc), Kaitai Struct
> > compiler does not make any special takes on the output. If you own the
> > input, you totally own the output, and free to specify your own
> > conditions on its licensing.
> >
> > If you use something from our formats repo — http://formats.kaitai.io/
> > — it's generally safe to assume that output license equals to KSY
> > input file license (of course, I'm not a lawyer, I can't provide legal
> > advice, blah, blah, etc, the regular disclaimer you've probably seen
> > tons of times already). As most of formats in that repo are
> > CC0-licensed, basically it's public domain, you can do whatever you
> > want with them."
> >
> > So if we input a definition which we write as part of the PLC4X project
> > and which is naturally Apache 2.0, so the output would be Apache 2.0 too
> > ... so that sounds good.
> >
> > Unfortunately he also told me that even if the parsing code was already
> > good, the serialization code is in very early stages and would probably not
> > be up to our expectations :-(
> >
> > So we probably shouldn't base our project on that ... but thanks for the
> > fast response Richard :-)
> >
> > Chris
> >
> >
> >
> > Am 09.01.19, 16:26 schrieb "Richard Eckart de Castilho" :
> >
> > Hi Chris,
> >
> > This seems to be a similar situation as for tools such as automake
> > (which I believe is used by several Apache projects).
> >
> > To the best of my knowledge (I am not a lawyer), the the copyleft
> > clause of the GPLv3 does not impose and restrictions on the output of tools
> > under the license. E.g. if you have a text editor published under GPLv3,
> > the copyleft doesn't affect to the texts you have written with it.
> >
> > In the case of a code generator (like a compiler or like automake)
> > you'd best check if the generated output contains anything that is licensed
> > under the problematic license. For example, the compiler might generate a
> > boot loader block into every application and this boot loader block might
> > be under a copyleft license - that could be a problem. For this reason,
> > e.g. automake has special exceptions to the GPLv3:
> > https://www.gnu.org/licenses/exceptions.en.html
> >
> > If the compiler you want to use does not mention any such exceptions
> > as part of their FAQ/license description, maybe best enter into contact
> > with the developers and ask them.
> >
> > Cheers,
> >
> > -- Richard
> >
> > > On 9. Jan 2019, at 15:53, Christofer Dutz 
> > wrote:
> > >
> > > Hi all,
> > >
> > > I just double checked the text on the GPLv3 compatibility.
> > > Stupid thing is the problem I’m having isn’t really covered by that
> > [1].
> > >
> > > The case I’m currently having is that there is a toolset called
> > Kaitai [2], which sounds interesting for the Apache PLC4X project.
> > > In general you define a data-format and have it generate model,
> > serializer and parser in multiple languages (Similar to Thrift or Protobuf,
> > but with a focus on the transport data-format and not the model).
> > >
> > > This consists of a compiler and a runtime.
> > >
> > > The compiler generates code from sources which use the runtime
> > libraries.
> > > The runtime libraries are Apache 2.0 and MIT licensed, so this would
> > be ok
> > > The compiler however is GPLv3 …
> > >
> > > Now we would not be bunding the compiler and the users wouldn’t need
> > to use it when using PLC4X as

Re: [VOTE] Release Apache Doris 0.9.0-incubating-rc01

[Makoto Yui]

I vote with +0 (binding).

Due to source build problems, I cannot vote +1 but not negative to other
three +1 because an IPMC (Dave) was succeeded for src build and other
checkpoints are green.

I checked the following points:
- Are release files in correct location?
 Yes
- Do release files have the word incubating in their name?
 Yes
- Are the digital signature and hashes correct?
 Yes
- Does DISCLAIMER file exist?
 Yes
- Do LICENSE and NOTICE files exists?
 Yes
- Is the LICENSE and NOTICE text correct?
 Yes (except issues pointed by Williem)
- Is the NOTICE year correct?
 Yes
- Un-included software dependencies are not mentioned in LICENSE or NOTICE?
 Not checked
- License information is not mentioned in NOTICE?
 Yes
Is there any 3rd party code contained inside the release? If so:
-  Does the software have a compatible license?
 Yes (checked LICENSE.txt)
- Are all software licenses mentioned in LICENSE?
 Not checked
- Is the full text of the licenses (or pointers to it) in LICENSE?
 Yes
Is any of this code Apache licensed? Do they have NOTICE files? If so:
- Have relevant parts of those NOTICE files been added to this NOTICE file?
 Yes
- Do all source files have ASF headers?
 Rat check passed successfully

https://github.com/apache/incubator-doris/wiki/How-to-verify-Apache-Release#3-verify-license-header
- Do the contents of the release match with what's tagged in version
control?
 Seems fine
- Are there any unexpected binary files in the release?
 Rat check passed
- Can you compile from source? Are the instruction clear?
 Failed to compile. Not sure users can build Doris from src.
 Instruction was clear.
- Is the issue minor?
 Unsure
- Could it possibly be fixed in the next release?
 Yes

Thanks,
Makoto

2019年1月12日(土) 2:12 Makoto Yui :

> With PARALLEL=1, the build fails as follows
>
> /usr/bin/../bin/g++ -DHAVE_CONFIG_H -I. -I../.. -I../../lib/cpp/src/thrift
> -I./src
> -I/tmp/doris/apache-doris-0.9.0.rc01-incubating-src/thirdparty/installed/include
> -Wall -Wextra -pedantic -g -O2 -std=c++11 -MT
> src/generate/thrift-t_as3_generator.o -MD -MP -MF
> src/generate/.deps/thrift-t_as3_generator.Tpo -c -o
> src/generate/thrift-t_as3_generator.o `test -f
> 'src/generate/t_as3_generator.cc' || echo
> './'`src/generate/t_as3_generator.cc
>
> src/generate/t_as3_generator.cc: In member function 'void
> t_as3_generator::generate_as3_struct(t_struct*, bool)':
>
> src/generate/t_as3_generator.cc:663:1: internal compiler error: Segmentation
> fault
>
>  }
>
>  ^
>
> Please submit a full bug report,
>
> with preprocessed source if appropriate.
>
> See  for instructions.
>
> Makefile:1066: recipe for target 'src/generate/thrift-t_as3_generator.o'
> failed
>
> make[3]: *** [src/generate/thrift-t_as3_generator.o] Error 1
>
> make[3]: Leaving directory
> '/tmp/doris/apache-doris-0.9.0.rc01-incubating-src/thirdparty/src/thrift-0.9.3/compiler/cpp'
>
> Makefile:588: recipe for target 'all' failed
>
> make[2]: *** [all] Error 2
>
> make[2]: Leaving directory
> '/tmp/doris/apache-doris-0.9.0.rc01-incubating-src/thirdparty/src/thrift-0.9.3/compiler/cpp'
>
> Makefile:609: recipe for target 'all-recursive' failed
>
> make[1]: *** [all-recursive] Error 1
>
> make[1]: Leaving directory
> '/tmp/doris/apache-doris-0.9.0.rc01-incubating-src/thirdparty/src/thrift-0.9.3'
>
> Makefile:530: recipe for target 'all' failed
>
> make: *** [all] Error 2
>
> I'm not sure it's host memory issue. Host has enough memory left.
>
> BTW, the project page[1] should have disclaimer [2] of undergoing
> incubation message.
> [1] https://doris.incubator.apache.org/
> [2] https://incubator.apache.org/guides/branding.html#disclaimers
>
> Makoto
>
> 2019年1月11日(金) 17:07 Li,De(BDG) :
>
>> Hi Makoto,
>>
>> Thank you for your check.
>>
>> >> Why not cancel rc1 and create rc2 fixing license header issue that
>> Willem
>> >> pointed?
>> >> It seems it's better to be fixed.
>>
>> Actually, we have fixed these issues in branch-0.9.0 (#471, #473) after
>> Willem pointed.
>>
>> I’m afraid it will take everyone’s more time to check repeatedly and so
>> I’m going to fix them in next version.
>>
>> >> It also seems that no one from IPMC succeeded to build distribution
>> from src
>>
>> Indeed, the building is not good as we expect, but I noticed the main
>> cause is that it can’t compile in OSX and it needs GCC 5.3.1+.
>> But it seems Dave Meikle has succeeded to build in Ubuntu 18.04 and we
>> have tested pass in CentOS and Ubuntu.
>> We will continue to check and complete the building, also docker
>> environment as you mentioned.
>>
>> Best Regards,
>> Reed
>>
>>
>> On 2019/1/11 上午2:23， "Makoto Yui"  wrote:
>>
>> >Reed,
>> >
>> >Why not cancel rc1 and create rc2 fixing license header issue that Willem
>> >pointed?
>> >It seems it's better to be fixed.
>> >
>> >It also seems that no one from IPMC succeeded to build distribution from
>> >src (no sure for Luke though).
>> >
>> >I got the following build error (which might be gcc-5 version issue):
>> >
>> >

Re: [VOTE] Release Apache Doris 0.9.0-incubating-rc01

[Makoto Yui]

With PARALLEL=1, the build fails as follows

/usr/bin/../bin/g++ -DHAVE_CONFIG_H -I. -I../..
-I../../lib/cpp/src/thrift  -I./src
-I/tmp/doris/apache-doris-0.9.0.rc01-incubating-src/thirdparty/installed/include
-Wall -Wextra -pedantic -g -O2 -std=c++11 -MT
src/generate/thrift-t_as3_generator.o -MD -MP -MF
src/generate/.deps/thrift-t_as3_generator.Tpo -c -o
src/generate/thrift-t_as3_generator.o `test -f
'src/generate/t_as3_generator.cc' || echo
'./'`src/generate/t_as3_generator.cc

src/generate/t_as3_generator.cc: In member function 'void
t_as3_generator::generate_as3_struct(t_struct*, bool)':

src/generate/t_as3_generator.cc:663:1: internal compiler error: Segmentation
fault

 }

 ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

Makefile:1066: recipe for target 'src/generate/thrift-t_as3_generator.o'
failed

make[3]: *** [src/generate/thrift-t_as3_generator.o] Error 1

make[3]: Leaving directory
'/tmp/doris/apache-doris-0.9.0.rc01-incubating-src/thirdparty/src/thrift-0.9.3/compiler/cpp'

Makefile:588: recipe for target 'all' failed

make[2]: *** [all] Error 2

make[2]: Leaving directory
'/tmp/doris/apache-doris-0.9.0.rc01-incubating-src/thirdparty/src/thrift-0.9.3/compiler/cpp'

Makefile:609: recipe for target 'all-recursive' failed

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory
'/tmp/doris/apache-doris-0.9.0.rc01-incubating-src/thirdparty/src/thrift-0.9.3'

Makefile:530: recipe for target 'all' failed

make: *** [all] Error 2

I'm not sure it's host memory issue. Host has enough memory left.

BTW, the project page[1] should have disclaimer [2] of undergoing
incubation message.
[1] https://doris.incubator.apache.org/
[2] https://incubator.apache.org/guides/branding.html#disclaimers

Makoto

2019年1月11日(金) 17:07 Li,De(BDG) :

> Hi Makoto,
>
> Thank you for your check.
>
> >> Why not cancel rc1 and create rc2 fixing license header issue that
> Willem
> >> pointed?
> >> It seems it's better to be fixed.
>
> Actually, we have fixed these issues in branch-0.9.0 (#471, #473) after
> Willem pointed.
>
> I’m afraid it will take everyone’s more time to check repeatedly and so
> I’m going to fix them in next version.
>
> >> It also seems that no one from IPMC succeeded to build distribution
> from src
>
> Indeed, the building is not good as we expect, but I noticed the main
> cause is that it can’t compile in OSX and it needs GCC 5.3.1+.
> But it seems Dave Meikle has succeeded to build in Ubuntu 18.04 and we
> have tested pass in CentOS and Ubuntu.
> We will continue to check and complete the building, also docker
> environment as you mentioned.
>
> Best Regards,
> Reed
>
>
> On 2019/1/11 上午2:23， "Makoto Yui"  wrote:
>
> >Reed,
> >
> >Why not cancel rc1 and create rc2 fixing license header issue that Willem
> >pointed?
> >It seems it's better to be fixed.
> >
> >It also seems that no one from IPMC succeeded to build distribution from
> >src (no sure for Luke though).
> >
> >I got the following build error (which might be gcc-5 version issue):
> >
> >[ 57%] Building CXX object
> >projects/compiler-rt/lib/msan/CMakeFiles/clang_rt.msan-x86_64.dir/msan_int
> >erceptors.cc.o
> >
> >/tmp/doris/apache-doris-0.9.0.rc01-incubating-src/thirdparty/src/llvm-3.4.
> >2.src/projects/compiler-rt/lib/msan/msan_interceptors.cc:
> >In function 'void __msan::InitializeInterceptors()':
> >
> >/tmp/doris/apache-doris-0.9.0.rc01-incubating-src/thirdparty/src/llvm-3.4.
> >2.src/projects/compiler-rt/lib/msan/msan_interceptors.cc:1573:1:
> >internal
> >compiler error: Segmentation fault
> >
> > }
> >
> > ^
> >
> >Please submit a full bug report,
> >
> >with preprocessed source if appropriate.
> >
> >See  for instructions.
> >
> >projects/compiler-rt/lib/msan/CMakeFiles/clang_rt.msan-x86_64.dir/
> build.ma
> >ke:134:
> >recipe for target
> >'projects/compiler-rt/lib/msan/CMakeFiles/clang_rt.msan-x86_64.dir/msan_in
> >terceptors.cc.o'
> >failed
> >
> >I used ubuntu xenial on docker on OSX.
> >Software versions meets requirements (except Maven version) as seen in
> >
> >docker run ubuntu:xenial -it
> >
> >
> >$ apt-get install wget openjdk-8-jdk maven gcc-5 bzip2 python cmake zip
> >xz-utils patch byacc flex automake libtool g++
> >
> >
> >root@d9e5b7017e7b:/tmp/doris/apache-doris-0.9.0.rc01-incubating-src# gcc
> >--version | head -1
> >
> >gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609
> >
> >
> >root@d9e5b7017e7b:/tmp/doris/apache-doris-0.9.0.rc01-incubating-src# java
> >-version
> >
> >openjdk version "1.8.0_191"
> >
> >OpenJDK Runtime Environment (build
> >1.8.0_191-8u191-b12-0ubuntu0.16.04.1-b12)
> >
> >OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
> >
> >
> >root@d9e5b7017e7b:/tmp/doris/apache-doris-0.9.0.rc01-incubating-src#
> >python
> >--version
> >
> >Python 2.7.12
> >
> >
> >root@d9e5b7017e7b:/tmp/doris/apache-doris-0.9.0.rc01-incubating-src# mvn
> >--version
> >
> >Apache Maven 3.3.9
> >
> >
> >root@d9e5b7017e7b:/tmp/doris/apache-d

Re: Using GPLv3 in the build?

[Matt Sicker]

Let's also not forget that OpenJDK is also GPLv2 with CP, though we
use it everywhere instead of continuing development on Harmony. And
then who knows how many GPL utilities were used in the original
version of httpd? ;)

On Fri, 11 Jan 2019 at 00:17, William A Rowe Jr  wrote:
>
> Yup. This seems concordant with most of the GPL exception clauses on
> generated output. That is fine, we don't prohibit through use of GPL for
> target architecture buildable tarballs of sources, so long as the consumers
> of those source tarballs are not imposed restrictions beyond the AL 2.0.
>
> Many projects generate tarballs from AutoMake/AutoConf, and this seems to
> sort in that category, but to be sure, present this as a legal-discuss@a.o
> inquiry with a corresponding Jira to have a binding conclusion.
>
> On Wed, Jan 9, 2019, 10:04 Christofer Dutz 
> > Ok ... so that was quick,
> >
> > I looked up the guy doing most of the commits and asked him. Here his
> > reply:
> >
> > "As with majority of the compilers (gcc, clang, etc), Kaitai Struct
> > compiler does not make any special takes on the output. If you own the
> > input, you totally own the output, and free to specify your own
> > conditions on its licensing.
> >
> > If you use something from our formats repo — http://formats.kaitai.io/
> > — it's generally safe to assume that output license equals to KSY
> > input file license (of course, I'm not a lawyer, I can't provide legal
> > advice, blah, blah, etc, the regular disclaimer you've probably seen
> > tons of times already). As most of formats in that repo are
> > CC0-licensed, basically it's public domain, you can do whatever you
> > want with them."
> >
> > So if we input a definition which we write as part of the PLC4X project
> > and which is naturally Apache 2.0, so the output would be Apache 2.0 too
> > ... so that sounds good.
> >
> > Unfortunately he also told me that even if the parsing code was already
> > good, the serialization code is in very early stages and would probably not
> > be up to our expectations :-(
> >
> > So we probably shouldn't base our project on that ... but thanks for the
> > fast response Richard :-)
> >
> > Chris
> >
> >
> >
> > Am 09.01.19, 16:26 schrieb "Richard Eckart de Castilho" :
> >
> > Hi Chris,
> >
> > This seems to be a similar situation as for tools such as automake
> > (which I believe is used by several Apache projects).
> >
> > To the best of my knowledge (I am not a lawyer), the the copyleft
> > clause of the GPLv3 does not impose and restrictions on the output of tools
> > under the license. E.g. if you have a text editor published under GPLv3,
> > the copyleft doesn't affect to the texts you have written with it.
> >
> > In the case of a code generator (like a compiler or like automake)
> > you'd best check if the generated output contains anything that is licensed
> > under the problematic license. For example, the compiler might generate a
> > boot loader block into every application and this boot loader block might
> > be under a copyleft license - that could be a problem. For this reason,
> > e.g. automake has special exceptions to the GPLv3:
> > https://www.gnu.org/licenses/exceptions.en.html
> >
> > If the compiler you want to use does not mention any such exceptions
> > as part of their FAQ/license description, maybe best enter into contact
> > with the developers and ask them.
> >
> > Cheers,
> >
> > -- Richard
> >
> > > On 9. Jan 2019, at 15:53, Christofer Dutz 
> > wrote:
> > >
> > > Hi all,
> > >
> > > I just double checked the text on the GPLv3 compatibility.
> > > Stupid thing is the problem I’m having isn’t really covered by that
> > [1].
> > >
> > > The case I’m currently having is that there is a toolset called
> > Kaitai [2], which sounds interesting for the Apache PLC4X project.
> > > In general you define a data-format and have it generate model,
> > serializer and parser in multiple languages (Similar to Thrift or Protobuf,
> > but with a focus on the transport data-format and not the model).
> > >
> > > This consists of a compiler and a runtime.
> > >
> > > The compiler generates code from sources which use the runtime
> > libraries.
> > > The runtime libraries are Apache 2.0 and MIT licensed, so this would
> > be ok
> > > The compiler however is GPLv3 …
> > >
> > > Now we would not be bunding the compiler and the users wouldn’t need
> > to use it when using PLC4X as it’s only needed in the code-generation phase
> > of the build.
> > >
> > > So before I throw the idea over board, I just wanted to double-check
> > this special case.
> > >
> > > Chris
> > >
> > >
> > >
> > > [1] https://www.apache.org/licenses/GPL-compatibility.html
> > > [2] https://kaitai.io/
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubat

Re: Draft incubator report for January 2019

[Justin Mclean]

Hi,
You can edit it in whimsy.
Thanks,
Justin

On Fri, 11 Jan 2019, 08:50 Myrle Krantz  Hey Justin,
>
> I just signed off weex... and then realized I was signing off on a report
> that was already submitted.  Sorry about that.
>
> Best Regards,
> Myrle
>
> On Mon, Jan 7, 2019 at 8:55 AM Justin Mclean  wrote:
>
> > Hi,
> >
> > Currently there's a couple of projects don’t have any sign offs. While we
> > have more than a day to go please don't leave it too late. Just a
> friendly
> > reminder any project that doesn't get any sign-off will be asked to
> report
> > next month and the board likes to see more than one sign off.
> >
> > Podlings missing signoff:
> >  - Annotator
> >  - BatchEE
> >  - Milagro
> >
> > Podlings with only one sign off:
> >  - Senssoft
> >  - Weex
> >
> > Thanks,
> > Justin
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Draft incubator report for January 2019

[Myrle Krantz]

Hey Justin,

I just signed off weex... and then realized I was signing off on a report
that was already submitted.  Sorry about that.

Best Regards,
Myrle

On Mon, Jan 7, 2019 at 8:55 AM Justin Mclean  wrote:

> Hi,
>
> Currently there's a couple of projects don’t have any sign offs. While we
> have more than a day to go please don't leave it too late. Just a friendly
> reminder any project that doesn't get any sign-off will be asked to report
> next month and the board likes to see more than one sign off.
>
> Podlings missing signoff:
>  - Annotator
>  - BatchEE
>  - Milagro
>
> Podlings with only one sign off:
>  - Senssoft
>  - Weex
>
> Thanks,
> Justin
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Hudi Incubation Proposal

[Thomas Weise]

I think that's a fair point.

If we can make sure we have one more experienced mentor with sufficient
time commitment for at least advisory capacity.

I'm happy to pick up more of the legwork for initial setup etc.

Thomas

On Thu, Jan 10, 2019 at 7:48 PM Justin Mclean  wrote:

> Hi,
>
> While I would not oppose it going forward I think the podling could still
> do with another experienced mentor. Any takers?
>
> Reason why I think this is below, please don’t take this personally or if
> you think it’s inaccurate speak up, I just want to give this new podling a
> good chance at success..
>
> > * Luciano Resende (lresende at apache dot org)
>
> Experienced mentor, but may have a few too many podlings to be able to
> spend a lot of time mentoring this podling.
>
> > * Thomas Weise (thw at apache dot org
>
> First time mentor and new IPMC member.
>
> > * Kishore Gopalakrishna (kishoreg at apache dot org)
>
>
> First time mentor and new IPMC member.who not been that active. (Podling
> missed report and missed last report missed signoff).
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Hudi Incubation Proposal

[Pierre Smits]

I have experience to help out as a mentor (I helped Apache Trafodion
through their incubation and successfully graduate).

Best regards,

Pierre Smits

*Apache Trafodion , Vice President & PMC
Chair*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Fri, Jan 11, 2019 at 4:48 AM Justin Mclean  wrote:

> Hi,
>
> While I would not oppose it going forward I think the podling could still
> do with another experienced mentor. Any takers?
>
> Reason why I think this is below, please don’t take this personally or if
> you think it’s inaccurate speak up, I just want to give this new podling a
> good chance at success..
>
> > * Luciano Resende (lresende at apache dot org)
>
> Experienced mentor, but may have a few too many podlings to be able to
> spend a lot of time mentoring this podling.
>
> > * Thomas Weise (thw at apache dot org
>
> First time mentor and new IPMC member.
>
> > * Kishore Gopalakrishna (kishoreg at apache dot org)
>
>
> First time mentor and new IPMC member.who not been that active. (Podling
> missed report and missed last report missed signoff).
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache Doris 0.9.0-incubating-rc01

[Li,De(BDG)]

Hi Makoto,

Thank you for your check.

>> Why not cancel rc1 and create rc2 fixing license header issue that
Willem
>> pointed?
>> It seems it's better to be fixed.

Actually, we have fixed these issues in branch-0.9.0 (#471, #473) after
Willem pointed.

I’m afraid it will take everyone’s more time to check repeatedly and so
I’m going to fix them in next version.

>> It also seems that no one from IPMC succeeded to build distribution
from src

Indeed, the building is not good as we expect, but I noticed the main
cause is that it can’t compile in OSX and it needs GCC 5.3.1+.
But it seems Dave Meikle has succeeded to build in Ubuntu 18.04 and we
have tested pass in CentOS and Ubuntu.
We will continue to check and complete the building, also docker
environment as you mentioned.

Best Regards,
Reed


On 2019/1/11 上午2:23， "Makoto Yui"  wrote:

>Reed,
>
>Why not cancel rc1 and create rc2 fixing license header issue that Willem
>pointed?
>It seems it's better to be fixed.
>
>It also seems that no one from IPMC succeeded to build distribution from
>src (no sure for Luke though).
>
>I got the following build error (which might be gcc-5 version issue):
>
>[ 57%] Building CXX object
>projects/compiler-rt/lib/msan/CMakeFiles/clang_rt.msan-x86_64.dir/msan_int
>erceptors.cc.o
>
>/tmp/doris/apache-doris-0.9.0.rc01-incubating-src/thirdparty/src/llvm-3.4.
>2.src/projects/compiler-rt/lib/msan/msan_interceptors.cc:
>In function 'void __msan::InitializeInterceptors()':
>
>/tmp/doris/apache-doris-0.9.0.rc01-incubating-src/thirdparty/src/llvm-3.4.
>2.src/projects/compiler-rt/lib/msan/msan_interceptors.cc:1573:1:
>internal
>compiler error: Segmentation fault
>
> }
>
> ^
>
>Please submit a full bug report,
>
>with preprocessed source if appropriate.
>
>See  for instructions.
>
>projects/compiler-rt/lib/msan/CMakeFiles/clang_rt.msan-x86_64.dir/build.ma
>ke:134:
>recipe for target
>'projects/compiler-rt/lib/msan/CMakeFiles/clang_rt.msan-x86_64.dir/msan_in
>terceptors.cc.o'
>failed
>
>I used ubuntu xenial on docker on OSX.
>Software versions meets requirements (except Maven version) as seen in
>
>docker run ubuntu:xenial -it
>
>
>$ apt-get install wget openjdk-8-jdk maven gcc-5 bzip2 python cmake zip
>xz-utils patch byacc flex automake libtool g++
>
>
>root@d9e5b7017e7b:/tmp/doris/apache-doris-0.9.0.rc01-incubating-src# gcc
>--version | head -1
>
>gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609
>
>
>root@d9e5b7017e7b:/tmp/doris/apache-doris-0.9.0.rc01-incubating-src# java
>-version
>
>openjdk version "1.8.0_191"
>
>OpenJDK Runtime Environment (build
>1.8.0_191-8u191-b12-0ubuntu0.16.04.1-b12)
>
>OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
>
>
>root@d9e5b7017e7b:/tmp/doris/apache-doris-0.9.0.rc01-incubating-src#
>python
>--version
>
>Python 2.7.12
>
>
>root@d9e5b7017e7b:/tmp/doris/apache-doris-0.9.0.rc01-incubating-src# mvn
>--version
>
>Apache Maven 3.3.9
>
>
>root@d9e5b7017e7b:/tmp/doris/apache-doris-0.9.0.rc01-incubating-src# cmake
>--version
>
>cmake version 3.5.1
>
>
>$ ./build.sh
>
>
>
>Providing working Dockerfile would help to verify release by IPMC members.
>
>Thanks,
>Makoto
>
>2019年1月10日(木) 15:51 Li,De(BDG) :
>>
>> Hi,
>>
>> Does anyone help us to check and vote？
>> Now we got two +1(binding).
>> If needed we will cancel and call for next VOTE after fixed all issues
>> which Willem and Justin mentioned.
>>
>>
>> Best Regards,
>> Reed
>>
>> On 2018/12/29 上午10:36， "Li,De(BDG)"  wrote:
>>
>> >Hi Dave,
>> >
>> >I got it, thank you very much. Have a good trip.
>> >
>> >Best Regards,
>> >Reed
>> >
>> >On 2018/12/28 下午10:49， "Dave Meikle"  wrote:
>> >
>> >>Hi Reed,
>> >>
>> >>I am traveling just now so away from the desktop that I tested the
>>build
>> >>on.  I setup a clean virtual machine with Ubuntu 18.04 and tried from
>> >>scratch, resulting in a perfect build.  So must be something funky
>>with
>> >>my
>> >>configuration back at base - it's been upgraded a few times, so sorry
>for
>> >>the hassle.
>> >>
>> >>(NOTE: I tried to build on a remote Ubuntu 18.10 at first getting a
>> >>different error but it made sense due to the 3rd-party LLVM fails due
>>to
>> >>ustat depreciation in glibc).
>> >>
>> >>So +1 (binding) to the release.
>> >>
>> >>Cheers,
>> >>Dave
>> >>
>> >>On Thu, 27 Dec 2018 at 12:13, Li,De(BDG)  wrote:
>> >>
>> >>> Hi Dave,
>> >>>
>> >>> Thanks for your reply.
>> >>>
>> >>> The files of flat_map.h and json_to_pb.h are come from brpc, which
>> >>>should
>> >>> be installed in thirdparty/installed/include.
>> >>>
>> >>>
>> >>> It seems brpc is not been compiled and installed successfully.
>> >>>
>> >>> Could you remove brpc and retry build as following command ? It will
>> >>>help
>> >>> us to know what happed.
>> >>>
>> >>>
>> >>> $ cd
>> >>>
>>
/home/dmeikle/Development/Apache/incubator/release-review/apache-doris-
0
>> >>>.
>> >>>9.
>> >>> 0.rc01-incubating-src
>> >>> $ rm -f thirdparty/installed/lib/librdkafka.a
>> >>> $ rm -fr thirdparty/src/brpc-0.9.0*
>> >>> $ sh bu