You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@ozone.apache.org by GitBox <gi...@apache.org> on 2020/05/14 08:10:06 UTC

[GitHub] [hadoop-ozone] maobaolong opened a new pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

maobaolong opened a new pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921


   ## What changes were proposed in this pull request?
   
   Change config file of checkstyle only, loosen some rule restrictions of checkstyle.
   
   ## What is the link to the Apache JIRA
   
   https://issues.apache.org/jira/browse/HDDS-3583
   
   ## How was this patch tested?
   
   No need
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] elek commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

elek commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-638231484


   There is a [related discussion](https://lists.apache.org/thread.html/rb3bfc0b6795a9fd5973e06e17b3fdc8780911e8be66536133d461ce6%40%3Cozone-dev.hadoop.apache.org%3E) on the mailing lists.
   
   @fapifta had some concerns, but he said `+0` and not `-1`. (He has different preference, but ready to accept other approach).
   
   As any code change can be vetoed by any committers, we need clarification from @anuengineer.
   
   @anuengineer can you accept this patch (`+0`) or it should be cancelled? (`-1`)


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648540995


   > So, what is the harm in extending the line limit to 120 characters, when users can always consume it the way they want to? Wouldn't it be more accommodative to a wider set of audience?
   
   Because we have no data if the tools that visually challenged people use are designed to work well with these lengths. Since both of us are not experts, we have to rely on someone else who is deemed to be an expert? That is all I am doing.
   
   For a second let us assume that your argument is correct, then it would seem that the recommendations being made by accessibility.gov is wrong. Since the same rationale would apply to most text, I think the issue is more subtle, and we(both you and I) are not familiar with the recommendations and complications arising out of these disabilities.
   
   I also use really wide monitors, so I personally have no issues with this. What is missing in this discussion is the most germane part of the discussion -- That is -- what does accessibility mean and how do you make sure that the systems we build is usable and accommodating to the extend possible for others. Let us take the other side, let us say that we don't move from 80 to 120, what is the loss? Are all the programmers going to be less productive? 
   
   We can always find out.. Take top 10 code writers in Linux, monitor them with 80 char time vs. 100 chars. So find people who have always been writing 100 chars, then let us see if that improves productivity. Otherwise, this is [classic bike shedding](http://bikeshed.com/), no one needs to put in any research and everyone has an opinion, including that accessibility.gov is not applicable to us. 
   
   Once more, let us try to bring the discussion back to the merits of the question. Let us do some research and make an informed decision; or let us leave this question open, until such time that someone who does research in this topic is kind enough to comment on this. I am not saying that world is going to come to an end by moving to 120 chars. As for  Linux, it  is a run on BDFL model, so what Torvalds decides works. The ethos of Apache is completely different, we really put effort into building communities, hence my concern.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] adoroszlai commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

adoroszlai commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-630707061


   +1


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648364625


   >    https://accessibility.digital.gov/ is about accessible websites (layout, navigation, etc.). It does not talk about making the source of these websites accessible.
   
   But which part of the write up gave you the impression that written text on a screen shouldn't follow this recommendation. For a website like https://www.gutenberg.org/ would this hold? It is just text, some novels on the web. I think it does; Again, what is missing in the whole conversation is what is the data point to move when a certified government body, designed to deal with only this issue is giving a set of recommendations and why would we not follow it? Why are we insisting that source code is some how not text? I am not able to comprehend this stretch of argument. In my mind, Source code is text. And I am assuming that these recommendations hold for all romantic languages.
   
   
   >  Even if we accept the specific line length recommendation as applicable to our sources, why should it apply only to Java code? Why not, most importantly, to our Markdown docs, which have much longer lines than 80 chars? What about Javascript, CSS, bash scripts, POM files, etc?
   This is a good point. I agree, to the extend possible, we should make this binding on all sources. Including for sure, on MArkdown and CSS and Bash scripts. I was not aware of this oversight. Thank you for bringing this to my attention.
   
   
   > What about log files and configuration? Those affect a (hopefully) much wider audience.
   
   Log files generally have no carriage return and therefor formats to whatever size you want. Configuration, I do feel that we should follow the 80 lines limit.
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-643829659

>Veto is cast, it must be accompanied by a valid reason explaining the reasons for the veto.
I am casting a veto on this change, it is not because I am one the first authors of the project, Far from it.

My reason is simple, https://accessibility.digital.gov/visual-design/typography/ argues very clearly too keep them under 75 chars per line. I want to make sure that code base usable for people with visual disability. If you have research or authority which proves that this is not the case, I am willing to lift the veto.

In the absence of information -- that an argument like this is probably for text and not for code -- is absence of information, I don't have any data to modify current stance. So currently this veto stands. I am more than willing to listen to your arguments and respectfully think about it. In fact, my veto is based on reading and researching on this topic. Not based on the fact that I am the first person to write code for Ozone.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] vivekratnavel commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

vivekratnavel commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648643111


   > Your argument is that it is about text, which part of the source code does not seem to be text? why is that recommendation not applicable? None of you are willing to produce information about why your preference is better, other than it is "my preference".
   
   https://accessibility.digital.gov/visual-design/typography/ talks about recommendations on how to present text. I think this is applicable to content that is published in web pages where users do not have much flexibility to change the presentation (typeface, type size, line height etc.). The best example where this would be applicable is this website - https://hadoop.apache.org/ozone/  
   
   I find a lot of differences between source code and normal text. Even though source code is text, it is not published in a hardcoded formatting where the type size, line width and line-height recommendations by https://accessibility.digital.gov/visual-design/typography/ can be followed. Source code is not written in paragraphs with headings or sub-headings. It has varying indentations based on the language and the users have complete control over its presentation. Users can choose to read source code from Github, or choose any IDE or text editors with options to choose a typeface, line height, and line width.  
   
   Now, when we enforce a hard rule on the line limit, we are excluding users who want to read 100 or 120 columns per line.  
   
   > Let us take the other side, let us say that we don't move from 80 to 120, what is the loss?
   
   We lose the ability to "grep" certain texts. And we are not accommodative to those users who are not comfortable with the 80 column limit.  
   
   > Are all the programmers going to be less productive?
   
   I believe this discussion is not about improving productivity. And your arguments were also to improve accessibility and be accommodative to the extent possible for others. My argument again is that we will be excluding a set of users by not extending the line limit to 120.   
   
   >  Let us do some research and make an informed decision; or let us leave this question open, until such time that someone who does research in this topic is kind enough to comment on this.
   
   I am not in denial of the research done by https://accessibility.digital.gov/. All I am saying is that extending the line limit to 120 characters will accommodate everybody's needs including the visually challenged.  
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] fapifta commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

