for sure. i see no reason it wouldn’t. anything on the current web will be possible plus a lot more
A lot of github action on the testnet launch tool…
Yes, I’ve been noticing that too. fingers crossed!
Is the CLI part of safe_network repository or is it still done in sn_cli?
I think it is too early to expect anything major, until there is some work done with the CLI.
Just so you know, we still don’t have a completely working setup yet. The whole test suite for the CLI isn’t passing yet. In particular, there are some issues around file retrieval.
We just merged some things into
sn_cli because I had so many outstanding changes and they were becoming a bit unwieldy to have on one branch.
We’re working hard to get a full passing test suite though.
I see a lot of new pull requests flying in left & right in the Github safe_network repo, meaning massive amounts of work being finalized Where do these PRs come from? Is there a list of PR todo’s where we can see what still needs to be done, or how does that work?
Reason I’m asking is many of these PRs are new feats, but I thought most of the crates were already done, so why adding new feats?
Thanks in advance for any layman’s answers to a (hopefully) silly question!
When you make one refactoring, you see possibilities for three refactorings.
When you make three refactorings, you see possibilities for nine refactorings.
There is no end to it unless you limit yourself.
Most of the work at the moment will be new features because it is new code rather than refactoring existing code. Everything to do with DBCs for example, and this results in numerous PRs rather than one big PR for everything to keep the changes contained and manageable.
There is no refactoring here, it’s bug fixing and features turning into code, mostly DBC work and things like backpressure, message flows, removing qp2p connection handler/queue etc. The refactor we did do was swap out the error handling for a more modern version that allows scoping and colour etc.
Refactor can happen after Fleming/Beta, but the code is not in need to a refactor right now, it’s just simplification and getting the features in place.
One are we are considering is blind sigs or pederson commitments for DBCs though, it’s based on auditability and proof of payment issues. A nice problem to discuss though.
Is this ‘code as you go’ or planned in any way? If planned, can we see what’s on the planning? I realise that is question is similar to asking for a timeline which has been asked too many times, but not quite the same.
Maybe “restructuring” is better word.
And if plans are changing, it is interesting to see what is the exact reason for that.
I’m sure that plans exists, but sharing them with community is time consuming process.
Also recognizing plans as wrong may be hard psychologically.
They built a website just for you to answer these questions…
I doubt that it answers question about “what happened during last months”.
It is more about “what happened during last years”.
edit: of course what will happen is equally important since we are talking about plans.
There are Thursday dev updates for that.
What will be happening next week & why previous “next week plans” changed?
It would be interesting.
To be clear: weekly updates shows what is happening.
The same thing can be determined by looking at Github commits.
What is needs to be done and what is not needs to be done anymore is usually corresponds to Github issues.
Which is almost empty for SN. Compare: Issues: 10 Open, 11 Closed, Pull requests: 11 Open, 486 Closed.
Things change. You’re asking for level of detail that is unreasonable, bordering on potential troll territory.
Do you agree that it is important to look at plans from week or month ago and analyze what happened since that time?
Not to blame developers, of course, but to predict future.
Like with popular image for James Webb telescope launch date:
For example, if plans are changing too often, then you may predict that next (updated) plans will change soon too.