From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: Konstantin Osipov <kostja@tarantool.org> Cc: tarantool-patches@freelists.org Subject: [tarantool-patches] Re: [PATCH v2 4/4] Extract 'coll' library from 'core' Date: Tue, 26 Feb 2019 16:43:08 +0300 [thread overview] Message-ID: <fbf1d4b4-c3dd-ed77-4729-321a060bddcb@tarantool.org> (raw) In-Reply-To: <20190226131757.GA20707@chai> On 26/02/2019 16:17, Konstantin Osipov wrote: > * Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [19/02/26 16:12]: >> Usually we either do not write readme at all, or write it in >> the main header, describing the main functionality. And it is >> never about build details, dependencies, and limitations. >> >> All limitations are usually described with corresponding enum >> values and function comments. > > I'd say it's mostly sloppiness: > > kostja@chai ~/work/tarantool/src/lib > % ls */README* > msgpuck/README.md salad/README small/README.md msgpuck and small are separate repositories, with their own rules. Msgpuck is even a separate project, not just repo. And even here you can see, that small README does not speak about build and dependencies. It just speaks the same, what should be written as function comments. What, in fact, would be much more useful. Talking of salad - it is ridiculous, howling shame, and profanation. Just open that useless 'readme' and you will see, that it consists of one single line: "salad - Some ALgorithms And Data structures" That. Is. All. Readme just for readme. You can name my opinion whatever you want - sloppiness, or anything else, showing me that trumpery composed of empty or not existing READMEs, but the fact is that we really never write them, unfortunately, as a obligatory practice. As an opposite to your 'readme's above I can show you much more not described libs: - small/rlist (part of small, by the way, but not described in small/README); - small/lf_fifo (the same) - small/rb (the same) - all the salad/* libs (I do not count empty README as a readme) - lib/bit - lib/uri - src/curl - src/histogram - src/httpc - src/rmean ... I can continue longer, but do not see any sense in it. Libs, having their readme inside the header, as a special paragraph or as a part of main struct comment: - lsregion - quota_lessor - json - lib/bit - lib/bitset - lib/coll (yes, touched in this patchset, and it has a description of struct coll and functions in the header) > > > -- > Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 > http://tarantool.io - www.twitter.com/kostja_osipov >
next prev parent reply other threads:[~2019-02-26 13:43 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-26 12:11 [tarantool-patches] [PATCH v2 0/4] Move 'core' lib to src/lib Vladislav Shpilevoy 2019-02-26 12:11 ` [tarantool-patches] [PATCH v2 1/4] Remove dead dependency of http_parser on httpc Vladislav Shpilevoy 2019-02-26 12:12 ` [tarantool-patches] " Vladislav Shpilevoy 2019-02-26 12:21 ` Konstantin Osipov 2019-02-26 12:11 ` [tarantool-patches] [PATCH v2 2/4] Move 'http_parser' to src/lib Vladislav Shpilevoy 2019-02-26 12:21 ` [tarantool-patches] " Konstantin Osipov 2019-02-26 16:57 ` Vladislav Shpilevoy 2019-02-26 12:11 ` [tarantool-patches] [PATCH v2 3/4] Move 'core' and 'uuid' libs " Vladislav Shpilevoy 2019-02-26 12:22 ` [tarantool-patches] " Konstantin Osipov 2019-02-26 16:57 ` Vladislav Shpilevoy 2019-02-26 12:11 ` [tarantool-patches] [PATCH v2 4/4] Extract 'coll' library from 'core' Vladislav Shpilevoy 2019-02-26 12:23 ` [tarantool-patches] " Konstantin Osipov 2019-02-26 12:37 ` Vladislav Shpilevoy 2019-02-26 12:55 ` Konstantin Osipov 2019-02-26 13:09 ` Vladislav Shpilevoy 2019-02-26 13:17 ` Konstantin Osipov 2019-02-26 13:43 ` Vladislav Shpilevoy [this message] 2019-02-27 15:07 ` Vladislav Shpilevoy 2019-02-26 16:55 ` [tarantool-patches] [PATCH 1/1] Move 'info' library to src/lib Vladislav Shpilevoy 2019-02-26 22:08 ` [tarantool-patches] " Konstantin Osipov 2019-02-27 15:07 ` Vladislav Shpilevoy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=fbf1d4b4-c3dd-ed77-4729-321a060bddcb@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=kostja@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH v2 4/4] Extract '\''coll'\'' library from '\''core'\''' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox