mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Bannier" <benjamin.bann...@mesosphere.io>
Subject Re: Review Request 40445: Added linter for license headers in some file types.
Date Thu, 03 Dec 2015 00:02:52 GMT


> On Dec. 2, 2015, 11:31 p.m., Michael Park wrote:
> > support/mesos-style.py, line 6
> > <https://reviews.apache.org/r/40445/diff/6/?file=1150508#file1150508line6>
> >
> >     Why the introduction of the `print` function? Can't we just use `print` and
`.format`?

This was some drive-by future proofing. 

In python-3.0 `print` can only be called as a function (`print("foo")`) and the python-2.X
syntax used around here (`print "foo"`) isn't available anymore. The `print` function becomes
available in python-2.6.0, but in the shebang we pick whatever python interpreter is in `$PATH`.
If we can drop support for python-2.5 or earlier (not sure if it is still supported with what
is in here) we don't need to import it from `__future__`.


> On Dec. 2, 2015, 11:31 p.m., Michael Park wrote:
> > support/mesos-style.py, lines 83-84
> > <https://reviews.apache.org/r/40445/diff/6/?file=1150508#file1150508line83>
> >
> >     Is this meant to be commented out?

I removed this intentionally as it was purely `cpplint` specific (but missed nuking the commented
code). The idea here was that as `mesos-style` wraps other checks we should not need to act
like a thin wrapper around `cpplint` anymore. I added a more generic header below.


> On Dec. 2, 2015, 11:31 p.m., Michael Park wrote:
> > support/mesos-style.py, lines 95-96
> > <https://reviews.apache.org/r/40445/diff/6/?file=1150508#file1150508line95>
> >
> >     Why the change here?

The old regex matched interesting lines by just looking for a `:` somewhere which let the
total `cpplint` error count slip through (it was useful for a thin wrapper around `cpplint`).
We now calculate and output our own, combined error count so we should remove the one from
`cpplint`.

I replaced this construct with a simple regex.


> On Dec. 2, 2015, 11:31 p.m., Michael Park wrote:
> > support/mesos-style.py, line 112
> > <https://reviews.apache.org/r/40445/diff/6/?file=1150508#file1150508line112>
> >
> >     Do we allow arbitrary whitespace `\s`? or do we want to lock it down to exactly
one space character?

Good point, this can be tightened.


- Benjamin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/40445/#review108745
-----------------------------------------------------------


On Dec. 3, 2015, 12:02 a.m., Benjamin Bannier wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/40445/
> -----------------------------------------------------------
> 
> (Updated Dec. 3, 2015, 12:02 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Marco Massenzio, and Michael Park.
> 
> 
> Bugs: MESOS-3581
>     https://issues.apache.org/jira/browse/MESOS-3581
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Review: https://reviews.apache.org/r/40445
> 
> 
> Diffs
> -----
> 
>   support/mesos-style.py 66b45692c3c04f68358b63d52e4d87934f241bd7 
> 
> Diff: https://reviews.apache.org/r/40445/diff/
> 
> 
> Testing
> -------
> 
> Ran the a whole clean checkout through the linter with only one expected failure (`3rdparty/libprocess/stout/tests/protobuf_tests.proto`
which lacks a license).
> 
> 
> NOTE TO THE COMMITTER
> ---------------------
> 
> Before committing this, it is probably a good idea to check the whole code base again
and fix any new files which do not follow the current license style. The commits which originally
fixed this were
> 
> * fa36917 (mesos),
> * dc23756 (stout), and
> * 3539b7a (libprocess).
> 
> 
> Thanks,
> 
> Benjamin Bannier
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message