Post #31812

27242b556317d204596bb20c828b2ed7c843d7fa6bd601e88b0688f001b442da
733b0bb9568e0f41c5b402b3027e6d27dd94bf0b1a00738e27803dcb32c843d0
e2c61429397da55a5ee7749088023feb12e0e8e261dfeba32ee7c0794f9a12f8
Signature verified

The signature from the blockchain entry has been verified against an identity on this server.

{"entry_date":1613469801,"post_data":{"edit_count":0,"last_edit_date":0,"last_edit_user_id":0,"message_sha512":"a89d4474bb69ca05ef844f1e0127e962c70499307b180a34c2aa0207ad63c8717e0eb1e897f2f4a89c0564e37ffff1048f3e71233343e062be410d068b2e72c9","node_id":115,"post_date":1613469801,"thread_id":5666,"user_id":8},"post_link":"https:\/\/forum.factomprotocol.org\/threads\/sphereon-bv-niels-klomp.5666\/post-31812"}
The entry content as it exists in the database. This should be verified against the blockchain entry.
[Sphereon BV] Niels Klomp
[QUOTE="David Chapman, post: 31785, member: 2"]
Hello Niels.

Clay, Who, and Luap worked hard to make trash code reasonably stable and add some TPS to the network. As far as I know, none of them are working on the code in any meaningful way. I've seen proposals that others start to take up that slack. As we both know, all developers are not created equal. The Factom codebase is still a mess and it will take a good developer months to figure it out. As such, there may be an understandable desire to bring back some people who are familiar with the codebase but don't write the best code which could result in the network taking a step backwards. This creates risk for outside entities like my own that hope to utilize the protocol.

What steps would you take to ensure that only quality, well tested code makes its way to production?
[/QUOTE]
Hi David,

Obviously that is a concern of mine. Talking from the Off-Blocks and Sphereon perspective, obviously we share the same concerns about the protocol as a whole. We need a steady protocol and we cannot have the types of stalls we had 2 years ago. One does have to be realistic about last year as well. We have only had something like 2 stalls, but we also only had few updates to the software, with a declining amount of ANOs, meaning the amount of changes was low and auth-network size shrinking.

I am not too happy with a repetition of what we have seen in the past regarding core-dev grants (a few bullet points and then hoping everything works out), or the anchor spec (let's make this really flexible thing that can do everything and have 2 FTE working on it for quite a time, without having the spec first, whilst the protocol is struggling to stay afloat) It would make sense to be realistic about the situation and make sure we create as much value in the shortest amount of time.

Just like in the other areas, we need a plan for development. I am not in the camp of "hey it is open-source, so everyone can do as they see fit". That is valid if none get paid. Most of the development in here does get paid and thus the work has to come from a plan. If people really believe that is how the well-known open-source companies work, I guess they have a skewed vision of the level of professionalism in these companies.

We definitely need to work on the QA and ensuring we have public CI/test infra in place, do proper code reviews. That start with ensuring the development tickets/stories are well defined and scoped. Having developers on board with proper software development principles. It also means having the proper people in the proper roles. It happens that all of that is of course my real background, so getting that in place if money wouldn't be an issue isn't going to be the problem. It will not happen overnight and whether we will have the money to put that in place in a really good way is another matter. But suffice to say that I rather have slow and good progress, then rushed progress with al kinds of new nuts and bolts just because developers feel like it.
This is the raw content, without BBCode parsing.
Top