fapifta commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-644671160


   We are currently the part of the Hadoop project, which has the 80 characters as the limit, we I think should change the rule - if we change it - after we become TLP as that is in the making. Also this seems to be a good time to write our guidelines (yes, I loved to read the Flink guidelines Marton posted on the mailing list), that talks about coding style, wrapping, line length, possible exceptions and all the things that we think is important regarding code. First it should not be large, but evolve over time as we have discussions and learning points on the go, but it would be useful to contain all the prior learning points we already have on the project.
   
   Even though I don't want to block the community from the change, I still think we should keep 80-ish as a limit. I wrote about consistency, I wrote about typography, and I wrote about a couple other things in the mail-thread. Also I questioned why not go unlimited then based on the first arguments about inclusiveness and naming problems cited by 120 limit supporters.
   
   Now I just would like to add some colour from a few guys seem way smarter then me...
   Kevlin Henney is dealing with this topic in a talk "Seven ineffective habits of many programmers" in several conferences.
   In this talk: https://vimeo.com/97329157
   At 14:38 he starts talking about spacing punctuation and indentation, and also gives some reason for 80 characters.
   After this section there comes the naming, and code structuring piece, and before this section he talks about the problems of verbosity and jokes around comments :)
   It is on one hand really convincing for me, also gives some interesting points we can use in the conversation about coding guidelines. If you have time to view the whole, the latter part talks about encapsulation, get/set and the problems with the wide use of'em, and tests at the end.
   
   Dan North at 20:42 in this video talks about "code that fits into one's head", and mentions why contextual consistency matters, and even though he talks about the way larger picture, it is true for source code as well, also he talks about teams have to be opinionated about how they do things, and how they organize things, and that makes me think that, we need general acceptable guidelines on many visual/architectural/algorithmical things that we might not agree on now, but we would like to have consistency on.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648358212

> I feel we would be better to accept the consensuses rather than veto the decision, and I would hope Anu would take onboard the direction the community desires over his own preference.

I have stated a logical reason. None of you seem to discuss that. So let me ask this again. Do you know how a visually challenged person operates? Have you used the tools? I have not, and I have rely on someone like Accessibility.gov. Your argument is that it is about text, which part of the source code does not seem to be text? why is that recommendation not applicable? None of you are willing to produce information about why your preference is better, other than it is "my preference".

I have repeatedly said in this conversation that if you are willing to produce data about accessible software use, I am willing to listen. If anything, I think this is a group of people trying to force the new preference without anything other than "ad hominem" attacks and innuendo.

Let us get the fact straight. The https://accessibility.digital.gov/ talks about recommendations to accommodate certain people who have biological restrictions; you have a wide monitor, you find that it is better to put the burden on them; since you would love to enjoy your wide monitor. I get that; but to accuse me to forcing my preference, when I have pointed out a valid logical objection and point out that we must be inclusive, where do you get the idea that I am forcing the community to be inline with my own preference. So yes, my VETO absolutely stands.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [hadoop-ozone] vivekratnavel commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

