Details

    • Sub-task
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • None
    • Documentation
    • None

    Attachments

      Activity

        IMHO - if commit only removes whitespaces, or clean up .gitignore or any other change that does nothing to functionality (documentation?), then Jira issue is am overkill, as it will only generate some spam Also - it's hard to wait for someone to give "+1" just for empty line removal, and I think that one of most important Jira's role is an ability to make review.

        hcorg Konrad Grochowski added a comment - IMHO - if commit only removes whitespaces, or clean up .gitignore or any other change that does nothing to functionality (documentation?), then Jira issue is am overkill, as it will only generate some spam Also - it's hard to wait for someone to give "+1" just for empty line removal, and I think that one of most important Jira's role is an ability to make review.
        jensg Jens Geyer added a comment -

        Assumed, I do some whitespace cleanup. Do I have to add a JIRA for that? I mean, nobody ever added a JIRA ticket for maintaining .gitignore, so probably not, since it is not a content change. Opinions?

        jensg Jens Geyer added a comment - Assumed, I do some whitespace cleanup. Do I have to add a JIRA for that? I mean, nobody ever added a JIRA ticket for maintaining .gitignore, so probably not, since it is not a content change. Opinions?

        I'll remove 'contents' from ASCII requirements then, and leave it to be 'lang specific'

        hcorg Konrad Grochowski added a comment - I'll remove 'contents' from ASCII requirements then, and leave it to be 'lang specific'
        roger Roger Meier added a comment -

        which languages need source files in utf-8 with BOM?
        e.g. js, html, nodejs, java....

        roger Roger Meier added a comment - which languages need source files in utf-8 with BOM? e.g. js, html, nodejs, java....

        ok, those base things I've added in https://github.com/hcorg/thrift/commit/51d9f16454f4e2c78c6b529f5841bcb471130fb7

        I'll try to move forward with naming etc

        hcorg Konrad Grochowski added a comment - ok, those base things I've added in https://github.com/hcorg/thrift/commit/51d9f16454f4e2c78c6b529f5841bcb471130fb7 I'll try to move forward with naming etc

        unfortunately not all git versions support .gitattributes (at least - that what I once learned the hard way when I had to fix a lot of files with window's line endings...), so just to be sure - we had to add note for developers

        but still - gitattributes for newer git should help

        hcorg Konrad Grochowski added a comment - unfortunately not all git versions support .gitattributes (at least - that what I once learned the hard way when I had to fix a lot of files with window's line endings...), so just to be sure - we had to add note for developers but still - gitattributes for newer git should help
        roger Roger Meier added a comment -

        +1
        we need a .gitattributes file
        see: https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

        What about a Code Style Chapter here: doc/contributing.md

        roger Roger Meier added a comment - +1 we need a .gitattributes file see: https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html What about a Code Style Chapter here: doc/contributing.md

        +1 for codesf

        for LF/CRLF issue we could provide git settings (autocrlf for windows wtc)

        hcorg Konrad Grochowski added a comment - +1 for codesf for LF/CRLF issue we could provide git settings (autocrlf for windows wtc)

        One thing I think we should try to enforce globally is a white space policy. This has sort of been implied for some time but it would be nice to make it explicit.

        I suggest:

        White Space Policy
        ===============
        1. Spaces must always be used in source files for indentation, Tabs are forbidden.
        Rational - Everyone has different tab settings. With tabs indenting source, good code in one editor looks like an error in another editor. We have a huge community and a vast set of languages. Spaces are the common denominator.

        2. Line Endings must always be LF only.
        Rational - Mixing CRLF with LF causes build failure on our key CI platforms.

        3. Lines must not end with trailing spaces.
        Rational - Invisible characters at the end of a line take up space in the repo, cause git warnings and can cause identical code to report line changes creating wasteful commits.

        codesf Randy Abernethy added a comment - One thing I think we should try to enforce globally is a white space policy. This has sort of been implied for some time but it would be nice to make it explicit. I suggest: White Space Policy =============== 1. Spaces must always be used in source files for indentation, Tabs are forbidden. Rational - Everyone has different tab settings. With tabs indenting source, good code in one editor looks like an error in another editor. We have a huge community and a vast set of languages. Spaces are the common denominator. 2. Line Endings must always be LF only. Rational - Mixing CRLF with LF causes build failure on our key CI platforms. 3. Lines must not end with trailing spaces. Rational - Invisible characters at the end of a line take up space in the repo, cause git warnings and can cause identical code to report line changes creating wasteful commits.

        People

          Unassigned Unassigned
          hcorg Konrad Grochowski
          Votes:
          0 Vote for this issue
          Watchers:
          4 Start watching this issue

          Dates

            Created:
            Updated: