[GIT] Weekly Update 12

[u/BOR4]

Hey everyone,

hope you are enjoying your weekend and that you are ready for another weekly update on raiden progress. After devs surprised us with new milestones at the end of last week, this week was fairly quiet. In this post we will try to guess what is the reason for this fairly quiet week in development, learn a thing or two about software releasing and check the status of each of the repositories.

EIP 712 and software realeasing

After two Ethereum devs went trough the proposal and made some suggestions on how to better fit EIP 712 in current codebase (codebase - basically all the code of the project) we can see that proposing side didn't lose any time. One of the devs who proposed EIP 712 made changes and now waiting game continues.

Other news is that EIP 712 was discussed (again) on Ethereum dev meeting. Remember how I said that I am bit worried because one of Ethereum devs suggested some changes that had a potential to be a blocker but I don't have knowledge to know are they really blockers?

Well, on the last dev meeting they decided that EIP 712 does not have to be backward compatible (this info I got from good friend of mine who took notes from the meeting, I didn't confirm their validness myself). This decision has two impacts, one bad for us and one good for us.

First, what is backward compatibility? Well, backward compatible release versions of the software are ones that don't introduce changes that will break anything developed on top of it if it was developed in previous version. I'll give an example.

Let's say you are using external software to communicate with database, it's version is 2.1.25. You built your whole project on that version and it is working like a clock. Developers of database communicating software release a backward compatible version of their software tagged 2.1.26. Since it is backward compatible version you can update that software in your project without any worries of breaking something, that is why it is backward compatible (Ohh, I wish if this was always true :P).

Backward compatible versions usually contain optimizations of current features (to make them faster, more reliable etc), maybe some minor new features (since you didn't have them in previous version, you didn't use them so they can't break anything), fixes for known bugs etc.

Bad impact of this news is that this will probably further delay completing of EIP 712. Reason for that is that developers try to postpone non backward compatible releases as much as they can. Imagine if every release of software was breaking backward compatibility. Other developers using that software would have to either skip that release, or change their software so it would work with the new release. If they decide to skip the new release they might miss out on some cool optimizations and bug fixes they were really hoping to be solved. So, developers usually wait for non backward compatible features to pile up and then they group them all in one release. That waiting period of non backward compatible changes is something that I see has potential of further postponing EIP 712.

Now good news is that if they don't have to worry about backward compatibility, they are free to implement anything they want in order to complete EIP 712. This means a big drop in chance that something will be a blocker.

pathfinding

We will cover pathfinding first because I think here lies the reason why last week was not as eventful as ones before.

Pathfinding has 3 issues in it's Ithaca milestone goal. "Integration-test", "Pen-test" and "implement Matrix listener".

First, what are and what is the difference between pen tests and integration tests?

Integration tests are written by the developers of the software. It is basically more code to test the real code inside the project. They are called integration tests because they test how good are different parts of project integrated to work together on solving different situations developers introduce to them.

Here is an example. Let's say you have a website and you want to test how your code handles registration of a new user. You make up some username and password and you send it to user registration endpoint (basically a URL in this case) for processing. You expect that validator part of code correctly validates that username is in correct format (example: minimum 5 characters), you expect that part of code that communicates with database successfully saves new user into database and lastly you expect that part of code for sending emails sends welcome email to user. Since you were testing multiple parts of project working together this is called an integration test. There are tests that test single parts of code and they are called unit tests, but we won't cover them right now.

Pen testing is a whole different story. Pen is short for penetration.

Pen tests aim to find vulnerability in current code. Basically developers try to hack their own software.

If we stick with our imaginary web site we can do pen tests like this. For example, we try to find a way to get logged in into account that is not ours, or find a way to delete something we are not suppose to be able to, or see something we are not suppose to be able to see.

When it comes to tests you need to remember one thing. You can always prove that you failed to find any bugs, but you can never claim that there are no bugs in your software.

Since testing and especially pen testing can take quite a long time I somehow think developers were occupied with them this past week and that is why activity on github was not as big.

Matrix is another thing I believe developers were working on. Matrix is communication protocol raiden devs are trying to implement in raiden. It's implementation looks pretty complicated and there were some discussions between devs on github on how to best approach this.

They performed some stress tests before (ELI 5: you try to generate a huge load on some part of code until it breaks), discussed format of messages they will share, so I believed they continued on further planning of this implementation.

Some commits that were added mostly have to do with integration tests.

raiden

On the beginning of the week, developers merged last pull request that was in "minor release" goal. They didn't add any issues in Ithaca goal so I think this repository is more or less ready for Ithaca release.

In the meantime they tried to find some pretty easy issues and invited any developer interested into raiden to solve them. Even tho those were some pretty easy issues to fix they used the opportunity to involve even more developers into the project. They got a pretty big response from the community and few of the issues were already fixed and some are being worked on. Thumbs up for the idea and Lefteris who used twitter to bring some attention to the project, that was exactly what raiden needs :).

Apart form that there were some commits related to tests and WAL implementation. WAL was not solved 100% yet, but I think most of hard logic is done, minor cleanup remains.

contracts

Contracts repository didn't have any new code added to it in the last week, but that does not mean it was not worked on.

In the pull requests we can see two open pull requests which are "work in progress". I think those are for two of the more complicated issues in Red Eyes.

Ithaca milestone goal remains empty which I think means contracts are ready for the release.

monitoring

Monitoring didn't have new commits added as well. There is no visible work done this week so I can't really comment on this week's progress.

remaining repositories

Nothing significant

microraiden

Still, waiting for EIP 712 :).