vivekratnavel commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648684073


   I was curious and did a quick research on what other top Apache projects are following for their max line length limit and here is what I found:
   
   - Apache Spark (http://spark.apache.org/contributing.html) - 100
   - Apache Kafka (https://kafka.apache.org/coding-guide) - certainly not 80 characters
   - Apache Hive (https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-CodingConventions) - 120
   - Apache Maven (http://maven.apache.org/developers/conventions/code.html) - 120
   - Apache Ranger (https://cwiki.apache.org/confluence/display/RANGER/Coding+guidelines) - unlimited
   - Apache Lucene Solr (https://cwiki.apache.org/confluence/display/SOLR/HowToContribute#HowToContribute-ContributingCode(Features,BugFixes,Tests,etc...)) - 132
   - Impala (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65868536) - 90
   - Airflow (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=99844429) - 110
   - Apache cloudstack (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Coding+conventions) - 180
   - Apache IGNITE (https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-LineBreaking) - 120
   - Apache Tomcat (https://github.com/apache/tomcat/blob/master/CONTRIBUTING.md#style-guide) - 100
   - JMeter (https://cwiki.apache.org/confluence/display/JMETER/CodeStyleGuidelines) - soft 80, hard 120
   - Apache ISIS (https://cwiki.apache.org/confluence/display/ISIS/Style+Guide) - 100
   - Apache Traffic Server (https://cwiki.apache.org/confluence/display/TS/Coding+Style) - 132
   - Apache Geode (https://cwiki.apache.org/confluence/display/GEODE/Code+Style+Guide) - 100
   
   All of these projects seem to use >80 column limit for line lengths. I noticed that in many of these projects, even though they follow [Sun's conventions](http://web.archive.org/web/20140228225807/http://www.oracle.com/technetwork/java/codeconventions-150003.pdf), they specifically make an exception to the line length limit to make it >80 columns per line. 


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648375813

> The longest line is 7434 characters long. Even if you remove the `docker-compose`-specific prefix, which does not appear in real clusters, we still have 7420 chars.

What you are pointing out it is the there are lines which are really long, and generally when you see a line of 7434, you need a something that warps that info for you to read effectively. I will agree to that. This is an example of what I meant by no carriage return, not literally, but in the practical sense of machine generated stuff that gets consumed -- it is hard to even know what the length is. So we treat these insanely long lines as if they are without carriage return since whatever wrapping you need, the consumer puts them up.

> Each line starting with datanode_1 | follows a carriage return at the end of the previous line.

As you correctly pointed out, each of these line can be really long. -- **7434** chars is extremely long and has absolutely no bearing on the discussion of lines length which is human produced and neatly formatted like source code. That is why we are discussing 80/120 chars.

There is also another point, it is trivial to attach all kinds of collectors to the log pipeline -- log4j itself ships with so many. So Transformation on data is designed to be trivial and if you need to make it different, it is simple.

So to be precise: I was trying to stress the point that while each log is separated by a carriage return, the general expectation is that lines can be really long because each line in a log is self contained -- and each source line that produces that information is producing it without reference to other parts of the code. This property makes it easy to write parsers and indexers over log files. In fact, there is a very large industry which produces tools to solve this issue.

To make this more clear: The log files are record oriented, each line is a record -- that is clearly delineated by a carriage return.
The information within that record can be really long and generally formatted via tools( I am aware there are issues here like Java exception logging), but this is the general principle. This record oriented format frees us from the absolute need to create log in a predefined manner. It is also that most of the logs are not read, they are searched, in fact slicing is the most important operation for a log, source is it linear reading.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648375813

> The longest line is 7434 characters long. Even if you remove the `docker-compose`-specific prefix, which does not appear in real clusters, we still have 7420 chars.

> Each line starting with datanode_1 | follows a carriage return at the end of the previous line.

There is also another point, it is trivial to attach all kinds of collectors to the log pipeline -- log4j itself ships with some many. So Transformation on data is designed to be trivial and if you need to make it different, it is simply possible.

To make this more clear: The log files are record oriented, each line is a record -- that is clearly delineated by a carriage return.
The information within that record can be really long and generally formatted via tools( I am aware there are issues here like Java exception logging), but this is the general principle. This record oriented format frees us from the absolutely need to process log in a predefined manner. It is also that most of the logs are not read, they are searched, in fact slicing is the most important operation for a log, source is it linear reading.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648358212

> I feel we would be better to accept the consensuses rather than veto the decision, and I would hope Anu would take onboard the direction the community desires over his own preference.

> The above link provides no evidence about the ease of reading source code.

I agree, but let me ask you this; how did you come to the conclusion that this is NOT applicable to the source code at all? What is the information used by you to come to that conclusion? That text does not have the word source code, and therefore source is some sort of magical thing? or are you under the impression that visually challenged people does not read source code and we don't need to care about them?

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [hadoop-ozone] anuengineer commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648358212

> I feel we would be better to accept the consensuses rather than veto the decision, and I would hope Anu would take onboard the direction the community desires over his own preference.
I have stated a logical reason. None of you seem to discuss that. So let me ask this again. Do you know how a visually challenged person operates? Have you used the tools? I have not, and I have rely on someone like Accessibility.gov. Your argument is that it is about text, which part of the source code does not seem to be text? why is that recommendation not applicable? None of you are willing to produce information about why your preference is better, other than it is "my preference".

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [hadoop-ozone] elek commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

elek commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-630692526


   > @sodonnel How about the result of the +1's int the community sync call?
   
   My fault, but it was not discussed during the call. We were out of time. Let me ping the mailing list.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648540995


   > So, what is the harm in extending the line limit to 120 characters, when users can always consume it the way they want to? Wouldn't it be more accommodative to a wider set of audience?
   
   Because we have no data if the tools that visually challenged people use are designed to work well with these lengths. Since both of us are not experts, we have to rely on someone else who is deemed to be an expert? That is all I am doing.
   
   For a second let us assume that your argument is correct, then it would seem that the recommendations being made by accessibility.gov is wrong. Since the same rationale would apply to most text, I think the issue is more subtle, and we(both you and I) are not familiar with the recommendations and complications arising out of these disabilities.
   
   I also use really wide monitors, so I personally have no issues with this. What is missing in this discussion is the most germane part of the discussion -- That is -- what does accessibility mean and how do you make sure that the systems we build is usable and accommodating to the extend possible for others. Let us take the other side, let us say that we don't move from 80 to 120, what is the loss? Are all the programmers going to be less productive? 
   
   We can always find out.. Take top 10 code writers in Linux, monitor them with 80 char time vs. 100 chars. So find people who have always been writing 100 chars, then let us see if that improves productivity. Otherwise, this is classic bike shedding, no one needs to put in any research and everyone has an opinion, including that accessibility.gov is not applicable to us. 
   
   Once more, let us try to bring the discussion back to the merits of the question. Let us do some research and make an informed decision; or let us leave this question open, until such time that someone who does research in this topic is kind enough to comment on this. I am not saying that world is going to come to an end by moving to 120 chars. As for  Linux, it  is a run on BDFL model, so what Torvalds decides works. The ethos of Apache is completely different, we really put effort into building communities, hence my concern.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] maobaolong commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

maobaolong commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-643350226

There are still lots of contributor around me complain with the 80 character per line limitation.

So a month past, a vehemently discussion has taken place in the mail-list, i think everyone have many arguments, but everyone try to persuade other, but nobody can persuade other.

But we still need a decision, and a reason why, both do nothing and do this change. can be a choice. I think we don't make decision means choose keep 80, it isn't a reasonable result for people who want to change. Now, i found there are 3 choices from the discussion.

1. keep 80
2. change to 120
3. change to 100

It seems we have no better idea than vote, and everyone is equal, i don't think it's a good idea of giving more weight of people who did special contribution for Ozone. For example, founder, member, committer, contributor. In fact, it is too complex, the simple way is everyone is equal, at least voter should be a contributor, majority can be accepted.

Finally, my choice is change to 120, or at least 100, so, i want to vote to 2, and 3. I don't know why if we have to keep consistent with the first great people who write the first line of one repository, in fact, i saw a repository was changed from one language into another language, i also saw a repository was changed from gradle to maven, that is what i want to say, keep change, change for great.

I write this reply here because i'm not sure all contributors in the ozone-dev mail list, but i believe all the contributor can see this page, we can send this link to mail-list, slack channel or any others to let people vote for this decision. If someone have a better idea than vote, i'm very glad to see any other idea about how to finish this proposal other than vote.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [hadoop-ozone] elek commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

elek commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-644056130


   Actually I think the question is slightly different (based on the conversation from the email list)
   
   Let's say that we have an ideal line length (75 or 95 or 120, I don't know what). Do we need to enforce it in the source representation? Or we can enable for anybody to choose it based on own preference. 
   
   Using higher (or unlimited) number makes it possible to use **both** 120 or 80 or any other number based on the preference as the soft-wrap function of IDEs and an editors are very powerful today (tested IntelliJ)
   
   Originally I had no preference but I convinced that using a high number is more inclusive.
   
   
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648375979


   >  The longest line is 7434 characters long. Even if you remove the `docker-compose`-specific prefix, which does not appear in real clusters, we still have 7420 chars.
   
   What you are pointing out it is the there are lines which are really long, and generally when you see a line of 7434, you need a something that warps that info for you to read effectively. I was agree to that. This is an example of what I meant by no carriage return, not literally, but in the practical sense of machine generated stuff that gets consumed -- it is hard to even know what the length is. So we treat these insanely long lines as if they are without carriage return since whatever wrapping you need the consumer puts them up.
   
   >  Each line starting with datanode_1 | follows a carriage return at the end of the previous line.
   As you correctly pointed out, each of these line can be really long. -- **7434** chars is extremely long and has absolutely no bearing on the discussion of lines length which is human produced and neatly formatted like source code. That is why we are discussing 80/120 chars.
   
   There is also another point, it is trivial to attach all kinds of collectors to the log pipeline -- log4j itself ships with some many. So Transformation on data is designed to be trivial and if you need to make it different, it is simply possible.
   
   So to be precise: I was trying to stress the point that while each log is separated by a carriage return,  the general expectation is that lines can be really long because each line in a log is self contained -- and each source line that produces that information is producing it without reference to other parts of the code. This property makes it easy to write parsers and indexers over log files. In fact, there is a very large industry which produces tools to solve this issue. 


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] adoroszlai edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

adoroszlai edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-644067146


   1. https://accessibility.digital.gov/ is about accessible websites (layout, navigation, etc.).  It does not talk about making the source of these websites accessible.
   
   2. Even if we accept the specific line length recommendation as applicable to our sources, why should it apply only to Java code?  Why not, most importantly, to our Markdown docs, which have much longer lines than 80 chars?  What about Javascript, CSS, bash scripts, POM files, etc?
   
   3. What about log files and configuration?  Those affect a (hopefully) much wider audience.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] timmylicheng commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

timmylicheng commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-630716124


   +1. Thanks @maobaolong for taking action.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] xiaoyuyao commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

xiaoyuyao commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-643532154

Thanks all for the discussion, this change can be arguable from both sides. If I understand correctly, @anuengineer indicated a valid binding veto here. According to the project bylaw, a vote will not be helpful. The best shot is to convince him to withdraw, otherwise let us cancel the PR and move on with other important issues.

Bylaw of the project https://hadoop.apache.org/bylaws.html
"A valid, binding veto cannot be overruled. If a veto is cast, it must be accompanied by a valid reason explaining the reasons for the veto. The validity of a veto, if challenged, can be confirmed by anyone who has a binding vote. This does not necessarily signify agreement with the veto - merely that the veto is valid.

If you disagree with a valid veto, you must lobby the person casting the veto to withdraw their veto. If a veto is not withdrawn, any action that has been vetoed must be reversed in a timely manner."

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [hadoop-ozone] anuengineer commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-638517204


   I think it should be cancelled. Thanks for checking. 


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] adoroszlai commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

adoroszlai commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-644067146


   1. https://accessibility.digital.gov/visual-design/typography/ is about accessible websites (layout, navigation, etc.).  It does not talk about making the source of these websites accessible.
   
   2. Even if we accept the specific line length recommendation as applicable to our sources, why should it apply only to Java code?  Why not, most importantly, to our Markdown docs, which have much longer lines than 80 chars?  What about Javascript, CSS, bash scripts, POM files, etc?
   
   3. What about log files and configuration?  Those affect a (hopefully) much wider audience.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] vivekratnavel commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

vivekratnavel commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-643516494


   @maobaolong @sodonnel I agree with you both. I like the approach of starting a vote thread similar to a normal release or merge vote and give it 7 days for responses. It will be easy to keep track of votes if we start a vote thread in the mailing list and share the link here and in slack channel.
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] adoroszlai commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

adoroszlai commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648371279


   > Log files generally have no carriage return and therefor formats to whatever size you want.
   
   Can you please clarify this?
   
   Example log:
   
   ```
   datanode_1  | STARTUP_MSG:   args = []
   datanode_1  | STARTUP_MSG:   version = 3.2.1
   datanode_1  | STARTUP_MSG:   classpath = /etc/hadoop:/opt/hadoop/share/hadoop/common/*:/opt/hadoop/share/ozone/lib/kerb-simplekdc-1.0.1.jar:/opt/hadoop/share/ozone/lib/okhttp-4.2.2.jar:/opt/hadoop/share/ozone/lib/ratis-common-0.6.0-cac3336-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/jackson-databind-2.10.3.jar:/opt/hadoop/share/ozone/lib/protobuf-java-2.5.0.jar:/opt/hadoop/share/ozone/lib/bcpkix-jdk15on-1.60.jar:/opt/hadoop/share/ozone/lib/netty-3.10.5.Final.jar:/opt/hadoop/share/ozone/lib/commons-validator-1.6.jar:/opt/hadoop/share/ozone/lib/hadoop-hdds-client-0.6.0-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/jaxb-impl-2.3.0.1.jar:/opt/hadoop/share/ozone/lib/kotlin-stdlib-common-1.3.50.jar:/opt/hadoop/share/ozone/lib/kerb-core-1.0.1.jar:/opt/hadoop/share/ozone/lib/jsr305-3.0.0.jar:/opt/hadoop/share/ozone/lib/j2objc-annotations-1.3.jar:/opt/hadoop/share/ozone/lib/leveldbjni-all-1.8.jar:/opt/hadoop/share/ozone/lib/jetty-io-9.4.26.v20200117.jar:/opt/hadoop/share/ozone/lib/ratis-server-0.6.0-cac3336-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/hadoop-auth-3.2.1.jar:/opt/hadoop/share/ozone/lib/jaeger-tracerresolver-1.2.0.jar:/opt/hadoop/share/ozone/lib/htrace-core4-4.1.0-incubating.jar:/opt/hadoop/share/ozone/lib/jaxb-api-2.3.0.jar:/opt/hadoop/share/ozone/lib/kerb-util-1.0.1.jar:/opt/hadoop/share/ozone/lib/jetty-http-9.4.26.v20200117.jar:/opt/hadoop/share/ozone/lib/jetty-xml-9.4.26.v20200117.jar:/opt/hadoop/share/ozone/lib/jaeger-thrift-1.2.0.jar:/opt/hadoop/share/ozone/lib/commons-logging-1.2.jar:/opt/hadoop/share/ozone/lib/kerby-xdr-1.0.1.jar:/opt/hadoop/share/ozone/lib/jetty-server-9.4.26.v20200117.jar:/opt/hadoop/share/ozone/lib/opentracing-tracerresolver-0.1.8.jar:/opt/hadoop/share/ozone/lib/commons-net-3.6.jar:/opt/hadoop/share/ozone/lib/log4j-api-2.11.0.jar:/opt/hadoop/share/ozone/lib/jaeger-core-1.2.0.jar:/opt/hadoop/share/ozone/lib/error_prone_annotations-2.2.0.jar:/opt/hadoop/share/ozone/lib/ratis-thirdparty-misc-0.4.0.jar:/opt/hadoop/share/ozone/lib/slf4j-log4j12-1.7.25.jar:/opt/hadoop/share/ozone/lib/kerby-config-1.0.1.jar:/opt/hadoop/share/ozone/lib/okio-2.2.2.jar:/opt/hadoop/share/ozone/lib/jetty-util-ajax-9.4.26.v20200117.jar:/opt/hadoop/share/ozone/lib/metrics-core-3.2.4.jar:/opt/hadoop/share/ozone/lib/kerby-pkix-1.0.1.jar:/opt/hadoop/share/ozone/lib/guava-28.2-jre.jar:/opt/hadoop/share/ozone/lib/jetty-servlet-9.4.26.v20200117.jar:/opt/hadoop/share/ozone/lib/xz-1.0.jar:/opt/hadoop/share/ozone/lib/activation-1.1.1.jar:/opt/hadoop/share/ozone/lib/jsr311-api-1.1.1.jar:/opt/hadoop/share/ozone/lib/commons-beanutils-1.9.4.jar:/opt/hadoop/share/ozone/lib/rocksdbjni-6.6.4.jar:/opt/hadoop/share/ozone/lib/jetty-security-9.4.26.v20200117.jar:/opt/hadoop/share/ozone/lib/hadoop-hdds-container-service-0.6.0-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/ratis-grpc-0.6.0-cac3336-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/kerb-server-1.0.1.jar:/opt/hadoop/share/ozone/lib/javax.servlet-api-3.1.0.jar:/opt/hadoop/share/ozone/lib/kerb-client-1.0.1.jar:/opt/hadoop/share/ozone/lib/disruptor-3.4.2.jar:/opt/hadoop/share/ozone/lib/libthrift-0.13.0.jar:/opt/hadoop/share/ozone/lib/annotations-13.0.jar:/opt/hadoop/share/ozone/lib/simpleclient_common-0.7.0.jar:/opt/hadoop/share/ozone/lib/dnsjava-2.1.7.jar:/opt/hadoop/share/ozone/lib/jackson-annotations-2.10.3.jar:/opt/hadoop/share/ozone/lib/commons-configuration2-2.1.1.jar:/opt/hadoop/share/ozone/lib/json-smart-2.3.jar:/opt/hadoop/share/ozone/lib/token-provider-1.0.1.jar:/opt/hadoop/share/ozone/lib/log4j-1.2.17.jar:/opt/hadoop/share/ozone/lib/commons-daemon-1.0.13.jar:/opt/hadoop/share/ozone/lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar:/opt/hadoop/share/ozone/lib/bcprov-jdk15on-1.60.jar:/opt/hadoop/share/ozone/lib/ratis-client-0.6.0-cac3336-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/jetty-webapp-9.4.26.v20200117.jar:/opt/hadoop/share/ozone/lib/hadoop-hdfs-client-3.2.1.jar:/opt/hadoop/share/ozone/lib/commons-lang3-3.7.jar:/opt/hadoop/share/ozone/lib/commons-compress-1.4.1.jar:/opt/hadoop/share/ozone/lib/accessors-smart-1.2.jar:/opt/hadoop/share/ozone/lib/re2j-1.1.jar:/opt/hadoop/share/ozone/lib/hadoop-hdfs-3.2.1.jar:/opt/hadoop/share/ozone/lib/commons-math3-3.1.1.jar:/opt/hadoop/share/ozone/lib/simpleclient_dropwizard-0.7.0.jar:/opt/hadoop/share/ozone/lib/hadoop-common-3.2.1.jar:/opt/hadoop/share/ozone/lib/simpleclient-0.7.0.jar:/opt/hadoop/share/ozone/lib/httpclient-4.5.2.jar:/opt/hadoop/share/ozone/lib/asm-5.0.4.jar:/opt/hadoop/share/ozone/lib/kerby-util-1.0.1.jar:/opt/hadoop/share/ozone/lib/ratis-proto-0.6.0-cac3336-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/failureaccess-1.0.1.jar:/opt/hadoop/share/ozone/lib/jsp-api-2.1.jar:/opt/hadoop/share/ozone/lib/jsch-0.1.54.jar:/opt/hadoop/share/ozone/lib/log4j-core-2.11.0.jar:/opt/hadoop/share/ozone/lib/nimbus-jose-jwt-7.9.jar:/opt/hadoop/share/ozone/lib/commons-codec-1.11.jar:/opt/hadoop/share/ozone/lib/kotlin-stdlib-1.3.50.jar:/opt/hadoop/share/ozone/lib/commons-pool2-2.6.0.jar:/opt/hadoop/share/ozone/lib/jackson-datatype-jsr310-2.10.3.jar:/opt/hadoop/share/ozone/lib/gson-2.2.4.jar:/opt/hadoop/share/ozone/lib/opentracing-api-0.33.0.jar:/opt/hadoop/share/ozone/lib/jcip-annotations-1.0-1.jar:/opt/hadoop/share/ozone/lib/kerb-admin-1.0.1.jar:/opt/hadoop/share/ozone/lib/commons-io-2.5.jar:/opt/hadoop/share/ozone/lib/snakeyaml-1.16.jar:/opt/hadoop/share/ozone/lib/jetty-util-9.4.26.v20200117.jar:/opt/hadoop/share/ozone/lib/opentracing-noop-0.33.0.jar:/opt/hadoop/share/ozone/lib/jersey-core-1.19.jar:/opt/hadoop/share/ozone/lib/hadoop-hdds-hadoop-dependency-client-0.6.0-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/checker-qual-2.10.0.jar:/opt/hadoop/share/ozone/lib/hadoop-hdds-server-framework-0.6.0-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/ratis-netty-0.6.0-cac3336-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/opentracing-util-0.33.0.jar:/opt/hadoop/share/ozone/lib/picocli-3.9.6.jar:/opt/hadoop/share/ozone/lib/hadoop-hdds-common-0.6.0-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/commons-cli-1.2.jar:/opt/hadoop/share/ozone/lib/woodstox-core-5.0.3.jar:/opt/hadoop/share/ozone/lib/javax.annotation-api-1.2.jar:/opt/hadoop/share/ozone/lib/kerby-asn1-1.0.1.jar:/opt/hadoop/share/ozone/lib/netty-all-4.1.48.Final.jar:/opt/hadoop/share/ozone/lib/hadoop-hdds-config-0.6.0-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/stax2-api-3.1.4.jar:/opt/hadoop/share/ozone/lib/commons-collections-3.2.2.jar:/opt/hadoop/share/ozone/lib/commons-digester-1.8.1.jar:/opt/hadoop/share/ozone/lib/jettison-1.1.jar:/opt/hadoop/share/ozone/lib/commons-text-1.4.jar:/opt/hadoop/share/ozone/lib/jackson-core-2.10.3.jar:/opt/hadoop/share/ozone/lib/ratis-metrics-0.6.0-cac3336-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/jersey-servlet-1.19.jar:/opt/hadoop/share/ozone/lib/jersey-json-1.19.jar:/opt/hadoop/share/ozone/lib/slf4j-api-1.7.25.jar:/opt/hadoop/share/ozone/lib/kerb-identity-1.0.1.jar:/opt/hadoop/share/ozone/lib/hadoop-hdds-hadoop-dependency-server-0.6.0-SNAPSHOT.jar:/opt/hadoop/share/ozone/lib/kerb-common-1.0.1.jar:/opt/hadoop/share/ozone/lib/jaeger-client-1.2.0.jar:/opt/hadoop/share/ozone/lib/jaxb-core-2.3.0.1.jar:/opt/hadoop/share/ozone/lib/jersey-server-1.19.jar:/opt/hadoop/share/ozone/lib/hadoop-hdds-common-0.6.0-SNAPSHOT-tests.jar:/opt/hadoop/share/ozone/lib/kerb-crypto-1.0.1.jar:/opt/hadoop/share/ozone/lib/hadoop-annotations-3.2.1.jar:/opt/hadoop/share/ozone/lib/httpcore-4.4.4.jar:/opt/hadoop/share/ozone/web:/opt/hadoop/share/ozone/lib/hadoop-ozone-datanode-0.6.0-SNAPSHOT.jar
   datanode_1  | STARTUP_MSG:   build = https://gitbox.apache.org/repos/asf/hadoop.git -r b3cbbb467e22ea829b3808f4b7b01d07e0bf3842; compiled by 'rohithsharmaks' on 2019-09-10T15:56Z
   datanode_1  | STARTUP_MSG:   java = 11.0.6
   ```
   
   Each line starting with `datanode_1 | ` follows a carriage return at the end of the previous line.  The longest line is 7434 characters long.  Even if you remove the `docker-compose`-specific prefix, which does not appear in real clusters, we still have 7420 chars.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648375813

> The longest line is 7434 characters long. Even if you remove the `docker-compose`-specific prefix, which does not appear in real clusters, we still have 7420 chars.

> Each line starting with datanode_1 | follows a carriage return at the end of the previous line.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [hadoop-ozone] sodonnel commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

sodonnel commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-629127925


   I am in favour of this change, but for a change like this, I feel we need a few more +1's and also wait to see if there are any objections. We will try to discuss it on the next community sync call, which is on Monday.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] fapifta edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

fapifta edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-644671160


   We are currently the part of the Hadoop project, which has the 80 characters as the limit, we I think should change the rule - if we change it - after we become TLP as that is in the making. Also this seems to be a good time to write our guidelines (yes, I loved to read the Flink guidelines Marton posted on the mailing list), that talks about coding style, wrapping, line length, possible exceptions and all the things that we think is important regarding code. First it should not be large, but evolve over time as we have discussions and learning points on the go, but it would be useful to contain all the prior learning points we already have on the project.
   
   Even though I don't want to block the community from the change, I still think we should keep 80-ish as a limit. I wrote about consistency, I wrote about typography, and I wrote about a couple other things in the mail-thread. Also I questioned why not go unlimited then based on the first arguments about inclusiveness and naming problems cited by 120 limit supporters.
   
   Now I just would like to add some colour from a few guys seem way smarter then me...
   Kevlin Henney is dealing with this topic in a talk "Seven ineffective habits of many programmers" in several conferences.
   In this talk: https://vimeo.com/97329157
   At 14:38 he starts talking about spacing punctuation and indentation, and also gives some reason for 80 characters.
   After this section there comes the naming, and code structuring piece, and before this section he talks about the problems of verbosity and jokes around comments :)
   It is on one hand really convincing for me, also gives some interesting points we can use in the conversation about coding guidelines. If you have time to view the whole, the latter part talks about encapsulation, get/set and the problems with the wide use of'em, and tests at the end.
   
   Dan North at 20:42 in this video (https://youtu.be/4Y0tOi7QWqM?t=1242) talks about "code that fits into one's head", and mentions why contextual consistency matters, and even though he talks about the way larger picture, it is true for source code as well, also he talks about teams have to be opinionated about how they do things, and how they organize things, and that makes me think that, we need general acceptable guidelines on many visual/architectural/algorithmical things that we might not agree on now, but we would like to have consistency on.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] umamaheswararao commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

umamaheswararao commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-649109144


   Looks like eclipse default size changed in 2014.
   
   ```
   +++ b/org.eclipse.jdt.core/formatter/org/eclipse/jdt/internal/formatter/DefaultCodeFormatterOptions.java
   @@ -2041,9 +2041,9 @@
    			try {
    				this.page_width = Integer.parseInt((String) pageWidthOption);
    			} catch (NumberFormatException e) {
   -				this.page_width = 80;
   +				this.page_width = 120;
    			} catch(ClassCastException e) {
   -				this.page_width = 80;
   +				this.page_width = 120;
    			}
   ```
   Related issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=356851


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] vivekratnavel commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

vivekratnavel commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648479528


   @anuengineer I get your argument that we must be inclusive and the source code should be readable by visually challenged and https://accessibility.digital.gov/ recommends keeping the text under 75 characters per line.
   
   My argument is that as @elek pointed out earlier, a majority (if not all) of the IDEs out there support soft-wrapping source code at any limit that the user wants. They can even read the code at 66 characters per line if that is what the user is comfortable with. But for developers who are comfortable with reading code at 100 or 120 characters per line, the source code is not accommodative. 
   
   And I really like and completely agree with Linus's arguments against 80 column lines from the email thread you shared earlier (https://lkml.org/lkml/2020/5/29/1038).
   
   So, what is the harm in extending the line limit to 120 characters, when users can always consume it the way they want to? Wouldn't it be more accommodative to a wider set of audience?


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] maobaolong commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

maobaolong commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-629265339


   @sodonnel Yeah it is necessary


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] elek commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

