Merge Development branches

[majestrate]

changes include:

• fixes CryptoPP exceptions that were thrown, those were (probably) caused by using 1 instance of CryptoPP's PRNG across multiple threads.
• bundling linting tools so others don't need to scavenge the net for them
• (toy) lua interpreter that is/was useful for finding bugs, disabled in build by default
• logging now shuts up if disabled in configuration

[anonimal]

I would like to merge if you are willing + able to make the appropriate adjustments/fixes:

• Either revert or let's come to a conclusion regarding cli args
• i2lua came out of nowhere. I think re: testing, a testnet is good, but I wonder if creating two routers like this is the best way to go about doing it. For now, if it helps, we can keep i2lua as long as there is a clear distinction between kovri and any contributing tools:

2016-01-21 19:02:00     &anonimal       I really don't think any of the lua stuff should be in core, it can all go into contrib or src/tests/i2lua or src/contrib/i2lua and linkup there. Also, I'm still reviewing because I see at least a few issues.

• CPPLINT.cfg and the lint hook are cluttering root, can you move them to contrib/cpplint? (is CPPLINT.cfg really necessary)?
• This PR is much better than the last one re: style but you did miss files (no cpplint), and functions + pointers + namespaces are not inline with our contributing guide
• It would help if you could PR more often. Lots of stuff like this that cover various topics are more time-consuming to accurately review.

[majestrate]

re: varmap

+psi | if it's really THAT bad we can always add another method that takes a varmap

re: i2lua not in core

+psi | lua really SHOULD be in core as it adds hooks to things to the netdb tunnel building parts

re: linting stuff

good point

re: style

I tried really hard but I don't see anything that is massively off? can you point to an example so I can correct it?

re: pr more often

can do.

[anonimal]

Awesome, I'm glad you're flexible. I'll be flexible too.

• Re: an example, I really don't know what to say because I see an entire codebase of them. For starters, re-reading the contributing guide. For more recent examples, see Massive refactor of #72. Update style guidelines. #75 as it directly refactors your recent work. To get an overall sense of the style and rythm, I would look at phase 1 of Quality Assurance #58. Also, nowhere in our base are our functions_styled_like_this(). I have a huge respect for your effort and the fact that your trying to stay inline. Now that you've told me this, I don't feel as strongly about any blatant disregard to the agreed upon contributing guide (not just style but development model and workflow model).

2015-11-30 18:45:58     +psi    no thoughts besides we need a strict code style
2015-11-30 19:03:18     &anonimal       I don't like google but https://google.github.io/styleguide/cppguide.html inherits good points
2015-11-30 19:04:38     +psi    it's strict and specific, like it

Our model is dependent on communication and I think we need more of that before every idea is PR'd. Workflow too + topic branches, especially so we don't have to cherry pick things like this in the future. The absolute last thing I want to do in a review is trip over style, so if it helps that I keep refactoring any PRs (and that in turn is the example), then I can do that (I learn by example too).

On that note, these other factors effect my opinion re: codebase decisions:

• I'm seeing persistent inability to run cpplint, even after putting the linter into the codebase. This has huge repercussions for large PRs of which I have to review. I don't have the time to catch the more difficult bugs because I'm looking at the glaring project management issues. I want that to be resolved so I can dive into your kickass new code with you because that would help the project and help me get a better perspective of your ideas. Re: keeping the linter in our codebase (which I don't think we should do), if future devs refuse to read the contributing guide and subsequently $ pip install cpplint on their own, then I seriously question the quality of any C++ contribution they can make.
• I'm also seeing inattention to important security details and subsequent mistakes. This can happen when someone hasn't lived with the code long enough to gain a sense of oversight; e.g., observe and remember important points that I clearly commented in the code. Things like this would not have been missed had the code been given better review before attempting to fix something that wasn't broken (and thus breaking it).
• Re: more breakage,
  2016-01-20 15:22:24 +psi the reason why it broke was because i didn't see that we had benchmarks
  I know there is a lot to cover, so I understand, but benchmarks that have been there since the start of the project. We all make mistakes and errors, but this is what I'm talking about re: needing to live with the code longer to remember it and to gain a knowledgeable perspective before acting on it.
