0.2.0 Priorities

[caribpa]

Because I am observing that more and more issues are being assigned to the 0.2.0 milestone, I'd like to know what is its ultimate purpose as there are issues ranging from high priority bugs (#400), to automated packaging (#387), and shell changes (#616).

@ret2libc and @XVilka (summoned because you are the ones assigning issues to the 0.2.0 milestone), what is the objective of 0.2.0 and the future for 0.3.0? (you get extra points for explaining it in a short sentence 😃)

P.S. Is there going to be any usage for the 0.2.X milestones?

[ret2libc]

I can talk for myself right now:

Objectives for 0.2.0 are making artifacts we provide to work well, making Rizin more widely and easily available, move forward the newshell conversion and refactor rz_core_cmd* calls. (This is one sentence, does it count? :D)

With more details:

• making artifacts we provide working well: this was the result of multiple changes already landed in dev. For example, by moving everything to subprojects you can now download the rizin-src tarball with all the dependencies (capstone as well) included in the tarball. This allows distros or users in general to build Rizin without downloading anything else, if they want. Also, this means that the static versions provided should actually work. This would mean fixing Make Rizin work when the whole install dir is moved #392, for example.
• making rizin more widely and easily available to new users to start getting more users/devs: one of the things we agreed on time ago is that we want our users to use releases and not having to stay always on dev. That means it should be easy to retrieve rizin and install it on their systems. See Configure repositories to deliver Rizin to linux distro users #387 but also macOS homebrew support #160 . This cannot be done until 0.2.0 because we need the released src tarball to include the needed dependencies, see point above.
• keep moving commands to newshell and improve it as we go: this is unfortunately not as easily "quantifiable" because there are many many commands to convert. Also, we realize some things need improvements in RzCmd as we convert existing stuff.
• remove most uses of rz_core_cmd* call whenever possible by using the proper API instead. Again, this is a quite long task but we have already achieved some good results. This will allow us to refactor the code with more confidence as we move, because if you change something you get a compiler warning instead of realizing just after X days/months that a command called through rz_core_cmd* has changed its syntax/does not work anymore.