elek commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-630694317


   BTW, I am +1, but let's wait a little for more feedback...


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648375813

> The longest line is 7434 characters long. Even if you remove the `docker-compose`-specific prefix, which does not appear in real clusters, we still have 7420 chars.

> Each line starting with datanode_1 | follows a carriage return at the end of the previous line.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [hadoop-ozone] anuengineer commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648375813


   >  The longest line is 7434 characters long. Even if you remove the `docker-compose`-specific prefix, which does not appear in real clusters, we still have 7420 chars.
   
   What you are pointing out it is the there are lines which are really long, and generally when you see a line of 7434, you need a something that warps that info for you to read effectively. I was agree to that. This is an example of what I meant by no carriage return, not literally, but in the practical sense of machine generated stuff that gets consumed -- it is hard to even know what the length is. So we treat these insanely long lines as if they are without carriage return since whatever wrapping you need the consumer puts them up.
   
   >  Each line starting with datanode_1 | follows a carriage return at the end of the previous line.
   As you correctly pointed out, each of these line can be really long. -- **7434** chars is extremely long and has absolutely no bearing on the discussion of lines length which is human produced and neatly formatted like source code. That is why we are discussing 80/120 chars.
   
   There is also another point, it is trivial to attach all kinds of collectors to the log pipeline -- log4j itself ships with some many. So Transformation on data is designed to be trivial and if you need to make it different, it is simply possible.
   
   So to be precise: I was trying to stress the point that while each log is separated by a carriage return,  the general expectation is that lines can be really long because each line in a log is self contained -- and each source line that produces that information is producing it without reference to other parts of the code. This property makes it easy to write parsers and indexers over log files. In fact, there is a very large industry which produces tools to solve this issue. 


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] elek commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

