4rkal/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-12-13 11:56:33 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

Add logs for 8th dev meeting and Kovri meeting

Browse Source
This commit is contained in:
dEBRUYNE-1 2016-06-05 22:57:07 +02:00
parent bc47549455
commit 16293753ce
No known key found for this signature in database
GPG Key ID: B9145F6EBFA81C32
2 changed files with 525 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

241
_posts/2016-06-05-logs-for-the-kovri-dev-meeting-held-on-2016-06-05.md Normal file
View File

@ -0,0 +1,241 @@
---
layout: post
title: Logs for the Dev Meeting Held on 2016-06-05
summary: I2P StackExchange, Website content (by fluffypony), Coverity, Review of new open tickets, GNU social
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*June 6th, 2016*
#Logs
**\<fluffypony>** ok so I think let's move on to Kovri - anonimal, the floor is yours
**\<meeting-bot> [anonimal]** Thanks fluffypony, I need about 30-60 seconds.
**\<fluffypony>** ok whilst you're doing that, there are two committers to the Monero StackExchange proposal that are just shy of 200+ rep on the Bitcoin StackExchange
**\<fluffypony>** so they need some upvotes if you have rep on the BTC StackExchange
**\<meeting-bot> [anonimal]** https://github.com/monero-project/kovri/issues/179
**\<meeting-bot> [anonimal]** 17:00 (UTC)
**\<fluffypony>** http://bitcoin.stackexchange.com/users/35760/dontmindme
**\<meeting-bot> [anonimal]** 1. Follow up on I2P StackExchange
**\<meeting-bot> [anonimal]** 2. Follow up on fluffypony's website content review
**\<fluffypony>** http://bitcoin.stackexchange.com/users/35975/jun-li
**\<meeting-bot> [anonimal]** 3. Follow up on Coverity
**\<meeting-bot> [anonimal]** 4. Review assigned open tickets: status, code ideas (if applicable), etc.
**\<meeting-bot> [anonimal]** 5. Any additional meeting items
**\<meeting-bot> [anonimal]** 6. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** Point 1. is open to all.
**\<fluffypony>** i2p StackExchange is doing well: http://area51.stackexchange.com/proposals/99297/i2p
**\<meeting-bot> [anonimal]** Where do we stand?
**\<fluffypony>** 29% committed
**\<fluffypony>** 34/100 committers with 200+ offsite rep
**\<fluffypony>** but considering the small number of total committers (78/100) that's pretty impressive
**\<moneromooo>** I will have 200 tomorrow, probably. 1% more.
**\<fluffypony>** I would like to encourage anyone that has committed to the i2p and Monero proposals to please try drum up 200+ rep on one of the other Stacks by asking and answering questions
**\<meeting-bot> [anonimal]** Good, I was about to ask what else we could do.
**\<meeting-bot> [anonimal]** I'll start banging.
**\<fluffypony>** it's REALLY easy to get that much rep, the fastest way I've found is answering questions
**\<fluffypony>** but pick ONE StackExchange, as the rep isn't cumulative across Stacks
**\<meeting-bot> [anonimal]** Ok, anything else for point 1?
**\<fluffypony>** yes just a small thing
**\<xmrpromotions>** How do you feel about reaching out to leaders in the Tor community to request support? Some may be curious about I2P and active Tor SE users will really help us with activity requirements after launch
**\<fluffypony>** the deep web StackExchange proposal has failed due to lack of follow-through on commitments, so the i2p one is more necessary than before
**\<meeting-bot> [anonimal]** Hmm, tricky.
**\<fluffypony>** xmrpromotions: that's certainly a possibility, but the Tor community is going through a bit of a difficult time at the moment, it may be prudent for us to wait it out
**\<meeting-bot> [anonimal]** How do I say this quickly,
**\<fluffypony>** anonimal: by typing fast? :-P
**\<meeting-bot> [anonimal]** I have a strong impression that Tor does not care about I2P.
**\<meeting-bot> [anonimal]** Nothing personal, just different technologies.
**\<xmrpromotions>** If you are talking about the applebaum allegation I agree the timing is not great. I plan to largely ignore that news for now since the evidence is not even public
**\<meeting-bot> [anonimal]** I agree with fluffypony for now.
**\<meeting-bot> [anonimal]** I'd like to come back to that idea though in the future.
**\<xmrpromotions>** Okay. I wont make any aggressive outreach efforts to the Tor community at this time
**\<meeting-bot> [anonimal]** Ok, anything else on 1.?
**\<fluffypony>** nothing from my side
**\<meeting-bot> [anonimal]** 2. fluffypony, last meeting we talked about website content,
**\<meeting-bot> [anonimal]** I sent a draft. Status?
**\<fluffypony>** I have a content dump from anonimal - I've started with a page to the Monero site, and hope to have it PR'd by next weekend
**\<fluffypony>** I go to Berlin on Tue and then back to Amsterdam on Wed, and then back to Johannesburg on Thur, so there will be plenty of bored-in-the-plane opportunities to work on it
**\<meeting-bot> [anonimal]** Ok, I hope to get a chance to review anything because what I sent really was a 'dump' ;)
**\<fluffypony>** oh yeah definitely, plus you can always PR changes to the site, we merge everything there :-P
**\<meeting-bot> [anonimal]** lol
**\<meeting-bot> [anonimal]** Ok, anything else on 2.?
**\<xmrpromotions>** does 2 include gnu social or just the website?
**\<meeting-bot> [anonimal]** Free-for-all.
**\<meeting-bot> [anonimal]** xmrpromotions: any updates on gnu social?
**\<xmrpromotions>** Well I read up on GNU Social and really like the idea (I had not heard of it before) but I am worried about the time commitment it will involve to do well
**\<meeting-bot> [anonimal]** Could it be done 'good enough'?
**\<xmrpromotions>** Any suggestions for volunteers eager to help with that sort of thing that have extra free time right now
**\<meeting-bot> [anonimal]** I can help when the time comes.
**\<xmrpromotions>** I guess it depends what good enough means. I have never used GNU software but assume it will require many contributors providing good content in order to attract many users
**\<meeting-bot> [anonimal]** I've ran an instance in the past (personal, not public).
**\<fluffypony>** dEBRUYNE: is anyone on the social media team available to assist ?
**\<merkaba>** what is it about? I have some free time but I am not sure what this is
**\<merkaba>** if I have the skills required..
**\<fluffypony>** merkaba: oh I have a special job for you if you want to flex your Ruby skills ;)
**\<merkaba>** btw I am stefioan from reddit
**\<merkaba>** cool
**\<dEBRUYNE>** fluffypony: I am running out of free time currently, so hopefully someone else could pick it up (e.g. xmrpromotions and/or merkaba)
**\<nobbynoob>** what exactly is needed as help in the gnu social thing?
**\<meeting-bot> * anonimal** was just about to ask that
**\<xmrpromotions>** People to provide quality content and invite users is needed the most IMHO
**\<xmrpromotions>** I am not an expert and had not heard of it until 2 weeks ago
**\<nobbynoob>** so no coding or stuff, but posting content about xmr, its development etc?
**\<xmrpromotions>** here is the example someone gave me: https://quitter.se/social details here: https://gnu.io/social/about/
**\<meeting-bot> [anonimal]** Can twitter posts be cross-posted?
**\<xmrpromotions>** we are talking about Kovri now but yes we could use it for Monero too
**\<fluffypony>** maybe not automatically, anonimal, but certainly manually
**\<meeting-bot> [anonimal]** "If you build it, they will come".
**\<meeting-bot> [anonimal]** Why not baby steps for now: get it up and running, and we'll get on it and start using it?
**\<fluffypony>** agreed
**\<meeting-bot> [anonimal]** xmrpromotions: ETA on when it can be physically online?
**\<fluffypony>** xmrpromotions: shout if you need me to host it on one of the Monero infrastructure servers
**\<meeting-bot> * anonimal** side-channels fluffypony for preparations of 3. https://scan.coverity.com/projects/monero-project-kovri?tab=overview
**\<xmrpromotions>** I have not made any efforts to do that yet but my impression is pretty quick. All I did since last meeting was read the basic description of it and look at a few examples of how it has been deployed
**\<meeting-bot> [anonimal]** Can it be up by next meeting?
**\<xmrpromotions>** I think that is realistic.
**\<xmrpromotions>** It sounds like others will be willing to help provide content.
**\<meeting-bot> [anonimal]** Excellent.
**\<meeting-bot> [anonimal]** I'll start using it once its up.
**\<meeting-bot> [anonimal]** Anything else on point 2.?
**\<fluffypony>** nein
**\<meeting-bot> [anonimal]** Ok moving on to 3.
**\<meeting-bot> [anonimal]** "No builds were successfully analyzed yet."
**\<meeting-bot> [anonimal]** So, it looks like more Coverity setup issues.
**\<xmrpromotions>** thank you. I just dont want to spread myself too thin. The Deep web SE shutting down concerned me. We need to learn from that and ensure I2P and Monero SE metrics are all continually high enough during private beta
**\<fluffypony>** anonimal: argh. it's like they're trying to irritate me.
**\<meeting-bot> [anonimal]** xmrpromotions: good point, I will work on my rep.
**\<meeting-bot> [anonimal]** fluffypony: seriously, I have no idea why its so problematic.
**\<fluffypony>** anonimal did you see the hello world example ?
**\<meeting-bot> [anonimal]** Directions were followed to the T.
**\<meeting-bot> [anonimal]** fluffypony: Maybe, a long while ago. Link?
**\<fluffypony>** https://github.com/daksheshvyas/MyHelloWorld/
**\<fluffypony>** https://travis-ci.org/daksheshvyas/MyHelloWorld/
**\<fluffypony>** maybe check if there's not something they do there that we haven't done
**\<meeting-bot> [anonimal]** I remember those.
**\<meeting-bot> [anonimal]** Nope, our config checks out AFAICT.
**\<fluffypony>** https://scan.coverity.com/faq#frequency
**\<fluffypony>** we're way under teh frequency limits
**\<meeting-bot> [anonimal]** Is yrashk still on that side? Maybe he uses coverity/travis-ci?
**\<fluffypony>** he's already hopped offline afaik
**\<fluffypony>** it's nearly 1am his time
**\<meeting-bot> [anonimal]** I've also done several merges to branch coverity_scan to 'trigger' it, but to no avail.
**\<meeting-bot> [anonimal]** fluffypony: Any ideas on solutions? They really don't make it easy to contact them for troubleshooting.
**\<fluffypony>** hmmm anonimal
**\<fluffypony>** "You'll need to manually fill in your project specifics, including build_command_prepend and build_command."
**\<fluffypony>** we don't have the build_command_prepend
**\<fluffypony>** could that be a requirement ?
**\<meeting-bot> [anonimal]** I highly doubt it.
**\<fluffypony>** nothing would surprise me at this stage :-P
**\<tewinget>** saw my mention, will be available in...10 min or so if anyone needs me or wants my input on something. Otherwise, hello everyone and enjoy the meeting or whatever.
**\<fluffypony>** anonimal: so "branch_pattern: coverity_scan" means it'll only build changes to the branch named coverity_scan, noto the master branch
**\<meeting-bot> [anonimal]** Yes.
**\<fluffypony>** ok
**\<meeting-bot> [anonimal]** And last merge into coverity_scan was May 29th.
**\<fluffypony>** maybe we should just include a build_command_prepend
**\<fluffypony>** something like cd build && make clean
**\<meeting-bot> [anonimal]** But what would we put? exporting variables?
**\<fluffypony>** the example has:
**\<fluffypony>** build_command_prepend: "./configure; make clean"
**\<fluffypony>** build_command: "make -j 4"
**\<fluffypony>** maybe add a && cd ..
**\<meeting-bot> [anonimal]** Which doesn't make sense if the VM is fresh before every build.
**\<meeting-bot> [anonimal]** The build_command is sound, it would literally be a matter of splitting that up.
**\<fluffypony>** anonimal: yet the example has "make clean", so maybe they don't have a fresh VM each time ?
**\<meeting-bot> [anonimal]** so build_command_prepend: export CC=gcc-${GCC_VERSION} CXX=g++-${GCC_VERSION} && cd build
**\<fluffypony>** that could work if we're 100% sure it's a fresh VM
**\<meeting-bot> [anonimal]** It is. You can see it in all the travis build logs.
**\<fluffypony>** and Coverity runs on the Travis VM right ?
**\<meeting-bot> [anonimal]** Apparently?
**\<meeting-bot> [anonimal]** So, we could keep tinkering and hope for a result or email scan-admin@coverity.com
**\<meeting-bot> [anonimal]** Thoughts?
**\<merkaba>** guys I am leaving. if I can be help on any task feel free to contact me on reddit (/u/stefioan)
**\<fluffypony>** merkaba: will do, thanks
**\<meeting-bot> [anonimal]** Thanks merkaba.
**\<merkaba>** you are welcome
**\<fluffypony>** anonimal: I think let's try including a build_command_prepend, failing that I'll have to try reach out to Coverity
**\<fluffypony>** seeing as how they were so helpful last time
**\<fluffypony>** :-P
**\<xmrpromotions>** thanks merkaba. lets talk more about gnu social later
**\<meeting-bot> [anonimal]** merkaba:
**\<meeting-bot> [anonimal]** Isn't diaspora written in ruby?
**\<meeting-bot> * anonimal** checks
**\<fluffypony>** anonimal: he already left unfortunately
**\<meeting-bot> [anonimal]** xmrpromotions: if you see them again, https://github.com/diaspora/diaspora
**\<meeting-bot> [anonimal]** Ok fluffypony, I'll make the change and we'll see what happens.
**\<meeting-bot> [anonimal]** Anything else on 3.?
**\<fluffypony>** nope
**\<meeting-bot> [anonimal]** Alright, 4. Review assigned open tickets: status, code ideas (if applicable), etc.
**\<meeting-bot> * anonimal** quickly pulls up
**\<meeting-bot> [anonimal]** Ok, 4 new tickets opened since last meeting. All by yours truly.
**\<meeting-bot> [anonimal]** Joyous #187 and #191.
**\<meeting-bot> [anonimal]** Would any of the talented Monero devs be interested in diving into Kovri?
**\<meeting-bot> [anonimal]** I think those two tickets would be a great intro into the project (not being sarcastic).
**\<fluffypony>** lol @ 191
**\<fluffypony>** "but that is not the real problem"
**\<meeting-bot> [anonimal]** lol
**\<xmrpromotions>** https://diasporafoundation.org/ looks interesting! Should we consider that as an alternative to GNU social?
**\<xmrpromotions>** In some ways it sounds better, but does a lack of Windows support hurt us significantly? https://wiki.diasporafoundation.org/Installation
**\<meeting-bot> [anonimal]** xmrpromotions: I personally wouldn't as its harder to maintain and I don't believe it is anonymity friendly (if we host a pod)
**\<meeting-bot> [anonimal]** Diaspora simply crossed my mind since that ruby dev popped in.
**\<meeting-bot> [anonimal]** Anyway, re: 4.,
**\<xmrpromotions>** okay. fair enough. I will keeped focused on gu social then
**\<xmrpromotions>** gnu
**\<meeting-bot> [anonimal]** fluffypony: I can't see who is on that side. Are any c++ devs online?
**\<fluffypony>** hmmm
**\<fluffypony>** not sure if any of them are in front of their keyboards atm, let's leave that open-ended
**\<fluffypony>** if anyone wants to do an FFS proposal for it that's a great option
**\<fluffypony>** since it's easily measurable and challenging in a fun way
**\<meeting-bot> [anonimal]** I'm leaning towards a proposal or two.
**\<meeting-bot> [anonimal]** Ok, I'll see what I can propose before the next meeting.
**\<meeting-bot> [anonimal]** The tickets just keep piling up, help would be nice.
**\<meeting-bot> [anonimal]** Actually, more than nice.
**\<fluffypony>** yeah we're definitely feeling a bit shy on warm bodies on both fronts, will have to shake the ol' C++ cage and see who falls out
**\<meeting-bot> [anonimal]** At some point we'll have to have a meeting dedicated to dev awareness.
**\<meeting-bot> [anonimal]** I understand. I see everyone doing their best so what else could we ask for.
**\<fluffypony>** yup yup
**\<meeting-bot> [anonimal]** Anything else on 4.?
**\<fluffypony>** nope
**\<meeting-bot> [anonimal]** fluffypony: Do you have any formal ideas on #159?
**\<meeting-bot> [anonimal]** s/ideas/strategies
**\<fluffypony> I had a meeting with Richard Kohl from Bitcoin Wednesday and it came up, I need to think through some of his suggestions and then we can discuss it
**\<tewinget>** anonimal: what about C++ devs online?
**\<tewinget>** fluffypony: what's meeting-bot connecting to?
**\<fluffypony>** tewinget: irc2p
**\<fluffypony>** most C++ devs online want full time work, or overstate their abilities
**\<meeting-bot>** [anonimal] tewinget: ^
**\<meeting-bot>** [anonimal] Or are not really interested but want a payout.
**\<fluffypony>** yup
**\<meeting-bot> [anonimal]** But everyone isn't bad.
**\<meeting-bot> [anonimal]** But we also don't have enough awareness yet, but we're working on that.
**\<tewinget>** Hey, I'm only like 2 out of 3 there!
**\<fluffypony>** yesh
**\<fluffypony>** we'll get there
**\<meeting-bot>** [anonimal] tewinget have you played with Kovri yet?
**\<tewinget>** anonimal: I can't even remember off the top of my head what Kovri is...
**\* tewinget** does a quick google search
**\<tewinget>** oh, that. Not yet, why?
**\<meeting-bot> [anonimal]** lol because that's what the meeting is for :)
**\<tewinget>** I just got up not long ago, haven't had time to read all the scrollback
**\<tewinget>** :)
**\<meeting-bot> [anonimal]** Alright, moving onto 5. Any additional meeting items
**\<meeting-bot> * anonimal** thinking
**\<fluffypony>** nothing off the top of my head
**\<meeting-bot> [anonimal]** Me neither. I'm out of energy but I feel like there was more to discuss.
**\<fluffypony>** we'll push stuff forward, we can discuss anything urgent in the week, else we let it fall to the next meeting
**\<fluffypony>** which will be the 19th, by my calendar
**\<meeting-bot> [anonimal]** Ok. I was hoping to talk more code but devs seem to be away.
**\<meeting-bot> [anonimal]** C++ nerd stuff. Boost enthusiasts.
**\<meeting-bot> [anonimal]** alla Monero.
**\<fluffypony> let's flip it around for next meeting and do that first
**\<meeting-bot> [anonimal]** Anyway, next time then or during the week.
**\<meeting-bot> [anonimal]** Ok, sounds great.
**\<meeting-bot> [anonimal]** So point 6.,
**\<meeting-bot> [anonimal]** June 19th? 17:00 UTC?
**\<xmrpromotions>** Do you think many people in this group would be interested in I2P or kovri? http://area51.stackexchange.com/proposals/82234/open-source
**\<fluffypony>** anonimal: yup
**\<tewinget>** anonimal: if there's anything specific you can point to as far as C++ goes you can ping me
**\<fluffypony>** xmrpromotions: hard to canvas on an SE propsal
**\<xmrpromotions>** they could use more activity right now in public beta. If we encourage monero and i2p users to participate in their open beta maybe some of them will support us
**\<xmrpromotions>** they lack of ability to direct message makes it harder but some leaders use their real names
**\<fluffypony>** ok meeting is over, killing meeting-bot

