Podling Report Reminder - February 2017

[johndament]

Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 15 February 2017, 10:30 am PDT.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, February 01).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
the project or necessarily of its field
*   A list of the three most important issues to address in the move
towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.

This should be appended to the Incubator Wiki page at:

https://wiki.apache.org/incubator/February2017

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

Re: Can a Committer Please Carry the +2 and Submit this Change for me?

[Tim Armstrong]

Will do

On Wed, Feb 1, 2017 at 5:20 PM, Lars Volker  wrote:

> https://gerrit.cloudera.org/#/c/5611/12
>
> Patch Set 11 has a +2 from Marcel. In Patch Set 12 I rebased the change,
> replaced NULL with nullptr in one .cc file, and removed "// clang-format"
> control statements and TODOs.
>
> Thanks for the help, Lars
>

Can a Committer Please Carry the +2 and Submit this Change for me?

[Lars Volker]

https://gerrit.cloudera.org/#/c/5611/12

Patch Set 11 has a +2 from Marcel. In Patch Set 12 I rebased the change,
replaced NULL with nullptr in one .cc file, and removed "// clang-format"
control statements and TODOs.

Thanks for the help, Lars

Can a committer submit the verify job for...

[David Knupp]

https://gerrit.cloudera.org/#/c/5854/

Thanks.

--
David Knupp
Software Engineer
Cloudera
415-312-1049

Restarting Jenkins now

[Jim Apple]

Jenkins upgrade needed, so Lars and I are restarting Jenkins now. No
jobs are running at the moment.

Re: Python string formatting

[Lars Volker]

Thanks for the feedback. Printing all tests and making sure the names stay
the same is a very good idea.

I also just stumbled over yapf (https://github.com/google/yapf) which is a
python code formatter based on clang-format's logic. I will check that one
out too and try to come up with a patch for review when I have some spare
time.

On Wed, Feb 1, 2017 at 3:33 AM, Jim Apple  wrote:

> 1. Autopep8 might break a part of a test that is rarely run, so even
> if exhaustive works, something may have gotten messed up.
>
> 2. David pointed out that you can print the tests that are scheduled
> to be run by using pytest's dry-run option. You can then check that
> the number of tests (and maybe even the configuration and names of
> them?) stay the same after autopep8/
>
> 3. You could use https://docs.python.org/2/library/ast.html to make
> sure that only the whitespace is being changed and the AST is staying
> the same. That might be overkill.
>
> On Tue, Jan 31, 2017 at 5:53 PM, Lars Volker  wrote:
> > Thanks for pointing this out. Yes, I thought of trying autopep8 and
> running
> > an exhaustive build. I assumed it wouldn't break tests, but that is
> > probably a naive assumption. However, if nothing breaks in an exhaustive
> > run I'd be quite confident that nothing else will. That leaves the risk
> > that a change made by autopep8 disables a test so we don't notice the
> > breakage. Other than manually reviewing the code I don't have an idea how
> > to prevent that.
> >
> > Thoughts?
> >
> > On Tue, Jan 31, 2017 at 8:29 PM, Jim Apple  wrote:
> >
> >> Will you use autopep8? If so, how will you check that it doesn't break
> >> something on an infrequently-used codepath?
> >>
> >> On Tue, Jan 31, 2017 at 11:12 AM, Michael Brown 
> >> wrote:
> >> > I agree.
> >> >
> >> > On Tue, Jan 31, 2017 at 10:44 AM, Lars Volker 
> wrote:
> >> >> Thanks for the feedback here and in the review.
> >> >>
> >> >> I agree that we should aim for a style as close to PEP8 as possible.
> >> >> However, I also didn't want to overshoot and my first goal was to get
> >> some
> >> >> useful tooling set up, so that I don't have to constantly worry about
> >> >> formatting. Once I had figured out some tooling, I thought I might as
> >> well
> >> >> share it and solicit feedback.
> >> >>
> >> >> Regarding the next steps, I'm open for anything really. I didn't know
> >> about
> >> >> the --diff switch of flake8, that looks very useful. Even better of
> >> course
> >> >> would be, if all python code could be converted to PEP8.
> >> >>
> >> >> Here is a list of all PEP8 violations and their count, obtained with
> >> >> "pycodestyle --statistics -qq tests":
> >> >>
> >> >> 9017E111 indentation is not a multiple of four
> >> >> 902 E114 indentation is not a multiple of four (comment)
> >> >> 2   E116 unexpected indentation (comment)
> >> >> 24  E122 continuation line missing indentation or outdented
> >> >> 5   E124 closing bracket does not match visual indentation
> >> >> 105 E125 continuation line with same indent as next logical line
> >> >> 43  E127 continuation line over-indented for visual indent
> >> >> 1038E128 continuation line under-indented for visual indent
> >> >> 7   E131 continuation line unaligned for hanging indent
> >> >> 13  E201 whitespace after '('
> >> >> 8   E202 whitespace before ']'
> >> >> 55  E203 whitespace before ':'
> >> >> 5   E211 whitespace before '['
> >> >> 5   E221 multiple spaces before operator
> >> >> 7   E222 multiple spaces after operator
> >> >> 9   E225 missing whitespace around operator
> >> >> 1   E227 missing whitespace around bitwise or shift operator
> >> >> 127 E231 missing whitespace after ':'
> >> >> 157 E251 unexpected spaces around keyword / parameter equals
> >> >> 20  E261 at least two spaces before inline comment
> >> >> 21  E265 block comment should start with '# '
> >> >> 1   E266 too many leading '#' for block comment
> >> >> 1   E271 multiple spaces after keyword
> >> >> 4   E301 expected 1 blank line, found 0
> >> >> 313 E302 expected 2 blank lines, found 1
> >> >> 16  E303 too many blank lines (2)
> >> >> 13  E305 expected 2 blank lines after class or function
> definition,
> >> >> found 1
> >> >> 6   E306 expected 1 blank line before a nested definition, found
> 0
> >> >> 7   E402 module level import not at top of file
> >> >> 3800E501 line too long (80 > 79 characters)
> >> >> 278 E502 the backslash is redundant between brackets
> >> >> 87  E701 multiple statements on one line (colon)
> >> >> 74  E703 statement ends with a semicolon
> >> >> 12  E711 comparison to None should be 'if cond is None:'
> >> >> 9   E712 comparison to False should be 'if cond is False:' or 'if
> >> not
> >> >> cond:'
> >> >> 2   E713 test for membership should be