elek commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-644053711


   > My reason is simple, https://accessibility.digital.gov/visual-design/typography/ argues very clearly too keep them under 75 chars per line.
   
   According to this study 95 character is better (based on the text sis more convincing as the mentioned article, as it's a reproducible study).
   
   http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.503.2885&rep=rep1&type=pdf


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] sodonnel commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

sodonnel commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-643494970


   > There are still lots of contributor around me complain with the 80 character per line limitation.
   
   > So a month past, a vehemently discussion has taken place in the mail-list, i think everyone have many arguments, but everyone try to persuade other, but nobody can persuade other.
   
   This is the problem with a change like this. Its a debate where there is no "correct" answer. Some like it one way and some like it another. However that is not a reason to not change - as you said, software is always changing and in my opinion the style can change too. We can see that as the Java language has evolved over the versions, software gets refactored etc.
   
   > It seems we have no better idea than vote, and everyone is equal, i don't think it's a good idea of giving more weight of people who did special contribution for Ozone.
   
   I believe a vote is the best way to get an idea of what the community wants. Let the people who are actively involved in the project give their opinion.
   
   Its probably best to do this like a normal release or merge vote. Post it to the mailing list, and Slack and give it 7 days for responses. I'd be inclined to with just two options 80 or 120, but add in the 100 option too if you like.
   
   I'd be happy with 100 or 120. Perhaps going for the middle ground (100) would be more sympathetic to the existing code style as the lines would not be too much longer.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] vivekratnavel commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

