Thanks for the broad support! I created a Jira issue:
https://issues.apache.org/jira/browse/FLINK-20651
For the timing, I agree with Piotr.
Best,
Aljoscha
On 17.12.20 11:45, Piotr Nowojski wrote:
Hi,
+1 for this kind of approach (with reformatting the code base).
Maybe ideally it would be b
Hi,
+1 for this kind of approach (with reformatting the code base).
Maybe ideally it would be best to do it either next week, or between
December 24th and January 1st? Maybe such timing would minimize the number
of open PRs that would need to be rewritten/modified to comply? I'm afraid
pending PR
+1
Cheers,
Till
On Thu, Dec 17, 2020 at 7:59 AM Tzu-Li (Gordon) Tai
wrote:
> +1
>
> On Thu, Dec 17, 2020, 2:56 PM Zhu Zhu wrote:
>
> > +1. It can be very helpful for future development. Thanks for driving
> this!
> >
> > Thanks,
> > Zhu
> >
> > Yangze Guo 于2020年12月17日周四 下午2:48写道：
> >
> > > +1
+1
On Thu, Dec 17, 2020, 2:56 PM Zhu Zhu wrote:
> +1. It can be very helpful for future development. Thanks for driving this!
>
> Thanks,
> Zhu
>
> Yangze Guo 于2020年12月17日周四 下午2:48写道：
>
> > +1
> > Thanks for driving this!
> >
> > Best,
> > Yangze Guo
> >
> > On Thu, Dec 17, 2020 at 2:39 PM Igal
+1. It can be very helpful for future development. Thanks for driving this!
Thanks,
Zhu
Yangze Guo 于2020年12月17日周四 下午2:48写道：
> +1
> Thanks for driving this!
>
> Best,
> Yangze Guo
>
> On Thu, Dec 17, 2020 at 2:39 PM Igal Shilman wrote:
> >
> > +1 it works really well in StateFun for quite some
+1
Thanks for driving this!
Best,
Yangze Guo
On Thu, Dec 17, 2020 at 2:39 PM Igal Shilman wrote:
>
> +1 it works really well in StateFun for quite some time.
>
> On Thursday, December 17, 2020, Wei Zhong wrote:
>
> > +1 for the coding style automation. Thanks for driving this!
> >
> > Best,
> >
+1 it works really well in StateFun for quite some time.
On Thursday, December 17, 2020, Wei Zhong wrote:
> +1 for the coding style automation. Thanks for driving this!
>
> Best,
> Wei
>
> > 在 2020年12月17日，10:10，Xingbo Huang 写道：
> >
> > +1 asap. Spotless can greatly help us save the time of fixi
+1 for the coding style automation. Thanks for driving this!
Best,
Wei
> 在 2020年12月17日，10:10，Xingbo Huang 写道：
>
> +1 asap. Spotless can greatly help us save the time of fixing checkstyle
> errors.
>
> Best,
> Xingbo
>
> Kostas Kloudas 于2020年12月17日周四 上午4:14写道：
>
>> +1 asap from my side as we
+1 asap. Spotless can greatly help us save the time of fixing checkstyle
errors.
Best,
Xingbo
Kostas Kloudas 于2020年12月17日周四 上午4:14写道：
> +1 asap from my side as well.
>
> On Wed, Dec 16, 2020 at 8:04 PM Arvid Heise wrote:
> >
> > +1 asap.
> >
> > On Wed, Dec 16, 2020 at 7:44 PM Robert Metzger
+1 asap from my side as well.
On Wed, Dec 16, 2020 at 8:04 PM Arvid Heise wrote:
>
> +1 asap.
>
> On Wed, Dec 16, 2020 at 7:44 PM Robert Metzger wrote:
>
> > +1
> >
> > Thanks for driving this.
> >
> > On Wed, Dec 16, 2020 at 7:33 PM Chesnay Schepler
> > wrote:
> >
> > > +1 to set this up ASAP.
+1 asap.
On Wed, Dec 16, 2020 at 7:44 PM Robert Metzger wrote:
> +1
>
> Thanks for driving this.
>
> On Wed, Dec 16, 2020 at 7:33 PM Chesnay Schepler
> wrote:
>
> > +1 to set this up ASAP. Now's a good time to (finally) finalize this
> > effort with a new release cycle having started and christ
+1 for better coding style automation
I see spotless works very well in other projects.
On Wed, Dec 16, 2020 at 10:45 AM Robert Metzger wrote:
> +1
>
> Thanks for driving this.
>
> On Wed, Dec 16, 2020 at 7:33 PM Chesnay Schepler
> wrote:
>
> > +1 to set this up ASAP. Now's a good time to (fin
+1
Thanks for driving this.
On Wed, Dec 16, 2020 at 7:33 PM Chesnay Schepler wrote:
> +1 to set this up ASAP. Now's a good time to (finally) finalize this
> effort with a new release cycle having started and christmas/vacations
> being around the corner.
>
> On 12/16/2020 7:20 PM, Aljoscha Kret
+1 to set this up ASAP. Now's a good time to (finally) finalize this
effort with a new release cycle having started and christmas/vacations
being around the corner.
On 12/16/2020 7:20 PM, Aljoscha Krettek wrote:
Let's try and conclude this discussion! I've prepared a PoC that uses
Spotless wit
Let's try and conclude this discussion! I've prepared a PoC that uses
Spotless with google-java-format to do the formatting:
https://github.com/aljoscha/flink/commits/flink-xxx-spotless
To summarize from earlier discussion, the main benefits are:
- no more worrying about code style, both as re
I don't like checkstyle because it cannot be easily applied from the
commandline. I'm happy to learn otherwise, though. And I'd also be very
happy about alternative suggestions that can do that.
Right now, I think Spotless is the most straightforward tool for that.
Also I don't care so much ab
+1 on locking on one codestyle and I think that is what current checkstyle
rules serving.
For automatic applying part, we suggest developing by IDEA and with
Checkstyle Plugin on IDEA applying checkstyle suggestion is also automatic.
One short coming for spotless is that we can hardly adjust rule
Hi all,
+1 for enforcing "a" codestyle using "a" tool.
As the project grows both in terms of LOCs and contributors, this
becomes more and more important as it eliminates some potential points
of friction without any additional effort.
>From the discussion, I am leaning towards having a single co
To me, ratchet seems to combine the worst aspects of both approaches.
You get disruptive changes, but only in singular files,
for something mundane as a typo fix or import change, which would be
annoying to keep separate from the actual functional changes in a PR.
On 10/7/2020 10:04 AM, Matthia
I find the ratchet feature you're suggesting interesting. But Arvid has a
point referring to the blog post about ignoring revisions in git blame [1].
Adding the configuration file for commits to ignore revs as proposed in the
blog post makes it even easier. One problem I see is that this is not
sup
Maybe I wasn't very clear on how the ratchet works. The changes are
gradual yes, but it doesn't leave you an option: if you touch a file you
will it will have to conform to the coding style afterwards. It's not
like the previous gradual process we had before where it would be based
on people ac
After having written that I did a quick search, you can even use git blame
with one big massive change commit [1], which would further help the idea
of "just get over with it".
With that option, I'd even change all whitespaces if the community thinks
that it's a better option (a separate discussio
I'm also +1 for automatically enforceable code style.
I also would just go over it as Chesnay said. While it makes some changes a
bit harder to track (inline git blame), it's easy to skip over in any git
history and if it's only one massive commit, then it's also much easier to
ignore than many gr
We shouldn't switch to spaces _now_; cutting this bit from your proposal
will massively simplify things and there's hardly any value in changing it.
Also I'm getting rather tired of this constant idea of "gradual
application". We've been doing this for 2-3 years now since we
introduced Checkst
Hi Aljoscha,
I think that having the style check directly in the IDE is a very good
feature so +1 on my side as a contributor (I also asked once on the mailing
list if there was already something like that)..I never used Spotless so I
can't say if it easy to integrate with the IDE but the nice thin
Hi All,
I know I know, but please keep reading because I recently learned about
some new developments in the area of coding-style automation.
The tool I would propose we use is Spotless
(https://github.com/diffplug/spotless). This doesn't come with a
formatter but allows using other popular
26 matches
Mail list logo