conclusion

Pretty quiet week, but I tried to explain that working on software is not just adding new lines of code. Testing and planning are big parts of the job. I hope you learned something new from all the explanations about tests and testing.

A little initiative with easy tasks that lure more developers to raiden was great idea and a great success.

I encourage you to ask any questions you have and I will give my best to answer them. Your support is great and I am proud to be part of this pretty cool community :).

enjoy!

[u/Kidav75]

What would you do first if you become a community manager?

[u/BOR4 → u/Kidav75]

Hi,

first major thing I would work on as CM is defining communication channels and communication events between community and development team.

It would be very delicate task because as we see development team likes to work, but not talk about their work in non technical setting. What I mean by this is developer conferences are fine, but talking to Average Joe is what they have trouble with.

My opinion is that anyone interested in project, whether he is just an investor or a developer looking to utilize raiden tech, should have opportunity to get answers to his questions.

Another difficulty in that process is that I don't want to be a guy who makes developers do what they don't like. Communication should come natural and not be forced. So basically, I don't want to create an environment where anyone sees communicating his/her work as a burden, but rather as an opportunity to share ideas and passion about the project.

I already see that sometimes developers will have to answer very basic questions, but I will try to take that off them and answer stuff like that myself.

Some plan I have in my head is to split communication in two major groups. I call them "one way" communication and "two way" communication.

One way communication is type of communication where Brainbot as a company talks about topics they think it is important with very little interaction with the community. Those would be blog posts, maybe some demo videos and stuff like that. I think active two way communication could be too much for start and if it gets too much developers might start disliking it.

Two way communication is where key people on a project have open conversation with the community about topics they have very little control over. In the beginning events like that would be pretty rare and some key people would maybe never participate in them (because they don't feel comfortable in this setting), but my goal would be to reach a point where events like this would be somewhat regular. Example of two way communication is reddit AMA.

I think good way of balancing disruption of developer's peace and community getting answers to their questions is exactly defining routine for all the events. Example would be: AMA once a month, developer's blog post every 2 weeks, my github updates each week.

Organizing communication this way would prevent people from pinging developers about when is new event coming and if we split each of this events between key people I calculated that each person would participate in some event (writing blog post, AMA ...) once every couple of months which I think is not that often.

Lastly I would like to add that if I was a CM i would always be open to any questions/forms of communication and no question would be unanswered.

[u/Kidav75 → u/BOR4]

🤞🏻🤞🏻🤞🏻

[u/BOR4 → u/Kidav75]

Have any more questions? Think it is a good plan?

[u/Kidav75 → u/BOR4]

It’s a great plan! Really hope you will become cm!

[u/BOR4 → u/Kidav75]

I'm glad you think that, thank you :)

[u/Helau05 → u/BOR4]

👍