Yes. I think that's a good compromise. Additionally, I vote for a "deadline" (or "target date") to get those JIRAs done (even if we cannot enforce it) to not get "trapped" by the lazy approach.
On 10/23/2015 02:12 PM, Fabian Hueske wrote: > Which basically defaults back to lazily adding JavaDocs (with some > bookkeeping). > > I'd be +1 for that. > > 2015-10-23 14:09 GMT+02:00 Matthias J. Sax <mj...@apache.org>: > >> A "deadline" is not really forcible. >> >> However, if we have a JIRA for each module, we can enable JavaDoc >> enforcement when the JIRA is resolved. And we should discuss the >> progress about those tickets regularly (to hopefully find volunteers to >> resolve them) and use a special tag for them. >> >> On 10/23/2015 01:59 PM, Fabian Hueske wrote: >>> And who should be "forced" to write the docs before the deadline passes? >>> That's not going to work either, IMO. >>> >>> 2015-10-23 13:13 GMT+02:00 Matthias J. Sax <mj...@apache.org>: >>> >>>> I don't care about line length. >>>> >>>> Still prefer whitespaces because it gives aligned indention for line >>>> break in method calls (remember my example) But I would not vote -1 for >>>> keeping tabs either. >>>> >>>> About JavaDocs: I agree with Max that lazy adding will not fix the >>>> problem. There should be some enforcement (maybe module by module over >>>> time; backed up with JIRAs; and maybe a fixed date when the JavaDocs >>>> must be completed) >>>> >>>> -Matthias >>>> >>>> >>>> On 10/23/2015 11:55 AM, Stephan Ewen wrote: >>>>> I am with Vasia. >>>>> >>>>> Are spaces so important that we want to effectively wipe out the entire >>>>> commit history? >>>>> >>>>> On Fri, Oct 23, 2015 at 11:51 AM, Vasiliki Kalavri < >>>>> vasilikikala...@gmail.com> wrote: >>>>> >>>>>> Hey, >>>>>> >>>>>> sorry I haven't replied so far. I was enjoying the thread tough :P >>>>>> >>>>>> I'm +1 for 120 line length and tabs. I wouldn't voice a -1 for spaces, >>>> but >>>>>> it seems to me like an unnecessary change that would touch every >> single >>>>>> Java file and without substantially improving anything. >>>>>> >>>>>> JavaDocs by-module with JIRAs to track progress seems like the best >>>> choice >>>>>> to me. >>>>>> >>>>>> -Vasia. >>>>>> >>>>>> On 23 October 2015 at 11:34, Fabian Hueske <fhue...@gmail.com> wrote: >>>>>> >>>>>>> Enforcing JavaDocs (no, by-file, by-module, global) is another open >>>>>>> question. >>>>>>> >>>>>>> Regarding the line length, I am OK with 120 chars. >>>>>>> >>>>>>> 2015-10-23 11:29 GMT+02:00 Ufuk Celebi <u...@apache.org>: >>>>>>> >>>>>>>> I think that we have two open questions now: >>>>>>>> >>>>>>>> 1. Line length >>>>>>>> >>>>>>>> From the discussion so far, I think that no one wants 80 characters >>>>>> line >>>>>>>> length. >>>>>>>> >>>>>>>> The final decision will be 100 vs. 120 characters. 120 characters is >>>>>> what >>>>>>>> we have right now (for most parts), so it is fair to keep it that >> way, >>>>>>> but >>>>>>>> enforce it (get rid of the longer lines). >>>>>>>> >>>>>>>> Is everyone OK with this? >>>>>>>> >>>>>>>> 2. Tabs vs. Spaces: >>>>>>>> >>>>>>>> I hope I’m not misrepresenting someone with the following summary of >>>>>>>> positions. >>>>>>>> >>>>>>>> Tabs: >>>>>>>> - Robert >>>>>>>> - Max >>>>>>>> - Fabian >>>>>>>> (- Stephan) >>>>>>>> >>>>>>>> Spaces: >>>>>>>> - Matthias >>>>>>>> - Marton >>>>>>>> - Till >>>>>>>> - Gyula >>>>>>>> - Henry >>>>>>>> (- Stephan) >>>>>>>> >>>>>>>> Let’s wrap the discussion up by focusing on this question. >>>>>>>> >>>>>>>> What are the PROs/CONs for the respective approaches? If we went >> with >>>>>> the >>>>>>>> opposing approach, would you voice a -1? E.g. would a “tabs person" >> -1 >>>>>> a >>>>>>>> "spaces decision" and vice versa? >>>>>>>> >>>>>>>> – Ufuk >>>>>>>> >>>>>>>>> On 23 Oct 2015, at 10:34, Maximilian Michels <m...@apache.org> >> wrote: >>>>>>>>> >>>>>>>>> I don't think lazily adding comments will work. However, I'm fine >>>>>> with >>>>>>>>> adding all the checkstyle rules one module at a time (with a jira >>>>>>>>> issue to keep track of the modules already converted). It's not >> going >>>>>>>>> to happen that we lazily add comments because that's the reason why >>>>>>>>> comments are missing in the first place... >>>>>>>>> >>>>>>>>> On Fri, Oct 23, 2015 at 12:05 AM, Henry Saputra < >>>>>>> henry.sapu...@gmail.com> >>>>>>>> wrote: >>>>>>>>>> Could we make certain rules to give warning instead of error? >>>>>>>>>> >>>>>>>>>> This would allow us to cherry-pick certain rules we would like >>>>>> people >>>>>>>>>> to follow but not strictly enforced. >>>>>>>>>> >>>>>>>>>> - Henry >>>>>>>>>> >>>>>>>>>> On Thu, Oct 22, 2015 at 9:20 AM, Stephan Ewen <se...@apache.org> >>>>>>> wrote: >>>>>>>>>>> I don't think a "let add comments to everything" effort gives us >>>>>> good >>>>>>>>>>> comments, actually. It just gives us checkmark comments that make >>>>>> the >>>>>>>> rules >>>>>>>>>>> pass. >>>>>>>>>>> >>>>>>>>>>> On Thu, Oct 22, 2015 at 3:29 PM, Fabian Hueske < >> fhue...@gmail.com> >>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Sure, I don't expect it to be free. >>>>>>>>>>>> But everybody should be aware of the cost of adding this code >>>>>> style, >>>>>>>> i.e., >>>>>>>>>>>> spending a huge amount of time on reformatting and documenting >>>>>> code. >>>>>>>>>>>> >>>>>>>>>>>> Alternatively, we could drop the JavaDocs rule and make the >>>>>>> transition >>>>>>>>>>>> significantly cheaper. >>>>>>>>>>>> >>>>>>>>>>>> 2015-10-22 15:24 GMT+02:00 Till Rohrmann <trohrm...@apache.org >>> : >>>>>>>>>>>> >>>>>>>>>>>>> There ain’t no such thing as a free lunch and code style. >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Oct 22, 2015 at 3:13 PM, Maximilian Michels < >>>>>>> m...@apache.org> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I think we have to document all these classes. Code Style >>>>>> doesn't >>>>>>>> come >>>>>>>>>>>>>> for free :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Oct 22, 2015 at 3:09 PM, Fabian Hueske < >>>>>> fhue...@gmail.com >>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> Any ideas how to deal with the mandatory JavaDoc rule for >>>>>>> existing >>>>>>>>>>>>> code? >>>>>>>>>>>>>>> Just adding empty headers to make the checkstyle pass or >> start >>>>>> a >>>>>>>>>>>>> serious >>>>>>>>>>>>>>> effort to add the missing docs? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2015-10-21 13:31 GMT+02:00 Matthias J. Sax <mj...@apache.org >>> : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Agreed. That's the reason why I am in favor of using vanilla >>>>>>>> Google >>>>>>>>>>>>> code >>>>>>>>>>>>>>>> style. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 10/21/2015 12:31 PM, Stephan Ewen wrote: >>>>>>>>>>>>>>>>> We started out originally with mixed tab/spaces, but it >> ended >>>>>>> up >>>>>>>>>>>>> with >>>>>>>>>>>>>>>>> people mixing spaces and tabs arbitrarily, and there is >>>>>> little >>>>>>>> way >>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> enforce Matthias' specific suggestion via checkstyle. >>>>>>>>>>>>>>>>> That's why we dropped spaces alltogether... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Oct 21, 2015 at 12:03 PM, Gyula Fóra < >>>>>>>>>>>> gyula.f...@gmail.com> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I think the nice thing about a common codestyle is that >>>>>>> everyone >>>>>>>>>>>>> can >>>>>>>>>>>>>> set >>>>>>>>>>>>>>>>>> the template in the IDE and use the formatting commands. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Matthias's suggestion makes this practically impossible so >>>>>> -1 >>>>>>>> for >>>>>>>>>>>>>> mixed >>>>>>>>>>>>>>>>>> tabs/spaces from my side. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Matthias J. Sax <mj...@apache.org> ezt írta (időpont: >> 2015. >>>>>>>> okt. >>>>>>>>>>>>>> 21., >>>>>>>>>>>>>>>> Sze, >>>>>>>>>>>>>>>>>> 11:46): >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I actually like tabs a lot, however, in a "mixed" style >>>>>>>> together >>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>> spaces. Example: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> myVar.callMethod(param1, // many more >>>>>>>>>>>>>>>>>>> .................paramX); // the dots mark space >>>>>>>>>>>> indention >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> indenting "paramX" with tabs does not give nice aliment. >>>>>> Not >>>>>>>>>>>> sure >>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>>> this would be a feasible compromise to keeps tabs in >>>>>> general, >>>>>>>>>>>> but >>>>>>>>>>>>>> use >>>>>>>>>>>>>>>>>>> space for cases as above. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If this in no feasible compromise, I would prefer space >> to >>>>>>> get >>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>> correct indention in examples as above. Even if this >> result >>>>>>> in >>>>>>>> a >>>>>>>>>>>>>>>>>>> complete reformatting of the whole code. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Why this? Everybody can set this in it's IDE/editor as >>>>>> he/she >>>>>>>>>>>>>> wishes... >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> If we keep tabs, we will have to specify the line >> length >>>>>>>>>>>>> relative >>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>> tab >>>>>>>>>>>>>>>>>>>>> size (like 4). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -Matthias >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 10/21/2015 11:06 AM, Ufuk Celebi wrote: >>>>>>>>>>>>>>>>>>>> To summarize up to this point: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - All are in favour of Google check style (with the >>>>>>> following >>>>>>>>>>>>>> possible >>>>>>>>>>>>>>>>>>>> exceptions) >>>>>>>>>>>>>>>>>>>> - Proposed exceptions so far: >>>>>>>>>>>>>>>>>>>> * Specific line length 100 vs. 120 characters >>>>>>>>>>>>>>>>>>>> * Keep tabs instead converting to spaces (this would >>>>>>>>>>>> translate >>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> skipping/coming up with some indentation rules as well) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If we keep tabs, we will have to specify the line length >>>>>>>>>>>> relative >>>>>>>>>>>>>> to a >>>>>>>>>>>>>>>>>>> tab >>>>>>>>>>>>>>>>>>>> size (like 4). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Let’s keep the discussion going a little longer. I think >>>>>> it >>>>>>>> has >>>>>>>>>>>>>>>>>> proceeded >>>>>>>>>>>>>>>>>>>> in a very reasonable manner so far. Thanks for this! >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> – Ufuk >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Wed, Oct 21, 2015 at 10:29 AM, Fabian Hueske < >>>>>>>>>>>>> fhue...@gmail.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks Max for checking the modifications by the Google >>>>>>> code >>>>>>>>>>>>>> style. >>>>>>>>>>>>>>>>>>>>> It is very good to know, that the impact on the code >> base >>>>>>>>>>>> would >>>>>>>>>>>>>> not >>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>> too >>>>>>>>>>>>>>>>>>>>> massive. If the Google code style would have touched >>>>>> almost >>>>>>>>>>>>> every >>>>>>>>>>>>>>>>>> line, >>>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>>>>> would have been in favor of converting to spaces. >>>>>> However, >>>>>>>>>>>> your >>>>>>>>>>>>>>>>>>> assessment >>>>>>>>>>>>>>>>>>>>> is a strong argument to continue with tabs, IMO. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Regarding the line length limit, I personally find 100 >>>>>>> chars >>>>>>>>>>>> too >>>>>>>>>>>>>>>>>> narrow >>>>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>>>>>> would be +1 for having a limit. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> +1 for discussing the Scala style in a separate thread. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Fabian >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 2015-10-20 18:12 GMT+02:00 Maximilian Michels < >>>>>>>> m...@apache.org >>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I'm a little less excited about this. You might not be >>>>>>> aware >>>>>>>>>>>>> but, >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>> a large portion of the source code, we already follow >>>>>> the >>>>>>>>>>>>> Google >>>>>>>>>>>>>>>>>> style >>>>>>>>>>>>>>>>>>>>>> guide. The main changes will be tabs->spaces and >> 80/100 >>>>>>>>>>>>>> characters >>>>>>>>>>>>>>>>>>>>>> line limit. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Out of curiosity, I ran the official Google Style >>>>>>> Checkstyle >>>>>>>>>>>>>>>>>>>>>> configuration to confirm my suspicion: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml >>>>>>>>>>>>>>>>>>>>>> The changes are very little if we turn off line length >>>>>>> limit >>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>> tabs-to-spaces conversion. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> There are some things I really like about the Google >>>>>>> style, >>>>>>>>>>>>> e.g. >>>>>>>>>>>>>>>>>> every >>>>>>>>>>>>>>>>>>>>>> class has to have a JavaDoc and spaces after keywords >>>>>>> (can't >>>>>>>>>>>>>> stand >>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>>>>>> there aren't any). I'm not sure if we should change >> tabs >>>>>>> to >>>>>>>>>>>>>> spaces, >>>>>>>>>>>>>>>>>>>>>> because it means touching almost every single line of >>>>>>> code. >>>>>>>>>>>>>> However, >>>>>>>>>>>>>>>>>>>>>> if we keep the tabs, we cannot make use of the >> different >>>>>>>>>>>>>> indention >>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>> case statements or wrapped lines...maybe that's a >>>>>>> compromise >>>>>>>>>>>> we >>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>>>>> live with. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> If we introduce the Google Style for Java, will we >> also >>>>>>>>>>>> impose >>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>>>> stricter style check for Scala? IMHO the line length >> is >>>>>>> the >>>>>>>>>>>>>>>> strictest >>>>>>>>>>>>>>>>>>>>>> part of the Scala Checkstyle. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Tue, Oct 20, 2015 at 4:14 PM, Henry Saputra < >>>>>>>>>>>>>>>>>>> henry.sapu...@gmail.com> >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>> 1) yes. Been dancing this issue for a while. Let's >> pull >>>>>>> the >>>>>>>>>>>>>>>> trigger. >>>>>>>>>>>>>>>>>>>>> Did >>>>>>>>>>>>>>>>>>>>>>> the exercise with Tachyon while back and did help >>>>>>>>>>>> readability >>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>> homogeneity of code. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 2) +1 for Google Java style with documented >> exceptions >>>>>>> and >>>>>>>>>>>>>>>>>> explanation >>>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>>>> why. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Tuesday, October 20, 2015, Ufuk Celebi < >>>>>>> u...@apache.org> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> DISCLAIMER: This is not my personal idea, but a >>>>>>> community >>>>>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>>>>>>> some time ago. Don't kill the messenger. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> In March we were discussing issues with >> heterogeneity >>>>>> of >>>>>>>>>>>> the >>>>>>>>>>>>>> code >>>>>>>>>>>>>>>>>>> [1]. >>>>>>>>>>>>>>>>>>>>>> The >>>>>>>>>>>>>>>>>>>>>>>> summary is that we had a consensus to enforce a >>>>>> stricter >>>>>>>>>>>> code >>>>>>>>>>>>>>>> style >>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>>> our >>>>>>>>>>>>>>>>>>>>>>>> Java code base in order to make it easier to switch >>>>>>>> between >>>>>>>>>>>>>>>>>> projects >>>>>>>>>>>>>>>>>>>>>> and to >>>>>>>>>>>>>>>>>>>>>>>> have clear rules for new contributions. The main >>>>>>> proposal >>>>>>>>>>>> in >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> last >>>>>>>>>>>>>>>>>>>>>>>> discussion was to go with Google's Java code style. >>>>>> Not >>>>>>>> all >>>>>>>>>>>>>> were >>>>>>>>>>>>>>>>>>> fully >>>>>>>>>>>>>>>>>>>>>>>> satisfied with this, but still everyone agreed on >> some >>>>>>>> kind >>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>> style. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I think the upcoming 0.10 release is a good point to >>>>>>>>>>>> finally >>>>>>>>>>>>> go >>>>>>>>>>>>>>>>>>>>> through >>>>>>>>>>>>>>>>>>>>>>>> with these changes (right after the >>>>>> release/branch-off). >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I propose to go with Google's Java code style [2] as >>>>>>>>>>>> proposed >>>>>>>>>>>>>>>>>>> earlier. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> PROs: >>>>>>>>>>>>>>>>>>>>>>>> - Clear style guide available >>>>>>>>>>>>>>>>>>>>>>>> - Tooling like checkstyle rules, IDE plugins already >>>>>>>>>>>>> available >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> CONs: >>>>>>>>>>>>>>>>>>>>>>>> - Fully breaks our current style >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> The main problem with this will be open pull >> requests, >>>>>>>>>>>> which >>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>> harder >>>>>>>>>>>>>>>>>>>>>>>> to merge after all the changes. On the other hand, >>>>>>> should >>>>>>>>>>>>> pull >>>>>>>>>>>>>>>>>>>>> requests >>>>>>>>>>>>>>>>>>>>>>>> that have been open for a long time block this? Most >>>>>> of >>>>>>>> the >>>>>>>>>>>>>>>>>> important >>>>>>>>>>>>>>>>>>>>>>>> changes will be merged for the release anyways. I >>>>>> think >>>>>>> in >>>>>>>>>>>>> the >>>>>>>>>>>>>>>> long >>>>>>>>>>>>>>>>>>>>> run >>>>>>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>>>>> will gain more than we loose by this (more >> homogenous >>>>>>>> code, >>>>>>>>>>>>>> clear >>>>>>>>>>>>>>>>>>>>>> rules). >>>>>>>>>>>>>>>>>>>>>>>> And it is questionable whether we will ever be able >> to >>>>>>> do >>>>>>>>>>>>> such >>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>>> change >>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>> the future if we cannot do it now. The project will >>>>>> most >>>>>>>>>>>>> likely >>>>>>>>>>>>>>>>>> grow >>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>> attract more contributors, at which point it will be >>>>>>> even >>>>>>>>>>>>>> harder >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> do. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Please make sure to answer the following points in >> the >>>>>>>>>>>>>> discussion: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 1) Are you (still) in favour of enforcing stricter >>>>>> rules >>>>>>>> on >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>>>>>>>>>>> codebase? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 2) If yes, would you be OK with the Google's Java >> code >>>>>>>>>>>> style? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> – Ufuk >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> http://mail-archives.apache.org/mod_mbox/flink-dev/201503.mbox/%3ccanc1h_von0b5omnwzxchtyzwhakeghbzvquyk7s9o2a36b8...@mail.gmail.com%3e >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> [2] >>>>>> https://google.github.io/styleguide/javaguide.html >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >
signature.asc
Description: OpenPGP digital signature
