diff options
author | Karel Kočí <cynerd@email.cz> | 2016-06-30 16:11:56 +0200 |
---|---|---|
committer | Karel Kočí <cynerd@email.cz> | 2016-06-30 16:11:56 +0200 |
commit | 9931e0888b2419326ae10ebbfae532261c5c125f (patch) | |
tree | 7504be5daccbb7b7d1ea396754de47b11ed790e5 /vim/bundle/YouCompleteMe/CONTRIBUTING.md | |
parent | e573b3020c032400eed60b649a2cbf55266e6bb0 (diff) | |
download | myconfigs-9931e0888b2419326ae10ebbfae532261c5c125f.tar.gz myconfigs-9931e0888b2419326ae10ebbfae532261c5c125f.tar.bz2 myconfigs-9931e0888b2419326ae10ebbfae532261c5c125f.zip |
Fix submodules
Diffstat (limited to 'vim/bundle/YouCompleteMe/CONTRIBUTING.md')
m--------- | vim/bundle/YouCompleteMe | 0 | ||||
-rw-r--r-- | vim/bundle/YouCompleteMe/CONTRIBUTING.md | 112 |
2 files changed, 0 insertions, 112 deletions
diff --git a/vim/bundle/YouCompleteMe b/vim/bundle/YouCompleteMe new file mode 160000 +Subproject 0de1c0c9bb13ce82172b472c676035cd47cf6a6 diff --git a/vim/bundle/YouCompleteMe/CONTRIBUTING.md b/vim/bundle/YouCompleteMe/CONTRIBUTING.md deleted file mode 100644 index d3e158f..0000000 --- a/vim/bundle/YouCompleteMe/CONTRIBUTING.md +++ /dev/null @@ -1,112 +0,0 @@ -Writing good issue reports -========================== - -First things first: **the issue tracker is NOT for tech support**. It is for -reporting bugs and requesting features. If your issue amounts to "I can't get -YCM to work on my machine" and the reason why is obviously related to your -machine configuration and the problem would not be resolved with _reasonable_ -changes to the YCM codebase, then the issue is likely to be closed. - -**A good place to ask questions is the [ycm-users][] Google group**. Rule of -thumb: if you're not sure whether your problem is a real bug, ask on the group. - -**YCM compiles just fine**; [the build bots say so][build-bots]. If the bots are -green and YCM doesn't compile on your machine, then _your machine is the root -cause_. Now read the first paragraph again. - -Realize that quite literally _thousands_ of people have gotten YCM to work -successfully so if you can't, it's probably because you have a peculiar -system/Vim configuration or you didn't go through the docs carefully enough. -It's very unlikely to be caused by an actual bug in YCM because someone would -have already found it and reported it. - -This leads us to point #2: **make sure you have checked the docs before -reporting an issue**. The docs are extensive and cover a ton of things; there's -also an FAQ at the bottom that quite possibly addresses your problem. - -Further, **search the issue tracker for similar issues** before creating a new -one. There's no point in duplication; if an existing issue addresses your -problem, please comment there instead of creating a duplicate. - -You should also **search the archives of the [ycm-users][] mailing list**. - -Lastly, **make sure you are running the latest version of YCM**. The issue you -have encountered may have already been fixed. **Don't forget to recompile -ycm_core.so too** (usually by just running `install.py` again). - -OK, so we've reached this far. You need to create an issue. First realize that -the time it takes to fix your issue is a multiple of how long it takes the -developer to reproduce it. The easier it is to reproduce, the quicker it'll be -fixed. - -Here are the things you should do when creating an issue: - -1. **Write a step-by-step procedure that when performed repeatedly reproduces - your issue.** If we can't reproduce the issue, then we can't fix it. It's - that simple. -2. Put the following options in your vimrc: - - ```viml - let g:ycm_server_keep_logfiles = 1 - let g:ycm_server_log_level = 'debug' - ``` - - Run `:YcmToggleLogs stderr` in vim to open the logfile. Attach the contents - of this file to your issue. -3. Add the output of the `:YcmDebugInfo` command. -4. **Create a test case for your issue**. This is critical. Don't talk about how - "when I have X in my file" or similar, _create a file with X in it_ and put - the contents inside code blocks in your issue description. Try to make this - test file _as small as possible_. Don't just paste a huge, 500 line source - file you were editing and present that as a test. _Minimize_ the file so that - the problem is reproduced with the smallest possible amount of test data. -5. **Include your OS and OS version.** -6. **Include the output of `vim --version`.** - - -Creating good pull requests -=========================== - -1. **Follow the code style of the existing codebase.** - - The Python code **DOES NOT** follow PEP 8. This is not an oversight, this - is by choice. You can dislike this as much as you want, but you still need - to follow the existing style. Look at other Python files to see what the - style is. - - The C++ code has an automated formatter (`style_format.sh` that runs - `astyle`) but it's not perfect. Again, look at the other C++ files and - match the code style you see. - - Same thing for VimScript. Match the style of the existing code. - -2. **Your code needs to be well written and easy to maintain**. This is of the - _utmost_ importance. Other people will have to maintain your code so don't - just throw stuff against the wall until things kinda work. - -3. **Split your pull request into several smaller ones if possible.** This - makes it easier to review your changes, which means they will be merged - faster. - -4. **Write tests for your code**. If you're changing the VimScript code then - you don't have to since it's hard to test that code. This is also why you - should strive to implement your change in Python if at all possible (and if - it makes sense to do so). Python is also _much_ faster than VimScript. - -5. **Explain in detail why your pull request makes sense.** Ask yourself, would - this feature be helpful to others? Not just a few people, but a lot of YCM’s - users? See, good features are useful to many. If your feature is only useful - to you and _maybe_ a couple of others, then that’s not a good feature. - There is such a thing as “feature overload”. When software accumulates so - many features of which most are only useful to a handful, then that software - has become “bloated”. We don’t want that. - - Requests for features that are obscure or are helpful to but a few, or are - not part of YCM's "vision" will be rejected. Yes, even if you provide a - patch that completely implements it. - - Please include details on exactly what you would like to see, and why. The - why is important - it's not always clear why a feature is really useful. And - sometimes what you want can be done in a different way if the reason for the - change is known. _What goal is your change trying to accomplish?_ - - -[build-bots]: https://travis-ci.org/Valloric/YouCompleteMe -[ycm-users]: https://groups.google.com/forum/?hl=en#!forum/ycm-users |