• Re: varMap: it's trivial at this point. Patchwork like this only causes more problems that it solves. Breaking CLI functionality is a moot point. If it must be done, it should be taken care of swiftly and in one swoop as to not impede development or it should be dealt with in another branch all-together. If this is a real issue, then that's what /issues are for and an new issue should be opened. I'm am soooo for tearing everything down to make it better, but we agreed to more communication and to focusing on two sepearate entities: me: design and functionality, you: crypto. We can/should/will continue to do both but that can only work as long as we open communication before PR'ing (preferably before committing). I am not opposed to adding another method, but we should talk about it before acting on it. I would ask the same of myself if I started working on crypto.
• Re: i2lua, I feel that the scripting interface is too young to include in the codebase at this time. Hacking kovri to work with the new router is, IMO, not inline with Kovri's mission and I don't see much point in having new or existing devs deal with Lua (let alone a separate router) as a means to creating a testnet. More research and discussion is needed or else the codebase will become erratic and unmanageable and work/time is wasted. A testnet is a freaking great idea, I want it badly, but there has to be better options. If not, then I'll support pouring more community effort into i2lua. I really want cool new things like this, and if this weren't an anonymity project (and if we had more devs) I would say "balls-to-the-wall free-for-all!" but I don't feel comfortable doing that at this point. Since I think you'll continue to work on i2lua, maybe keeping it another branch for now would be best and, also, keeping it out of core (regardless of what it hooks) as that would be for the better in terms of our project. When i2lua matures (and if we decide to keep it with kovri and not a separate program), we can always merge into development. In the mean time, we really should discuss our options, preferably at our next meeting.
• Re: client, core: it's simple: anything that interfaces with core is either client or api. core is the kovri router and only the essentials that keep the I2P network intact and online. What is currently there is essentially all that needs to be there. I've slaved all my free non-work time over the past 3 months living and learning this codebase and I'll need a very good argument as to why any of the current design logic should change, but I am open to change. Right now, I don't see any substantial arguments to supplement the existing design with any additional code outside of what is currently missing and that needs to be implemented (Quality Assurance #58, TunnelEndpoint: implement out-of-order message fragment reassembly #74, Enforce message expiration #77, etc.).
• Re: communication; IMHO, responding to questions, asking questions, bringing up ideas for discussion and not just doing something and expecting/assuming that it will/should be merged; all needs more communication. This is why I'm adamant about implementing Agile; because it ensures open communication so that we know what the other is doing on a daily (or semi-daily) basis. I've screwed up in the past re: lack of communication when starting Quality Assurance #58, these things happen and I'm sorry for that, but as a result, I think we've learned that communication can issues be fixed. Since this is FOSS, I know I can't ask for anything from anyone but if I didn't think that everyone involved with this project can do great things, then I wouldn't be here to begin with.

So, I think we should get the fixes out of this PR and into development a.s.a.p. If your tree is clean (after merging into a personal dev branch perhaps?), maybe a git revert of everything here but the fixes and then a new PR will do the trick. I'm open to ideas. I don't want to squash anyone's workflow but I also want to be on the same page.

[majestrate]

nevermind then, this is way too much bullshit for me to go through.

[anonimal]

If by "bullshit" you mean failing to follow through with your agreement and the basics of our contributing guide, then I agree. If you mean "bullshit" as in the facts-of-life behind running a real organization, then I disagree: basic standards must be set and adhered to.

I don't know who you work for, but I can't imagine that they tolerate that kind of immaturity and response. Like I've said before, I'm flexible and open to discussion - but rage quitting is not the solution, and you're always welcome to finish what you've started.

[majestrate]

If by "bullshit" you mean failing to follow through with your agreement and the basics of our contributing guide, then I agree. If you mean "bullshit" as in the facts-of-life behind running a real organization, then I disagree: basic standards must be set and adhered to.

There is too much red tape for a project with 2 (maybe 1 soon?) contributors.

I don't know who you work for, but I can't imagine that they tolerate that kind of immaturity and response.

Such a lovely and mature (totally not patronizing or condescending) way to frame your response.

Like I've said before, I'm flexible and open to discussion

Your actions so far seem to contradict this statement.

rage quitting is not the solution, and you're always welcome to finish what you've started.

Allow me to contribute code if you're serious about that.

[anonimal]

Allow me to contribute code if you're serious about that.

This is your 10th pull request to Kovri since Nov. 17th, 2015. All previous 9 have been merged without question. This is the only one that had issues which came under scrutiny before merging.

@fluffypony will merge this in the morning, SAST time. Once that's done, we'll open the appropriate tickets for the issues that will arise.

[anonimal]

Re: #83, @fluffypony and I have agreed to revert the appropriate commits instead of opening a slew of tickets because:

A) Neither of us have the time to do so
B) The reasoning for reversion was clearly stated above

However, I will open tickets for an introduced bug, an i2plua feature request, and a review of RouterContext.

Topic branches

Our contributor workflow is inline with Bitcoin's so commits like 8605937 have a better chance of causing less friction for any development team if appropriate topic branches are used for each relevant commit/PR.

From now on, we will allow a wiki-git philosophy where we will merge regardless of quality, but all contributors should realize that this is a community project and everyone may have to (at some point) self-sacrifice for the good of the software. All contributors are free to do whatever they want within their own forks but, like any pull request, a "request" is just that: a request to be considered - not a demand to be satisfied.

Thank you 🙇