vivekratnavel commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-634874921


   Should we wait for more approvals or is it good to be merged?


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648358212

> I feel we would be better to accept the consensuses rather than veto the decision, and I would hope Anu would take onboard the direction the community desires over his own preference.

Let us get the fact straight. The https://accessibility.digital.gov/ talks about recommendations to accommodate certain people who have handicaps; you have a wide monitor, you find that it is better to put the burden on them; since you would love to enjoy your wide monitor. I get that; but to accuse me to forcing my preference, when I have pointed out a valid logical objection and point out that we must be inclusive, where do you get the idea that I am forcing the community to be inline with my own preference. So yes, my VETO absolutely stands.

> The above link provides no evidence about the ease of reading source code.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648364625


   >    https://accessibility.digital.gov/ is about accessible websites (layout, navigation, etc.). It does not talk about making the source of these websites accessible.
   
   But which part of the write up gave you the impression that written text on a screen shouldn't follow this recommendation. For a website like https://www.gutenberg.org/ would this hold? It is just text, some novels on the web. I think it does; Again, what is missing in the whole conversation is what is the data point to move when a certified government body, designed to deal with only this issue is giving a set of recommendations and why would we not follow it? Why are we insisting that source code is some how not text? I am not able to comprehend this stretch of argument. In my mind, Source code is text. And I am assuming that these recommendations hold for all romantic languages.
   
   
   >  Even if we accept the specific line length recommendation as applicable to our sources, why should it apply only to Java code? Why not, most importantly, to our Markdown docs, which have much longer lines than 80 chars? What about Javascript, CSS, bash scripts, POM files, etc?
   
   This is a good point. I agree, to the extend possible, we should make this binding on all sources. Including for sure, on MArkdown and CSS and Bash scripts. I was not aware of this oversight. Thank you for bringing this to my attention.
   
   
   > What about log files and configuration? Those affect a (hopefully) much wider audience.
   
   Log files generally have no carriage return and therefor formats to whatever size you want. Configuration, I do feel that we should follow the 80 lines limit.
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] maobaolong commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

