Re: Python API Docs
Hrm, looking again at the C++ wrapper code, I wonder if typical generated API docs will even work with the mainstream python documentation tools. I don't know the answer to that. Mike On Mon, Sep 12, 2016 at 8:09 PM, Mike Percy wrote: > It seems like everybody in Python land uses Sphinx and ReStructuredText > for documentation. However if this is just API docs then I don't know what > the benefit is to using a system like Sphinx over a core library like > pydoc, since we already have Asciidoc for the primary Kudu documentation. > > As long as the Python API docs are auto-generated, easy to build, and look > nice, I would be okay with whatever seems to work well. > > Mike > > On Mon, Sep 12, 2016 at 7:08 PM, Todd Lipcon wrote: > >> Hey Jordan, >> >> I guess the silence here means that no one has a strong opinion :) I >> wonder >> if the user@ list would have any more thoughts. >> >> I'm curious, though, what exactly this doc tool would do? If it's "prose" >> documentation, maybe we should stick to the adoc style that we use for the >> rest of the documentation, and just give the Python client its own page? >> If >> it's more strictly API docs, isn't that sort of built in using Python doc >> strings? (I'm not much of a Python programmer) >> >> -Todd >> >> On Sat, Sep 10, 2016 at 3:57 PM, Jordan Birdsell < >> jordantbirds...@gmail.com> >> wrote: >> >> > Anyone have any opinions/thoughts on Python API documentation? Pyspark, >> > pandas and others use Sphinx, so I'm thinking python devs would be >> pretty >> > comfortable with that format. >> > >> > Jordan >> > >> >> >> >> -- >> Todd Lipcon >> Software Engineer, Cloudera >> > >
Re: Python API Docs
It seems like everybody in Python land uses Sphinx and ReStructuredText for documentation. However if this is just API docs then I don't know what the benefit is to using a system like Sphinx over a core library like pydoc, since we already have Asciidoc for the primary Kudu documentation. As long as the Python API docs are auto-generated, easy to build, and look nice, I would be okay with whatever seems to work well. Mike On Mon, Sep 12, 2016 at 7:08 PM, Todd Lipcon wrote: > Hey Jordan, > > I guess the silence here means that no one has a strong opinion :) I wonder > if the user@ list would have any more thoughts. > > I'm curious, though, what exactly this doc tool would do? If it's "prose" > documentation, maybe we should stick to the adoc style that we use for the > rest of the documentation, and just give the Python client its own page? If > it's more strictly API docs, isn't that sort of built in using Python doc > strings? (I'm not much of a Python programmer) > > -Todd > > On Sat, Sep 10, 2016 at 3:57 PM, Jordan Birdsell < > jordantbirds...@gmail.com> > wrote: > > > Anyone have any opinions/thoughts on Python API documentation? Pyspark, > > pandas and others use Sphinx, so I'm thinking python devs would be pretty > > comfortable with that format. > > > > Jordan > > > > > > -- > Todd Lipcon > Software Engineer, Cloudera >
Re: Config file comments generated by GPL tools
Yes, exactly -- the client_api.footer.in file. Thanks for clarifying on this! Best regards, Alexey On Mon, Sep 12, 2016 at 7:05 PM, Todd Lipcon wrote: > On Mon, Sep 12, 2016 at 7:03 PM, Alexey Serbin > wrote: > > > Todd, > > > > Thank you for spotting the issue. > > > > Yep, we keep the directives which we changed to non-default value(s). > > > > For those, I used those auto-generated comments and added some > description > > explaining the reason for overriding. > > > > I'll remove the auto-generated part from those comments. Will send a > patch > > for review in a moment. > > > > BTW, could somebody assess the footer of the auto-generated docs? We > have > > an Apache copyright there along with 'Generated by Doxygen ...'. It > might > > make sense to verify that we are OK there as well. > > > > You mean docs/support/doxygen/client_api.footer.in right? I was just in > the > process of adding it to the RAT exclude list. > > I don't think this one's problematic. Doxygen explicitly states that the > generated docs are licensed the same as the source used to generate them. > > -Todd > > > > > > > > Thanks, > > > > Alexey > > > > On Mon, Sep 12, 2016 at 11:02 AM, Todd Lipcon wrote: > > > > > It looks like this licensing question may affect us too. Alexey, did > you > > > use the same generaotr/template to create our doxygen config files? > Maybe > > > we should remove some of the comments to be sure we're on the right > side > > of > > > the licensing before our 1.0 release? > > > > > > -Todd > > > > > > > > > -- Forwarded message -- > > > From: Ryan Blue > > > Date: Mon, Sep 12, 2016 at 10:58 AM > > > Subject: Re: Config file comments generated by GPL tools > > > To: legal-disc...@apache.org > > > Cc: "dev@impala" > > > > > > > > > We had the same issue last year when we audited Avro's license > > > documentation. This is tracked at LEGAL-224 [1] and we did reach out to > > > doxygen [2]. The doxygen developer, Dimitri clarified that he doesn't > > > intend for the doxy config files to be GPL, but hasn't clarified the > > > license to my knowledge. In the end, we created a new config file with > > all > > > of the non-default settings and none of the nice descriptions you get > > with > > > the generated file. > > > > > > rb > > > > > > > > > [1]: https://issues.apache.org/jira/browse/LEGAL-224 > > > [2]: https://bugzilla.gnome.org/show_bug.cgi?id=755135 > > > > > > On Mon, Sep 12, 2016 at 10:52 AM, Todd Lipcon > wrote: > > > > > > > Maybe it's worth reaching out to the doxygen authors and ask them to > > add > > > a > > > > header on that file saying that the prose in the documentation may be > > > > licensed under a different more permissive license? (e.g MIT/BSD?) > > > > > > > > -Todd > > > > > > > > On Mon, Sep 12, 2016 at 9:38 AM, Jim Apple > > wrote: > > > > > > > >> Apache Impala (incubating) includes a file that includes > substantial > > > >> portions containing prose that is only licensed, as far as I can > tell, > > > in > > > >> a > > > >> GPL way: > > > >> > > > >> https://git-wip-us.apache.org/repos/asf?p=incubator-impala.g > > > >> it;a=blob;f=be/.impala.doxy;h=4b81af4bab3c04ab60f84e29b70790 > > > >> 26e9959bf2;hb=fcb5c6821d1a0b2d49212dd791c4556dd5ac6c9e > > > >> > > > >> https://github.com/doxygen/doxygen/blob/b38efd15eb69b2b61e05 > > > >> ee09fc9ed6474cc8b1da/src/config.xml > > > >> > > > >> Can we keep that config file in our project as-is, or do we need to > > > remove > > > >> the prose, or perhaps some third thing? > > > >> > > > >> Thanks for your help, > > > >> Jim > > > >> > > > > > > > > > > > > > > > > -- > > > > Todd Lipcon > > > > Software Engineer, Cloudera > > > > > > > > > > > > > > > > -- > > > Ryan Blue > > > Software Engineer > > > Netflix > > > > > > > > > > > > -- > > > Todd Lipcon > > > Software Engineer, Cloudera > > > > > > > > > -- > Todd Lipcon > Software Engineer, Cloudera >
Re: Python API Docs
Hey Jordan, I guess the silence here means that no one has a strong opinion :) I wonder if the user@ list would have any more thoughts. I'm curious, though, what exactly this doc tool would do? If it's "prose" documentation, maybe we should stick to the adoc style that we use for the rest of the documentation, and just give the Python client its own page? If it's more strictly API docs, isn't that sort of built in using Python doc strings? (I'm not much of a Python programmer) -Todd On Sat, Sep 10, 2016 at 3:57 PM, Jordan Birdsell wrote: > Anyone have any opinions/thoughts on Python API documentation? Pyspark, > pandas and others use Sphinx, so I'm thinking python devs would be pretty > comfortable with that format. > > Jordan > -- Todd Lipcon Software Engineer, Cloudera
Re: Config file comments generated by GPL tools
On Mon, Sep 12, 2016 at 7:03 PM, Alexey Serbin wrote: > Todd, > > Thank you for spotting the issue. > > Yep, we keep the directives which we changed to non-default value(s). > > For those, I used those auto-generated comments and added some description > explaining the reason for overriding. > > I'll remove the auto-generated part from those comments. Will send a patch > for review in a moment. > > BTW, could somebody assess the footer of the auto-generated docs? We have > an Apache copyright there along with 'Generated by Doxygen ...'. It might > make sense to verify that we are OK there as well. > You mean docs/support/doxygen/client_api.footer.in right? I was just in the process of adding it to the RAT exclude list. I don't think this one's problematic. Doxygen explicitly states that the generated docs are licensed the same as the source used to generate them. -Todd > > > Thanks, > > Alexey > > On Mon, Sep 12, 2016 at 11:02 AM, Todd Lipcon wrote: > > > It looks like this licensing question may affect us too. Alexey, did you > > use the same generaotr/template to create our doxygen config files? Maybe > > we should remove some of the comments to be sure we're on the right side > of > > the licensing before our 1.0 release? > > > > -Todd > > > > > > -- Forwarded message -- > > From: Ryan Blue > > Date: Mon, Sep 12, 2016 at 10:58 AM > > Subject: Re: Config file comments generated by GPL tools > > To: legal-disc...@apache.org > > Cc: "dev@impala" > > > > > > We had the same issue last year when we audited Avro's license > > documentation. This is tracked at LEGAL-224 [1] and we did reach out to > > doxygen [2]. The doxygen developer, Dimitri clarified that he doesn't > > intend for the doxy config files to be GPL, but hasn't clarified the > > license to my knowledge. In the end, we created a new config file with > all > > of the non-default settings and none of the nice descriptions you get > with > > the generated file. > > > > rb > > > > > > [1]: https://issues.apache.org/jira/browse/LEGAL-224 > > [2]: https://bugzilla.gnome.org/show_bug.cgi?id=755135 > > > > On Mon, Sep 12, 2016 at 10:52 AM, Todd Lipcon wrote: > > > > > Maybe it's worth reaching out to the doxygen authors and ask them to > add > > a > > > header on that file saying that the prose in the documentation may be > > > licensed under a different more permissive license? (e.g MIT/BSD?) > > > > > > -Todd > > > > > > On Mon, Sep 12, 2016 at 9:38 AM, Jim Apple > wrote: > > > > > >> Apache Impala (incubating) includes a file that includes substantial > > >> portions containing prose that is only licensed, as far as I can tell, > > in > > >> a > > >> GPL way: > > >> > > >> https://git-wip-us.apache.org/repos/asf?p=incubator-impala.g > > >> it;a=blob;f=be/.impala.doxy;h=4b81af4bab3c04ab60f84e29b70790 > > >> 26e9959bf2;hb=fcb5c6821d1a0b2d49212dd791c4556dd5ac6c9e > > >> > > >> https://github.com/doxygen/doxygen/blob/b38efd15eb69b2b61e05 > > >> ee09fc9ed6474cc8b1da/src/config.xml > > >> > > >> Can we keep that config file in our project as-is, or do we need to > > remove > > >> the prose, or perhaps some third thing? > > >> > > >> Thanks for your help, > > >> Jim > > >> > > > > > > > > > > > > -- > > > Todd Lipcon > > > Software Engineer, Cloudera > > > > > > > > > > > -- > > Ryan Blue > > Software Engineer > > Netflix > > > > > > > > -- > > Todd Lipcon > > Software Engineer, Cloudera > > > -- Todd Lipcon Software Engineer, Cloudera
Re: Config file comments generated by GPL tools
Todd, Thank you for spotting the issue. Yep, we keep the directives which we changed to non-default value(s). For those, I used those auto-generated comments and added some description explaining the reason for overriding. I'll remove the auto-generated part from those comments. Will send a patch for review in a moment. BTW, could somebody assess the footer of the auto-generated docs? We have an Apache copyright there along with 'Generated by Doxygen ...'. It might make sense to verify that we are OK there as well. Thanks, Alexey On Mon, Sep 12, 2016 at 11:02 AM, Todd Lipcon wrote: > It looks like this licensing question may affect us too. Alexey, did you > use the same generaotr/template to create our doxygen config files? Maybe > we should remove some of the comments to be sure we're on the right side of > the licensing before our 1.0 release? > > -Todd > > > -- Forwarded message -- > From: Ryan Blue > Date: Mon, Sep 12, 2016 at 10:58 AM > Subject: Re: Config file comments generated by GPL tools > To: legal-disc...@apache.org > Cc: "dev@impala" > > > We had the same issue last year when we audited Avro's license > documentation. This is tracked at LEGAL-224 [1] and we did reach out to > doxygen [2]. The doxygen developer, Dimitri clarified that he doesn't > intend for the doxy config files to be GPL, but hasn't clarified the > license to my knowledge. In the end, we created a new config file with all > of the non-default settings and none of the nice descriptions you get with > the generated file. > > rb > > > [1]: https://issues.apache.org/jira/browse/LEGAL-224 > [2]: https://bugzilla.gnome.org/show_bug.cgi?id=755135 > > On Mon, Sep 12, 2016 at 10:52 AM, Todd Lipcon wrote: > > > Maybe it's worth reaching out to the doxygen authors and ask them to add > a > > header on that file saying that the prose in the documentation may be > > licensed under a different more permissive license? (e.g MIT/BSD?) > > > > -Todd > > > > On Mon, Sep 12, 2016 at 9:38 AM, Jim Apple wrote: > > > >> Apache Impala (incubating) includes a file that includes substantial > >> portions containing prose that is only licensed, as far as I can tell, > in > >> a > >> GPL way: > >> > >> https://git-wip-us.apache.org/repos/asf?p=incubator-impala.g > >> it;a=blob;f=be/.impala.doxy;h=4b81af4bab3c04ab60f84e29b70790 > >> 26e9959bf2;hb=fcb5c6821d1a0b2d49212dd791c4556dd5ac6c9e > >> > >> https://github.com/doxygen/doxygen/blob/b38efd15eb69b2b61e05 > >> ee09fc9ed6474cc8b1da/src/config.xml > >> > >> Can we keep that config file in our project as-is, or do we need to > remove > >> the prose, or perhaps some third thing? > >> > >> Thanks for your help, > >> Jim > >> > > > > > > > > -- > > Todd Lipcon > > Software Engineer, Cloudera > > > > > > -- > Ryan Blue > Software Engineer > Netflix > > > > -- > Todd Lipcon > Software Engineer, Cloudera >
Re: [ANNOUNCE] Two new Kudu committer/PMC members
Awesome job Alexey/Will, congrats ! > On Sep 12, 2016, at 3:55 PM, Todd Lipcon wrote: > > Hi Kudu community, > > It's my great pleasure to announce that the PMC has voted to add both Alexey > Serbin and Will Berkeley as committers and PMC members. > > Alexey has been contributing for a few months, including developing some > pretty meaty (and tricky) additions. Two of note are the addition of doxygen > for our client APIs, as well as the implementation of AUTO_FLUSH_BACKGROUND > in C++. He has also been quite active in reviews recently, having reviewed > 40+ patches in the last couple months. He also contributed by testing and > voting on the recent 0.10 release. > > Will has been a great contributor as well, spending a lot of time in areas > that don't get as much love from others. In particular, he's made several > fixes to the web UIs, has greatly improved the Flume integration, and has > been burning down a lot of long-standing bugs recently. Will also spends a > lot of his time outside of Kudu working with users and always has good input > on what our user community will think of a feature. Like Alexey, Will also > participated in the 0.10 release process. > > Both of these community members have already been "acting the part" through > their contributions detailed above, and the PMC is excited to continue > working with them in their expanded roles. > > Please join me in congratulating them! > > -Todd
Re: [ANNOUNCE] Two new Kudu committer/PMC members
Congratulations Alexey and Will -Jake On Mon, Sep 12, 2016 at 6:55 PM, Todd Lipcon wrote: > Hi Kudu community, > > It's my great pleasure to announce that the PMC has voted to add both > Alexey Serbin and Will Berkeley as committers and PMC members. > > Alexey has been contributing for a few months, including developing some > pretty meaty (and tricky) additions. Two of note are the addition of > doxygen for our client APIs, as well as the implementation of > AUTO_FLUSH_BACKGROUND in C++. He has also been quite active in reviews > recently, having reviewed 40+ patches in the last couple months. He also > contributed by testing and voting on the recent 0.10 release. > > Will has been a great contributor as well, spending a lot of time in areas > that don't get as much love from others. In particular, he's made several > fixes to the web UIs, has greatly improved the Flume integration, and has > been burning down a lot of long-standing bugs recently. Will also spends a > lot of his time outside of Kudu working with users and always has good > input on what our user community will think of a feature. Like Alexey, Will > also participated in the 0.10 release process. > > Both of these community members have already been "acting the part" through > their contributions detailed above, and the PMC is excited to continue > working with them in their expanded roles. > > Please join me in congratulating them! > > -Todd >
Re: [ANNOUNCE] Two new Kudu committer/PMC members
Congrats! On Mon, Sep 12, 2016 at 4:27 PM, Jordan Birdsell wrote: > Congrats > > On Mon, Sep 12, 2016 at 7:09 PM Brock Noland wrote: > >> Congratulations!! >> >> On Mon, Sep 12, 2016 at 6:06 PM, David Alves >> wrote: >> >>> Congrats Alexey and Will!! >>> >>> On Mon, Sep 12, 2016 at 3:55 PM, Todd Lipcon wrote: >>> >>> > Hi Kudu community, >>> > >>> > It's my great pleasure to announce that the PMC has voted to add both >>> > Alexey Serbin and Will Berkeley as committers and PMC members. >>> > >>> > Alexey has been contributing for a few months, including developing >>> some >>> > pretty meaty (and tricky) additions. Two of note are the addition of >>> > doxygen for our client APIs, as well as the implementation of >>> > AUTO_FLUSH_BACKGROUND in C++. He has also been quite active in reviews >>> > recently, having reviewed 40+ patches in the last couple months. He >>> also >>> > contributed by testing and voting on the recent 0.10 release. >>> > >>> > Will has been a great contributor as well, spending a lot of time in >>> areas >>> > that don't get as much love from others. In particular, he's made >>> several >>> > fixes to the web UIs, has greatly improved the Flume integration, and >>> has >>> > been burning down a lot of long-standing bugs recently. Will also >>> spends a >>> > lot of his time outside of Kudu working with users and always has good >>> > input on what our user community will think of a feature. Like Alexey, >>> Will >>> > also participated in the 0.10 release process. >>> > >>> > Both of these community members have already been "acting the part" >>> > through their contributions detailed above, and the PMC is excited to >>> > continue working with them in their expanded roles. >>> > >>> > Please join me in congratulating them! >>> > >>> > -Todd >>> > >>> >> >>
Re: [ANNOUNCE] Two new Kudu committer/PMC members
Congrats Alexey and Will! Great work. Best, Mike On Mon, Sep 12, 2016 at 3:55 PM, Todd Lipcon wrote: > Hi Kudu community, > > It's my great pleasure to announce that the PMC has voted to add both > Alexey Serbin and Will Berkeley as committers and PMC members. > > Alexey has been contributing for a few months, including developing some > pretty meaty (and tricky) additions. Two of note are the addition of > doxygen for our client APIs, as well as the implementation of > AUTO_FLUSH_BACKGROUND in C++. He has also been quite active in reviews > recently, having reviewed 40+ patches in the last couple months. He also > contributed by testing and voting on the recent 0.10 release. > > Will has been a great contributor as well, spending a lot of time in areas > that don't get as much love from others. In particular, he's made several > fixes to the web UIs, has greatly improved the Flume integration, and has > been burning down a lot of long-standing bugs recently. Will also spends a > lot of his time outside of Kudu working with users and always has good > input on what our user community will think of a feature. Like Alexey, Will > also participated in the 0.10 release process. > > Both of these community members have already been "acting the part" > through their contributions detailed above, and the PMC is excited to > continue working with them in their expanded roles. > > Please join me in congratulating them! > > -Todd >
Re: [ANNOUNCE] Two new Kudu committer/PMC members
Congrats On Mon, Sep 12, 2016 at 7:09 PM Brock Noland wrote: > Congratulations!! > > On Mon, Sep 12, 2016 at 6:06 PM, David Alves > wrote: > >> Congrats Alexey and Will!! >> >> On Mon, Sep 12, 2016 at 3:55 PM, Todd Lipcon wrote: >> >> > Hi Kudu community, >> > >> > It's my great pleasure to announce that the PMC has voted to add both >> > Alexey Serbin and Will Berkeley as committers and PMC members. >> > >> > Alexey has been contributing for a few months, including developing some >> > pretty meaty (and tricky) additions. Two of note are the addition of >> > doxygen for our client APIs, as well as the implementation of >> > AUTO_FLUSH_BACKGROUND in C++. He has also been quite active in reviews >> > recently, having reviewed 40+ patches in the last couple months. He also >> > contributed by testing and voting on the recent 0.10 release. >> > >> > Will has been a great contributor as well, spending a lot of time in >> areas >> > that don't get as much love from others. In particular, he's made >> several >> > fixes to the web UIs, has greatly improved the Flume integration, and >> has >> > been burning down a lot of long-standing bugs recently. Will also >> spends a >> > lot of his time outside of Kudu working with users and always has good >> > input on what our user community will think of a feature. Like Alexey, >> Will >> > also participated in the 0.10 release process. >> > >> > Both of these community members have already been "acting the part" >> > through their contributions detailed above, and the PMC is excited to >> > continue working with them in their expanded roles. >> > >> > Please join me in congratulating them! >> > >> > -Todd >> > >> > >
Re: [ANNOUNCE] Two new Kudu committer/PMC members
Congratulations!! On Mon, Sep 12, 2016 at 6:06 PM, David Alves wrote: > Congrats Alexey and Will!! > > On Mon, Sep 12, 2016 at 3:55 PM, Todd Lipcon wrote: > > > Hi Kudu community, > > > > It's my great pleasure to announce that the PMC has voted to add both > > Alexey Serbin and Will Berkeley as committers and PMC members. > > > > Alexey has been contributing for a few months, including developing some > > pretty meaty (and tricky) additions. Two of note are the addition of > > doxygen for our client APIs, as well as the implementation of > > AUTO_FLUSH_BACKGROUND in C++. He has also been quite active in reviews > > recently, having reviewed 40+ patches in the last couple months. He also > > contributed by testing and voting on the recent 0.10 release. > > > > Will has been a great contributor as well, spending a lot of time in > areas > > that don't get as much love from others. In particular, he's made several > > fixes to the web UIs, has greatly improved the Flume integration, and has > > been burning down a lot of long-standing bugs recently. Will also spends > a > > lot of his time outside of Kudu working with users and always has good > > input on what our user community will think of a feature. Like Alexey, > Will > > also participated in the 0.10 release process. > > > > Both of these community members have already been "acting the part" > > through their contributions detailed above, and the PMC is excited to > > continue working with them in their expanded roles. > > > > Please join me in congratulating them! > > > > -Todd > > >
Re: [ANNOUNCE] Two new Kudu committer/PMC members
Congrats Alexey and Will!! On Mon, Sep 12, 2016 at 3:55 PM, Todd Lipcon wrote: > Hi Kudu community, > > It's my great pleasure to announce that the PMC has voted to add both > Alexey Serbin and Will Berkeley as committers and PMC members. > > Alexey has been contributing for a few months, including developing some > pretty meaty (and tricky) additions. Two of note are the addition of > doxygen for our client APIs, as well as the implementation of > AUTO_FLUSH_BACKGROUND in C++. He has also been quite active in reviews > recently, having reviewed 40+ patches in the last couple months. He also > contributed by testing and voting on the recent 0.10 release. > > Will has been a great contributor as well, spending a lot of time in areas > that don't get as much love from others. In particular, he's made several > fixes to the web UIs, has greatly improved the Flume integration, and has > been burning down a lot of long-standing bugs recently. Will also spends a > lot of his time outside of Kudu working with users and always has good > input on what our user community will think of a feature. Like Alexey, Will > also participated in the 0.10 release process. > > Both of these community members have already been "acting the part" > through their contributions detailed above, and the PMC is excited to > continue working with them in their expanded roles. > > Please join me in congratulating them! > > -Todd >
Re: [ANNOUNCE] Two new Kudu committer/PMC members
Congrats guys! On Mon, Sep 12, 2016 at 3:55 PM, Todd Lipcon wrote: > Hi Kudu community, > > It's my great pleasure to announce that the PMC has voted to add both > Alexey Serbin and Will Berkeley as committers and PMC members. > > Alexey has been contributing for a few months, including developing some > pretty meaty (and tricky) additions. Two of note are the addition of > doxygen for our client APIs, as well as the implementation of > AUTO_FLUSH_BACKGROUND in C++. He has also been quite active in reviews > recently, having reviewed 40+ patches in the last couple months. He also > contributed by testing and voting on the recent 0.10 release. > > Will has been a great contributor as well, spending a lot of time in areas > that don't get as much love from others. In particular, he's made several > fixes to the web UIs, has greatly improved the Flume integration, and has > been burning down a lot of long-standing bugs recently. Will also spends a > lot of his time outside of Kudu working with users and always has good > input on what our user community will think of a feature. Like Alexey, Will > also participated in the 0.10 release process. > > Both of these community members have already been "acting the part" through > their contributions detailed above, and the PMC is excited to continue > working with them in their expanded roles. > > Please join me in congratulating them! > > -Todd
[ANNOUNCE] Two new Kudu committer/PMC members
Hi Kudu community, It's my great pleasure to announce that the PMC has voted to add both Alexey Serbin and Will Berkeley as committers and PMC members. Alexey has been contributing for a few months, including developing some pretty meaty (and tricky) additions. Two of note are the addition of doxygen for our client APIs, as well as the implementation of AUTO_FLUSH_BACKGROUND in C++. He has also been quite active in reviews recently, having reviewed 40+ patches in the last couple months. He also contributed by testing and voting on the recent 0.10 release. Will has been a great contributor as well, spending a lot of time in areas that don't get as much love from others. In particular, he's made several fixes to the web UIs, has greatly improved the Flume integration, and has been burning down a lot of long-standing bugs recently. Will also spends a lot of his time outside of Kudu working with users and always has good input on what our user community will think of a feature. Like Alexey, Will also participated in the 0.10 release process. Both of these community members have already been "acting the part" through their contributions detailed above, and the PMC is excited to continue working with them in their expanded roles. Please join me in congratulating them! -Todd
Re: Potential Java client issue?
David and I chatted about this briefly offline. We think we should probably revert the original bug fix from the 1.0.0 branch, since we're not 100% confident in the "fix of the fix". This isn't a regression, so will just have to be a known bug in 1.0.0, to be addressed in 1.1 (or a 1.0.1 if we decide to do one) -Todd On Sun, Sep 11, 2016 at 10:03 PM, David Alves wrote: > Look at it for a bit and think I figured out the problem and fixed it (put > on the ip2client map is synchronized with the put on client2tablets so it > makes sense that the removing is too). > The problem is that I'm having a hard time reproing the first failure. > I'll ask JD's opinion tomorrow. > > -david > > On Sun, Sep 11, 2016 at 8:25 PM, Todd Lipcon wrote: > > > I just had a Jenkins job time out when TestAsyncKuduSession java test > took > > an hour: > > http://104.196.14.100/job/kudu-gerrit/3359/BUILD_TYPE=RELEASE/console > > > > Looking at the test output > > http://104.196.14.100/job/kudu-gerrit/3359/BUILD_TYPE= > > RELEASE/artifact/java/kudu-client/target/surefire- > reports/org.apache.kudu. > > client.TestAsyncKuduSession-output.txt > > , > > I see the following NPE after an unexpected disconnect: > > > > 00:50:11.056 [WARN - main] (AsyncKuduSession.java:334) unexpected > > tablet lookup failure for operation KuduRpc(method=Write, tablet=null, > > attempt=0, DeadlineTracker(timeout=0, elapsed=32), > > Deferred@1645276019(state=PENDING, result=null, callback=, > > errback=)) row_key=(int32 key=1) > > java.lang.NullPointerException > > at org.apache.kudu.client.AsyncKuduClient$RemoteTablet. > > addTabletClient(AsyncKuduClient.java:2089) > > at org.apache.kudu.client.AsyncKuduClient$RemoteTablet. > > refreshTabletClients(AsyncKuduClient.java:2049) > > at org.apache.kudu.client.AsyncKuduClient.discoverTablets( > > AsyncKuduClient.java:1404) > > at org.apache.kudu.client.AsyncKuduClient$MasterLookupCB.call( > > AsyncKuduClient.java:1317) > > at org.apache.kudu.client.AsyncKuduClient$MasterLookupCB.call( > > AsyncKuduClient.java:1297) > > at com.stumbleupon.async.Deferred.doCall(Deferred.java:1280) > > at com.stumbleupon.async.Deferred.addCallbacks( > Deferred.java:685) > > at com.stumbleupon.async.Deferred.addCallback(Deferred.java:721) > > at org.apache.kudu.client.AsyncKuduClient.locateTablet( > > AsyncKuduClient.java:1106) > > at org.apache.kudu.client.AsyncKuduClient.loopLocateTable( > > AsyncKuduClient.java:1206) > > at org.apache.kudu.client.AsyncKuduClient.locateTable( > > AsyncKuduClient.java:1241) > > at org.apache.kudu.client.AsyncKuduClient.getTabletLocation( > > AsyncKuduClient.java:1450) > > at org.apache.kudu.client.AsyncKuduSession.apply( > > AsyncKuduSession.java:509) > > at org.apache.kudu.client.TestAsyncKuduSession. > > testInsertIntoUnavailableTablet(TestAsyncKuduSession.java:162) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at sun.reflect.NativeMethodAccessorImpl.invoke( > > NativeMethodAccessorImpl.java:57) > > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > > DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:606) > > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall( > > FrameworkMethod.java:47) > > at org.junit.internal.runners.model.ReflectiveCallable.run( > > ReflectiveCallable.java:12) > > at org.junit.runners.model.FrameworkMethod.invokeExplosively( > > FrameworkMethod.java:44) > > at org.junit.internal.runners.statements.InvokeMethod. > > evaluate(InvokeMethod.java:17) > > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > > > > > > I'm guessing this is an artifact > > of d5082d8ec1218e3f3bd2143d117ddd64772a6162 which was committed Friday. > > David, since you committed that change, do you mind looking into this and > > decide if we should revert this patch for 1.0 so we have some more time > to > > thoroughly test it? > > > > -Todd > > -- > > Todd Lipcon > > Software Engineer, Cloudera > > > -- Todd Lipcon Software Engineer, Cloudera
Fwd: Config file comments generated by GPL tools
It looks like this licensing question may affect us too. Alexey, did you use the same generaotr/template to create our doxygen config files? Maybe we should remove some of the comments to be sure we're on the right side of the licensing before our 1.0 release? -Todd -- Forwarded message -- From: Ryan Blue Date: Mon, Sep 12, 2016 at 10:58 AM Subject: Re: Config file comments generated by GPL tools To: legal-disc...@apache.org Cc: "dev@impala" We had the same issue last year when we audited Avro's license documentation. This is tracked at LEGAL-224 [1] and we did reach out to doxygen [2]. The doxygen developer, Dimitri clarified that he doesn't intend for the doxy config files to be GPL, but hasn't clarified the license to my knowledge. In the end, we created a new config file with all of the non-default settings and none of the nice descriptions you get with the generated file. rb [1]: https://issues.apache.org/jira/browse/LEGAL-224 [2]: https://bugzilla.gnome.org/show_bug.cgi?id=755135 On Mon, Sep 12, 2016 at 10:52 AM, Todd Lipcon wrote: > Maybe it's worth reaching out to the doxygen authors and ask them to add a > header on that file saying that the prose in the documentation may be > licensed under a different more permissive license? (e.g MIT/BSD?) > > -Todd > > On Mon, Sep 12, 2016 at 9:38 AM, Jim Apple wrote: > >> Apache Impala (incubating) includes a file that includes substantial >> portions containing prose that is only licensed, as far as I can tell, in >> a >> GPL way: >> >> https://git-wip-us.apache.org/repos/asf?p=incubator-impala.g >> it;a=blob;f=be/.impala.doxy;h=4b81af4bab3c04ab60f84e29b70790 >> 26e9959bf2;hb=fcb5c6821d1a0b2d49212dd791c4556dd5ac6c9e >> >> https://github.com/doxygen/doxygen/blob/b38efd15eb69b2b61e05 >> ee09fc9ed6474cc8b1da/src/config.xml >> >> Can we keep that config file in our project as-is, or do we need to remove >> the prose, or perhaps some third thing? >> >> Thanks for your help, >> Jim >> > > > > -- > Todd Lipcon > Software Engineer, Cloudera > -- Ryan Blue Software Engineer Netflix -- Todd Lipcon Software Engineer, Cloudera
KUDU-1604 - [python] Fix bug getting table column by index
Hey all, Submitted a patch for a little bug in the python client that was causing incorrect column names to be returned when getting a column from a table by index. Can someone take a look? https://gerrit.cloudera.org/#/c/4378/ Thanks, Jordan