Please keep in mind we are not one person, so others have other (important) priorities as well, while we try to work on what we enjoy at the same time. I know @XVilka is moving forward with types (which includes some refactoring to use API instead of rz_core_cmd and also moving type commands to newshell) and @thestr4ng3r with Projects (like serializing bin and io, which are not as well supported as we'd like).

That said, I agree it would be awesome to be a bit more focused and organized and if you want to help with that (dealing with issues, feature requests, personal interests, etc. is not easy!) it would be awesome and very much appreciated!

[caribpa]

Objectives for 0.2.0 are making artifacts we provide to work well, making Rizin more widely and easily available, move forward the newshell conversion and refactor rz_core_cmd* calls.

Wow, that's marking-expert level material! 😂

That said, I agree it would be awesome to be a bit more focused and organized and if you want to help with that (dealing with issues, feature requests, personal interests, etc. is not easy!) it would be awesome and very much appreciated!

Yes, I'll try to help with the overall organization of the project (including Cutter if it's ok with @ITAYC0HEN) as I don't have the time to dive in the code ATM (though I still peek it). Of course, you are all always free to tell me when I'm overstepping, as it is not (and won't be) my intention 🙂

[caribpa]

keep moving commands to newshell and improve it as we go: this is unfortunately not as easily "quantifiable" because there are many many commands to convert.

Regarding this point, I think that it would be best to separate the newshell commands in "groups" (not necessarily means a or z command groups), so that we could place some of these "groups" in one milestone (others in a different one, etc). I'll create a different discussion for this.

[caribpa]

remove most uses of rz_core_cmd* call whenever possible by using the proper API instead. Again, this is a quite long task but we have already achieved some good results.

This point is more or less similar than the newshell command "groups", let's choose some files to refactor for a milestone. I'll create another discussion for this.

[caribpa]

Regarding the first two points, I see that the first one affects the second one, so let's make the first one a priority (over the second one), but let's create a different discussion for them.

[ret2libc]

No need for a discussion for the first point. It is essentially completed, at least the part related to having all dependencies included in the src tarball.

[caribpa]

I think the following issues currently present in the 0.2.0 milestone should be left out:

• MSYS2 failure to build: ../librz/socket/socket.c:275: undefined reference to `rz_sys_signal'  #337 - Left out because it doesn't seem Rizin related and there are other ways for compiling Rizin in Windows
• Allow to disable debug tests in rz-test command line #336 - rz-test feature addition is not a priority (now)
• Split afvx to two commands - one for variables and one for function arguments #332 - Newshell commands for 0.2.0 are already assigned (see Porting commands to the newshell #710)
• Fix test_r_analysis_var test #282 - Left out because there seems to be no progress since it was opened and doesn't seem trivial
• Meaningless strings are printed #38 - Left out because it is only a cosmetic issue and not a priority for now
• Add tests for s commands #419 - Left out because it may make sense to create tests for s while investigating how to port it to newshell
• TinyCC failing debugging tests #398 - Left out because of lack of progress and it is not a priority for now to support "non-mainstream"
• Refactor Graph mode (librz/core/agraph.c) to use API instead of commands #397 - Left out because it may be complex and currently graph mode is not broken
• _ (underscore) command wrongly updated if previous output was filtered #579 - Not a priority for now
• Commands that are both groups and have multi-mode cannot be listed #657 - Left out because a discussion is still going about the syntax/output
• Sort out the ah* commands #698 - Left out because doing this makes sense when also investigating for porting to newshell

@ret2libc, @XVilka, @thestr4ng3r, @ITAYC0HEN, @Maijin, @kazarmy, @wargio, @yossizap, @08A, @pelijah, @officialcjunior what do you think? (tag whomever I wrongfully forgot)

My objective is to start delimiting (more or less) the milestones, so that we could start providing releases with changelogs, announcements, etc. This release cycle is important not only for bringing new people to the project, but also for development (the end user can report a bug saying that something broke in the 0.3.0 release that was working in the 0.2.0 instead of making them hunt for the specific commit that created the bug in a "releaseless" project).

Remember that we want the bugs and ugly things to appear before reaching 1.0.0 (and ideally way before that) so that we have the ability to rework everything from scratch, breaking all APIs, if we need to, for making life easier in the future. We don't want to be in a position where the only option to keep going is adding more bolognese to the spaghetti 😉

[wargio]

in the 0.2.0 i want to also include the changes I'm doing for java.

[ret2libc]

#419 - Left out because it may make sense to create tests for s while investigating how to port it to newshell

Please note that s commands were already ported. Anyway, I'm perfectly fine in keeping this out of release. It is, I think, a perfectly fine task for some who wants to start working on rizin.

[ret2libc]

I am ok with the list of issues you'd like to remove. I agree they are a bit "out of place"

[caribpa]

Please note that s commands were already ported. Anyway, I'm perfectly fine in keeping this out of release. It is, I think, a perfectly fine task for some who wants to start working on rizin.

My bad then, though the test cases still need to be done, right?

[ret2libc]

Please note that s commands were already ported. Anyway, I'm perfectly fine in keeping this out of release. It is, I think, a perfectly fine task for some who wants to start working on rizin.

My bad then, though the test cases still need to be done, right?

Yes, tests still need to be done.

[wargio]

I expect 0.x.0 to break stuff. like changes on newshell side when converting old commands to the new format.

[caribpa]

That's the main point of 0.x.0 😃 Though things will break faster the more people is tinkering the project, so defining a development cycle with releases will improve the reach of the project (as most people are lazy to compile things on their own) 🙂

[Maijin]

"That's the main point of 0.x.0"

Defining what x.0.0, 0.x.0 and 0.0.x would involve should probably be put somewhere too.

[XVilka]

One more forgotten but crucial thing - restore SPDX copyrights and finish the proper conversion: #683

[caribpa]

Indeed, that's why they remain in the list for 0.2.0 changes 🙂

[XVilka]

Locking this discussion since https://github.com/rizinorg/rizin/releases/tag/v0.2.0 is out.