maobaolong commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-630488842


   @sodonnel How about the result of the +1's int the community sync call?


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] vivekratnavel commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

vivekratnavel commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-631032760


   @maobaolong Thanks for working on this! +1 LGTM


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648375813






----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] xiaoyuyao commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

xiaoyuyao commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-631659926


   Change Line length limit from 80 -> 120 is overall positive change for me, only once in a while I hit it with modern IDEs. A few things I can think of are multiple-window side-by-side will need to be adjusted
   e.g., 
   * Three-way merging on IntelliJ with longer lines, 
   * .md file editing with rendering window
    


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648375813

> The longest line is 7434 characters long. Even if you remove the `docker-compose`-specific prefix, which does not appear in real clusters, we still have 7420 chars.

> Each line starting with datanode_1 | follows a carriage return at the end of the previous line.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [hadoop-ozone] anuengineer edited a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer edited a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648358212

> I feel we would be better to accept the consensuses rather than veto the decision, and I would hope Anu would take onboard the direction the community desires over his own preference.

> The above link provides no evidence about the ease of reading source code.
I agree, but let me ask you this; how did you come to the conclusion that this is NOT applicable to the source code at all? What is the information used by you to come to that conclusion? That text does not have the word source code, and therefore source is some sort of magical thing? or are you under the impression that visually challenged people does not read source code and we don't need to care about them?

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [hadoop-ozone] anuengineer removed a comment on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer removed a comment on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648375979


   >  The longest line is 7434 characters long. Even if you remove the `docker-compose`-specific prefix, which does not appear in real clusters, we still have 7420 chars.
   
   What you are pointing out it is the there are lines which are really long, and generally when you see a line of 7434, you need a something that warps that info for you to read effectively. I was agree to that. This is an example of what I meant by no carriage return, not literally, but in the practical sense of machine generated stuff that gets consumed -- it is hard to even know what the length is. So we treat these insanely long lines as if they are without carriage return since whatever wrapping you need the consumer puts them up.
   
   >  Each line starting with datanode_1 | follows a carriage return at the end of the previous line.
   As you correctly pointed out, each of these line can be really long. -- **7434** chars is extremely long and has absolutely no bearing on the discussion of lines length which is human produced and neatly formatted like source code. That is why we are discussing 80/120 chars.
   
   There is also another point, it is trivial to attach all kinds of collectors to the log pipeline -- log4j itself ships with some many. So Transformation on data is designed to be trivial and if you need to make it different, it is simply possible.
   
   So to be precise: I was trying to stress the point that while each log is separated by a carriage return,  the general expectation is that lines can be really long because each line in a log is self contained -- and each source line that produces that information is producing it without reference to other parts of the code. This property makes it easy to write parsers and indexers over log files. In fact, there is a very large industry which produces tools to solve this issue. 


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] anuengineer commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