284
_posts/2016-06-05-overview-and-logs-for-the-dev-meeting-held-on-2016-06-05.md Normal file
View File

@ -0,0 +1,284 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-06-05
summary: Introduction to Yurii Rashkovski and the C4 (predominant subject of the meeting), bit about Ring CT, bit about 0MQ
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*June 6th, 2016*
# Overview (by Aerbax)
An overview can be read here: https://hellomonero.com/article/monero-bi-weekly-dev-meeting-note-highlights-2016-06-05
# Logs
**\<fluffypony>** everyone ready to start? smooth / tewinget / dEBRUYNE / ArticMine / luigi1111w / luigi1112 / luigi1114 / NoodleDoodle / gingeropolous etc.
**\<ArticMine>** yes
**\<fluffypony>** hyc is excused, as he is at Pieter Hintjen's wake
**\* dEBRUYNE** slaps othe, moneromooo
**\<dEBRUYNE>** did we forget anyone? :p
**\<fluffypony>** don't think so
**\* dEBRUYNE** pages redfish
**\<dEBRUYNE>** Think that covers it
**\<fluffypony>** ok cool
**\<moneromooo>** Traditional Dutch greeting ?
**\<fluffypony>** lol
**\<fluffypony>** traditional Dutch greeting = "hallo"
**\<fluffypony>** so to start this meeting off I wanted to introduce yrashk, Yurii Rashkovskii
**\<fluffypony>** he's our special guest for today
**\<moneromooo>** o/
**\<fluffypony>** a little bit of background: as everyone is aware we've been looking at formally adopting C4, the Collective Code Construction Contract
**\<fluffypony>** which 0MQ uses
**\<yrashk>** hey hey
**\<fluffypony>** forgot to start meeting-bot, sorry
**\<fluffypony>** ok
**\<fluffypony>** so
**\<fluffypony>** with Pieter passing the mantel on to others one of the things that has happened is that yrashk has split some of these "soft skills" things off into something called Unprotocols
**\<fluffypony>** and what I wanted is for yrashk to tell us a little bit about C4 and COSS, and talk a bit about how C4 differs from the dreaded CoC - because adopting a CoC is simply not going to happen, but adopting C4 is a much better option
**\<fluffypony>** yrashk: the floor is yours
**\<yrashk>** fluffypony: thanks for the intro!
**\<yrashk>** yeah, actually Pieter has passed the unprotocols.org domain to me as well to play with the idea of extracting C4 and COSS (and more protocols in the future) into a separate domain from ZeroMQ and Digistan projects.
**\<yrashk>** as a side node, I think that action itself was very much in the spirit of C4 — it was a quick decision when I confirmed the fact that I want to volunteer, and the domain was passed over.
**\<yrashk>** what actually has drawn me to C4 was 1) its simplicity and 2) the rules that seemed to lead to less tension between people
**\<yrashk>** it's hardly possible to eliminate those, of course, but it's easy to create "hot spots" unintentionally
**\<yrashk>** I was thinking a lot about situations when things got heated before and when I myself got an urge to say things I later regretted
**\<yrashk>** and I saw that it was often over a value judgement
**\<yrashk>** ("do we need a feature X?" "do we implement it this or that way?" etc.)
**\<yrashk>** on the other hand, I had two arguments against CoC
**\<yrashk>** one was the Opalgate (https://github.com/opal/opal/issues/941), second one was a tad more complex... it felt like it's just a tool to punish or eject people... a guillotine. something not focused on the positive but rather on handling the negative stuff.
**\<fluffypony>** 100% agreed
**\<yrashk>** with C4, the main rules of the game were pretty simple: maintainers can't hold up your patch because of your value judgement
**\<yrashk>** even if it is stupid
**\<yrashk>** by the contract, everybody has a right to contribute
**\<yrashk>** the contributions must get merged in quickly (possibly after passing some sanity tests, like travis ci or a quick glance — that said, Pieter says, merge anything — you'll get a permanent record of trolls as well)
**\<yrashk>** so instead of having a hierarchy of contributors (maintainers' opinion being more important than others' by default), it's rather a flat space where maintainers' role is rather administrative, to enforce the process.
**\<yrashk>** if they (like anyone else) have a value judgment, they can express it either as another PR, or they comment on the patch after the patch got merged in.
**\<yrashk>** no bike shedding, no gatekeeping
**\<yrashk>** everything is record. anything can be easily reverted.
**\<yrashk>** is recorded*
**\<yrashk>** there's, however, an important philosophical principle behind. My current thesis (after conversing with different people) is that those who believe in individual intelligence (as opposed to aggregate group intelligence) have a harder time accepting C4.
**\<yrashk>** I met people who strongly believe that their experience and intelligence justify them being gatekeepers
**\<yrashk>** Pieter does talk about this in his books... basically arguing that individual intelligence applied to a particular work is rather a product of luck, not a systematic thing
**\<yrashk>** another important aspect of C4 that helps justifying just about every incoming PR, is that they are REQUIRED to contain a problem-solution statement (http://rfc.unprotocols.org/spec:1/C4/,section 2.3.7)
**\<fluffypony>** 'A patch commit message MUST consist of a single short (less than 50 characters) line stating the problem ("Problem: ...") being solved, followed by a blank line and then the proposed solution ("Solution: ...").'
**\<yrashk>** if a patch solves a particular problem instead of doing something that "might be helpful" or a "nice thing to do", it's easier to form your own opinion about the patch and see if any corrective measure should be taken
**\<yrashk>** (should I send a reverting PR if it is a total and utter BS? should I help improving this? etc.)
**\<yrashk>** I guess this braindump is good for starters. I'll take questions, if any?
**\<fluffypony>** ok so my first questions when I read C4 was about how it deals with people who are disruptive
**\<moneromooo>** Do you end up with a pile of crap in git, making view diffs a pain, bisect impossible, and generally having to waste time with crap ?
**\<fluffypony>** how does it do so in a non-guillotine manner ?
**\<yrashk>** (also, my short article on the subject https://blog.eventsourcing.com/productive-welcoming-vs-code-of-conduct-656b1571ddd6)
**\<yrashk>** fluffypony: first important thing, the way I understand it, is getting everything logged. merge disruptive people's commits. this way you get a permanent log of their behaviour.
**\<yrashk>** fluffypony: the rest is no different from other approaches: discuss the situation, if a correction can't happen, ban/eject
**\<fluffypony>** yeah I gathered the focus was on people self-correcting instead of being forced to correct
**\<yrashk>** moneromooo: you tell me https://github.com/zeromq/czmq/commits/master (as an example) — but basically, at least in my rationalization behind this, with great powers come great responsibilities
**\<yrashk>** when you treat people like adults, they tend to behave more like adults
**\<yrashk>** resulting in better ORs
**\<yrashk>** PRs*
**\<fluffypony>** I think the worst case scenario is someone submits a PR that intentionally introduces a backdoor, or intentionally breaks things
**\<yrashk>** I see this "optimistic" merge strategy as a way to treat people like adults
**\<fluffypony>** in which case the reverted PR is a black mark against them
**\<moneromooo>** You assume good faith, and a single bad faith person can throw a lot of crap in.
**\<yrashk>** fluffypony: exactly, a permanent record (as opposed to a rejected PR, which might be lost over time)
**\<fluffypony>** moneromooo: the issue is that doing it the *other* way means a bad faith person can waste everyone's time
**\<yrashk>** moneromooo: just like anybody can throw a lot of crap in, it can be thrown own the same way
**\<moneromooo>** But why would we want a permanent record of spam patches in the first place ?
**\<ArticMine>** So the concept is it is easy to undo / revert damage while leaving a cleat and objective trail for community accountability
**\<moneromooo>** yrashk: I'm worried about the history here, not the snapshot.
**\<yrashk>** moneromooo: because that helps identifying the bad actors at a later point ("yup, known spammer")
**\<moneromooo>** I imagine someone wanting to DoS us would not use the same email over and over again. They're good at sock puppets.
**\<yrashk>** it's a bit like a TSA thing — assume any passenger can be a terrorist and check everybody or do the intelligence work to single out bad actors.
**\<moneromooo>** Appeal to emotion.
**\<yrashk>** moneromooo: I guess it is highly dependent on the nature of the project — how many bad actors are actually interested to disrupt the project
**\<fluffypony>** moneromooo: consider it this way - if I'm compiling every-single-PR on every-single-platform and then testing-each-platform that's like an 2-3 hours per PR
**\<fluffypony>** so how easy is it to waste my time :-P
**\<yrashk>** that's actually a worse DoS
**\<moneromooo>** Do you do that ?
**\<yrashk>** time is the most valuable thing
**\<yrashk>** well, any PR review takes time
**\<yrashk>** and delays releases further
**\<fluffypony>** moneromooo: not since we've introduced that brief-code-review process, I just merge based on a visual inspection or a review by some known contributor
**\<fluffypony>** someone will compile it and see it's broken, and that someone doesn't have to be me
**\<yrashk>** C4 doesn't actually say the code should not be reviewed
**\<moneromooo>** I think there are a large number of possible positions between "compile every single PR and test on all platforms" and "rubber stamp everything". For instance, "have a look and reject if it doesn't pass the smell test".
**\<yrashk>** it's just done after the merging
**\<fluffypony>** moneromooo: we'll still have smell tests
**\<moneromooo>** That seems good to be ("I just merge based on a visual inspection or a review by some known contributor").
**\<moneromooo>** (and I try to review those fwiw)
**\<fluffypony>** also the action AFTER a failed smell test is important
**\<fluffypony>** ie. do we then have a long, drawn-out convo on github
**\<fluffypony>** or do we merge and revert, then explain to the person why that happened
**\<moneromooo>** As for building, you said you'd like a build bot IIRC. That'd help a lot there.
**\<moneromooo>** But the things I'm worried about are not held off by a build check.
**\<yrashk>** I use travis-ci so I can quickly see if PR breaks existing tests
**\<fluffypony>** yeah a build check solves a small subset of issues, 100% moneromooo
**\<moneromooo>** Maybe I'm paranoid, but I totally see part of the BCT jerks spamming our tree just because.
**\<yrashk>** do they do this right now?
**\<moneromooo>** Not to my knowledge.
**\<fluffypony>** moneromooo: it's MUCH easier to deal with that if we merge-and-revert than if we analyse and have long github discussions
**\<yrashk>** one of the main ideas behind C4 is to incentivize the positive contributors to get their stuff in quickly, without painless waiting and discussions
**\<yrashk>** I've beed in a situation where it just becomes so painful to abide by all the maintainers' wants to get something in
**\<fluffypony>** https://github.com/bitcoin/bitcoin/pull/5905
**\<fluffypony>** that PR is over a year old
**\<yrashk>** or when the maintainers are busy with other projects, or don't care about a particular problem enough to get my stuff in quickly
**\<yrashk>** without painful waiting*
**\<fluffypony>** and there are lots like that - full of discussion, "concept ACKs" and so on
**\<dEBRUYNE>** \<moneromooo> As for building, you said you'd like a build bot IIRC. That'd help a lot there. <= Zcash has a build bot afaik, might want to look into that
**\<fluffypony>** we use travis on Kovri
**\<moneromooo>** What are the problems now, beyond fluffypony's time ?
**\<fluffypony>** but hoping for a more OS-complete buildbot
**\<yrashk>** the other way to look at it — with C4, you have *all contributors* as reviewrs
**\<yrashk>** not just a handful of maintainers
**\<yrashk>** because everybody can initiate a corrective action
**\<fluffypony>** moneromooo: the main problem is that we don't want to become exclusionary, where only a handful of special contributors actually have successful PRs
**\<moneromooo>** That would not happen if there is a large enough numbers of people who can review and ack something.
**\<moneromooo>** And doing so would not need so muvch time from you either.
**\<yrashk>** yet another way to look it, if you have gatekeepers, they *would* have biases of different kind when looking at a patch, conscious or subconscious; C4 helps making project more diverse as value judgement or more subtle biases don't affect the input.
**\<yrashk>** (speaking of C4 vs CoC)
**\<moneromooo>** What is CoC ?
**\<yrashk>** Code of Conduct
**\<fluffypony>** moneromooo: Bitcoin has significant numbers of people that can review and ACK, yet there are 102 open PRs stuck in PR-review-hell
**\<yrashk>** CoC is about prohibiting certain types of behaviours and topics
**\<moneromooo>** This may be so, but I do not believe a free for all is better.
**\<yrashk>** in the name of attracting a more diverse set of contributors
**\<moneromooo>** (or at least, not before we have that problem)
**\<yrashk>** while removing gatekeeping/biases from reviews gets diverse opinions in proactively
**\<yrashk>** at least that's the hypothesis
**\<fluffypony>** moneromooo: ok so consider this: what would we do if a PR was submitted from an unknown person that increases the block time to 4 minutes
**\<moneromooo>** Bias is a fair point, but if there are many reviewers, then that should not matter much, iunless they all have the same ones. And if they do, maybe there is a good reason.
**\<merkaba>** (I know you guys are in the middle of other stuff. don't mind me. If there is anything I can help with I am ruby developer)
**\<moneromooo>** That'd probably fork at once.
**\<yrashk>** moneromooo: many projects are started by very small teams that are likely to be less diverse. therefore original maintainers might have similar biases.
**\<fluffypony>** moneromooo: I mean, would we merge the PR, or not ?
**\<fluffypony>** hi merkaba, and welcome :)
**\<yrashk>** I think in the case of this PR (block time), first important thing to consider is "does it have a valid problem/solution statement"
**\<moneromooo>** I'd hope not, but you're not allowed to then magic other assumptions after I said that :)
**\<yrashk>** maybe there's a problem nobody thought about?
**\<merkaba>** fluffypony, thank you
**\<ArticMine>** Then the question becomes is the problem valid?
**\<moneromooo>** If there's a problem nobody thought about, surely a reviewer would ack it ?
**\<fluffypony>** moneromooo: so the only difference under C4 is that we merge-and-revert and then tell the committer that they have to at least discuss something that controversial on the forum or on reddit or in dev meetings or something
**\<moneromooo>** So, same result, except a spammed git history ?
**\<moneromooo>** I *do* use git history :/
**\<fluffypony>** but spammed for a reason
**\<fluffypony>** a revert won't affect git bisect / git blame, I don't think ?
**\<moneromooo>** It will affect blame I think. It will certainly affect bisect time.
**\<moneromooo>** Regardless, I object to it for other grounds anyway (it seeming like shooting ourslves in the foot).
**\<fluffypony>** I think that maybe extreme examples like "change the block time" are bad for what I'm trying to illustrate
**\<moneromooo>** If/when there is a problem with people's patches being held up, and this causing contributors to become dissatisfied, we can talk about it again.
**\<moneromooo>** But then, the solution *should* consider something not totally at the extreme of "let's merge anything".
**\<fluffypony>** but moneromooo, I think we can do the opposite of "possibly causing dissatisfied contributors" - I think we can be extremely welcoming to contributors
**\<ArticMine>** Is a middle ground possible here?
**\<moneromooo>** That'd seem to be a great idea. I find monero very welcoming tbh.
**\<fluffypony>** well the current pitch is "let's merge everything once it's been reviewed by a known contributor"
**\<redfish>** what is the goal of introducing a new contribution guideline? what problem is being addressed here? attracting potential contributors? treating dissatisfied contributors?
**\<fluffypony>** so we still have that firewall
**\<fluffypony>** redfish: it's about establishing protocol that will survive through to when we have 500+ contributors
**\<moneromooo>** Do you mean "we'd still have" ?
**\<fluffypony>** moneromooo: yes I do
**\<fluffypony>** I hate the idea of "dev worship", where a single contributor is lorded over others, or viewed as being able to cure cancer
**\<moneromooo>** Then I agree. I was iunder the impression that there'd be no review by a known contributor. Sorry about that :D
**\<fluffypony>** to the exclusion of newcomers
**\<yrashk>** C4 kind of helps addressing the "problem of elders"
**\<redfish>** a newcomer can be dissuaded by review-block, but the newcomer should really have thicker skin
**\<redfish>** be careful of working with a strawmen for a newcomer contributor
**\<moneromooo>** 17:35 \<@fluffypony> moneromooo: not since we've introduced that brief-code-review process, I just merge based on a visual inspection or a review by some known contributor
**\<expez>** Code review on github is often about increasing code quality. Most contributors aren't cpp experts. If you just merge everything the code quality in the project will gradually decrease until changes become very hard. Or the regular contributors will have to cleanup the area they want to change prior to doing the work the actually wanted. This means a few bad apples will slow everyone down.
**\<redfish>** the attitute of "you don't want my patch? then, fuck you all" should not be encouraged
**\<moneromooo>** Then:
**\<moneromooo>** 17:53 \<@fluffypony> well the current pitch is "let's merge everything once it's been reviewed by a known contributor"
**\<moneromooo>** And:
**\<moneromooo>** 17:54 \< moneromooo> Do you mean "we'd still have" ?
**\<moneromooo>** 17:54 \<@fluffypony> moneromooo: yes I do
**\<moneromooo>** So I don't see what would change, then.
**\<expez>** If there's no discussion, just accept or revert, only the experts will make contributions whereas with some guidance a lot more would've been able to.
**\<moneromooo>** Currently: an ack by a known contributor.
**\<fluffypony>** expez: so by the same token every technical / scientific / medical article on Github should have declining quality until it's illegible garbage :-P
**\<expez>** fluffypony: I can't speak to that. I haven't seen any articles written by acretion.
**\<fluffypony>** I jest - I'm not suggesting the code be written by Wikipedia contributors
**\<fluffypony>** but let me use a practical example
**\<fluffypony>** a new contributor submits a new feature, but it breaks the Windows build and also doesn't include unit tests
**\<fluffypony>** option 1 is that we back-and-forth on his PR until he has it "perfect" by some undefined definition of perfection
**\<fluffypony>** this leads to ANY contributor being frustrated, because they've put in effort and maybe they don't even have a Windows box to work on
**\<fluffypony>** if, instead, we merge the PR and then create an issue for the broken Windows build + issues for the lack of tests, then ANYONE can fix those
**\<fluffypony>** not just the original contributor
**\<yrashk>** I think you really nailed it here: "undefined definition of perfection"
**\<moneromooo>** Dude. Why do you always present the alternative as the other extreme ? This is also a problem, but we don't have it right now.
**\<redfish>** anyone can push commits on top of a PR branch
**\<fluffypony>** redfish: yes they can, but until when ?
**\<redfish>** until the build is fixed and the unit tests pass
**\<meeting-bot> [anonimal]** Kovri meeting starts now but everyone is on a roll - and I'd like to read this huge backlog :)
**\<fluffypony>** moneromooo: sure, but that's like saying we shouldn't adopt any sort of governance structure because we're "too small for governance"
**\<moneromooo>** Not really. Maybe a bit.
**\<yrashk>** fluffypony: I decided to adopt C4 at eventsourcing.com before it's actually needed — the later you are the harder it is to change the governance
**\<fluffypony>** ^^
**\<moneromooo>** OK, that is a fair point.
**\<fluffypony>** literally the only change from a contributor perspective is you have to include a Problem...Solution statement
**\<moneromooo>** But we could adopt a governance that's not as seemingly footgun.
**\<fluffypony>** nothing else changes
**\<moneromooo>** Not the merge it all and revert at once ?
**\<fluffypony>** that affects those with push rights, not contributors as a whole
**\<fluffypony>** and because we're small we'll probably not even follow that to the letter all the time
**\<fluffypony>** BUT we'll have a documented process which contributors will be able to find and understand
**\<ArticMine>** There is a difference between a controversial change to the social covenant and failure to build for a particular OS
**\<yrashk>** in fact, C4 adds a review layer of a sort for "proven" maintainers as you can't push to master directly
**\<fluffypony>** ArticMine: agreed
**\<fluffypony>** http://oss-watch.ac.uk/resources/governancemodels <- this is a good read
**\<yrashk>** but other maintainers have to merge your PR in
**\<fluffypony>** from that article:
**\<lpaalp1>** hello
**\<moneromooo>** hi
**\<fluffypony>** "It is never too soon to define a suitable governance model. Without one, the chances of third parties wishing to contribute are considerably reduced. This is for a number of reasons:
**\<fluffypony>** - potential contributors will not know how to contribute
**\<fluffypony>** - they will not be sure what will happen to their contribution
**\<fluffypony>** - the project will not look serious about engaging with third parties
**\<fluffypony>** - there is no visible assurance that contributions will be managed in such a way that they will remain of value to the original contributor
**\<fluffypony>** Since you never know when a contributor might stumble upon your project, it is important to be ready from the earliest possible date."
**\<moneromooo>** "the project will not look serious about engaging with third parties" sounds like bullshit.
**\<fluffypony>** you'd be surprised by how many people who code for a living are afraid to submit a PR, moneromooo
**\<moneromooo>** The rest, OK.
**\<fluffypony>** we have fluffy ponies and cows and all sorts, not everyone wants to be in the middle of a farmyard
**\<moneromooo>** That may be so, but the sentence doesn't really mention that.
**\<redfish>** this quote assumes strawman for a contributor
**\<fluffypony>** hi lpaalp1 :)
**\<redfish>** imho, the danger from a troll newcomer is greater than a danger from a biased old-timer
**\<fluffypony>** redfish: C4 provides options to deal with trolls that don't self-correct
**\<moneromooo>** I'm totally fine with having a CONTRIBUTING file, or HTML page somewhere, etc, fwiw.
**\<fluffypony>** and it does so in a way that is least disruptive to the community as a whole
**\<moneromooo>** Well, I do not agree with this, since the harm to history has already been done.
**\<moneromooo>** (assuming we're back to merge-first, rather htan wait for an ack from a well known contributor)
**\<fluffypony>** no we're not back to that, lol
**\<fluffypony>** the review-first model still stays, we're just bolting C4 on top of that
**\<fluffypony>** at any rate, we've gone significantly over time, and we've only had one point for discussion, lol
**\<moneromooo>** OK. I feel like I'm being lied to here for some reason...
**\<fluffypony>** I think let's bounce this around over the next two weeks
**\<moneromooo>** Maybe because the discussion about it months ago was merge first.
**\<fluffypony>** and then at the next dev meeting we can make a decision if everyone is comfortable
**\<fluffypony>** moneromooo: that hasn't changed, we've just added the eyeball-review bit per the discussion with smooth ages ago
**\<moneromooo>** OK. Thanks.
**\<ArticMine>** Yes this needs a lot more thought and discussion before a decision is made
**\<fluffypony>** yes absolutely
**\<fluffypony>** so before we move on to Kovri
**\<fluffypony>** two quick things
**\<fluffypony>** 1. moneromooo - can you give us a brief update on how the RingCT stuff is going
**\<fluffypony>** and 2. dEBRUYNE wanted to discuss 0MQ briefly
**\<fluffypony>** also thanks for attending yrashk - much to think about and discuss :)
**\<moneromooo>** Well, I'm getting to know it. I'm hacking on bits at a time, so I get to learn bits of it at a time.
**\<yrashk>** fluffypony: thanks for having me!
**\<moneromooo>** It's progressing anyway.
**\<dEBRUYNE>** re: 0MQ -> tewinget is going to pick that up (i.e. continue). I am drafting the FFS proposal on his behalf and hope to put it out soon (probably at latest by monday/tuesday).
**\<fluffypony>** moneromooo: do you need any extra help, or are you ok with things at the moment ?
**\<moneromooo>** Rewrite, not contunue, AFAIK.
**\<moneromooo>** I'm ok with it, but I'll have questions for shen, most certainly.
**\<fluffypony>** kk
**\<fluffypony>** ok so I think let's move on to Kovri - anonimal, the floor is yours
**\<dEBRUYNE>** \<moneromooo> Rewrite, not contunue, AFAIK. <= Correct. Rewrite is in a sense also continue right? :P
**\<smooth>** hi guys, sorry i missed the meeting. Very interesting conversation. One thing stuck out at me:
**\<smooth>** 16:34 < yrashk> moneromooo: I guess it is highly dependent on the nature of the project — how many bad actors are actually interested to disrupt the project
**\<smooth>** I'd say that cryptocurrency is a pretty extreme case here in the negative. It is highly competitive and potentially contentious
**\<smooth>** both short and long term there are probably more people who want to disrupt and undermine than some other type of software
**\<smooth>** like a database engine, messaging system, etc.
**\<smooth>** which does not necessarily reach any conclusion but an obvious factor to consider
**\<fluffypony>** smooth: agreed - which, at least from my perspective, means that giving those actors any opportunity to waste our individual and collective time is a bad thing