anuengineer commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-648540995


   > So, what is the harm in extending the line limit to 120 characters, when users can always consume it the way they want to? Wouldn't it be more accommodative to a wider set of audience?
   
   Because we have no data if the tools that visually challenged people use are designed to work well with these lengths. Since both of us are not experts, we have to rely on someone else who is deemed to be an expert? That is all I am doing.
   
   For a second let us assume that your argument is correct, then it would seem that the recommendations being made by accessibility.gov is wrong. Since the same rationale would apply to most text, I think the issue is more subtle, and we(both you and I) are not familiar with the recommendations and complications arising out of these disabilities.
   
   I also use really wide monitors, so I personally have no issues with this. What is missing in this discussion is the most germane part of the discussion -- That is -- what is the does accessibility mean and how do you make sure that the systems we build is usable and accommodating to the extend possible for others. Let us take the other side, let us say that we don't move from 80 to 120, what is the loss? Are all the programmers going to be less productive? 
   
   We can always find out.. Take top 10 code writers in Linux, monitor them with 80 char time vs. 100 chars. So find people who have always been writing 100 chars, then let us see if that improves productivity. Otherwise, this is classic bike shedding, no one needs to put in any research and everyone has an opinion, including that accessibility.gov is not applicable to us. 
   
   Once more, let us try to bring the discussion back to the merits of the question. Let us do some research and make an informed decision; or let us leave this question open, until such time that someone who does research in this topic is kind enough to comment on this. I am not saying that world is going to come to an end by moving to 120 chars. As for  Linux, it  is a run on BDFL model, so what Torvalds decides works. The ethos of Apache is completely different, we really put effort into building communities, hence my concern.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: ozone-issues-help@hadoop.apache.org

[GitHub] [hadoop-ozone] sodonnel commented on pull request #921: HDDS-3583. Loosen some rule restrictions of checkstyle

Posted by GitBox <gi...@apache.org>.

sodonnel commented on pull request #921:
URL: https://github.com/apache/hadoop-ozone/pull/921#issuecomment-644074007

> https://accessibility.digital.gov/ is about accessible websites (layout, navigation, etc.). It does not talk about making the source of these websites accessible.

Exactly. These recommendations are not about reading source code, which is read in a very different way to text. The above link provides no evidence about the ease of reading source code.

With what @elek has tried related to "soft-wrap function of IDEs" I feel code with longer line lengths can still be inclusive. I am even open to removing the line length restriction entirely and handling it at review time, but I worry about the reviews getting bogged down in comments about reducing line lengths on excessively long lines.

The reason I suggested having a vote on the preference, is so we can fairly access what the community desires. If the majority of people want to extend the line length, then for the sake of the community, I feel we would be better to accept the consensuses rather than veto the decision, and I would hope Anu would take onboard the direction the community desires over his own preference.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org