-
-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release Checklist #229
Comments
of cargo audit and cargo outdated. Part of ISSUE #229
Rust dependencies all updated to latest, tweaks made to code where necessary. The GitHub CI now checks for CVEs and obsolete packages as part of the continuous integration run. |
In my opinion alpha version is ready to release (as we use current master branch state in production and it really do well work now). This issue should be renamed to "Beta release checklist" after alpha comes out. It's better to release alpha early and often next versions than doing really big milestones. What do You think? |
Mentally I have targetted an alpha release for the end of the month. I would like the vast majority of this checklist to have gone through by then. Also I have an increasing desire to move stuff out of Ispconfig.py and into the toml, where it would share the configuration for the bridge with the rust, and the setup simplified more for new users. Lastly, I would like to find and on-board at least two new users to find the things that those with experience with the product aren't finding before declaring that state. In the latter two cases, it is not the existing users' I care so much about, but the costs of supporting and on-boarding the next 100, or 1000, and everything we can do to improve usability before the alpha or final release, with the resources available will pay off down the line. I am glad that the code is considered stable enough to be in production. I have mostly been focusing on the math (which has some problems), a decent sim of real RTTs, and the netlink/sampling problems, none of which are barriers to the alpha. Some of the items on the checklist, look easy, like coping with licensing issues and verifying the python is up to date: @rchac ? As always I seek consensus on all we do or plan, and we have a meeting this thursday 1PM PST to discuss the remaining 31 open issues here: https://github.com/LibreQoE/LibreQoS/issues?q=is%3Aopen+is%3Aissue+milestone%3Av1.4 which we can punt, modify, or fix. |
to a proper atomic bool, for a completely unnoticable performance improvement.
I did a global I've moved a couple of trivial locks to atomics, for a not-really-measurable performance change (an uncontested mutex lock is approximately 13 nanoseconds in userspace on an 8 core AMD Fx at 3.6 ghz; that's VERY hard to beat). I've abandoned the effort to use lock-free structures because they are consistently outperformed by locks in the benchmarking I performed. An A few minutes ago an advisory hit about Rocket; I'll update when the fix exists. It's pretty trivial and doesn't seem to make us vulnerable to anything. The audit system alerted me to it. |
I've put up a PR that checks for GPL3 in the Rust side of things. There isn't any. I haven't looked at the Python side. (PR #292 ) |
For the other items:
So I've done the parts of the "Checklist items on code passes" that make sense. The rest read more like an abstract guide on code creation, minus the parts about not optimizing things that don't matter. |
I appreciate all your pithy comments. Try to remember that we will one day on board devs far less experienced than us, and rather than hanging over every line of commit, I like to have deeply embedded the basic checklist items such as these. Someday, perhaps, there will be more. Pieces of feedback on your feedback:
2.1) EAGAIN, EBUSY, etc can and will bite you on high speed interactions with the kernel. I am merely going to wait until it bites you as hard as it has bitten me, before stressing on this point anymore.
I agree, that presently, we are collecting and keeping around too much useless data. Also, ideally we move away from parsing system tool output into more directly programming the kernel.
Aside from that, we can work on coding guidelines and other items to try and Very happy to see you take the time to review this checklist, and express your feelings about it! |
Moving to two items I did not check off: It is nice to have a grip on structure sizes. Traditionally I tried to construct something that took every structure we had and showed the size of it. Even more so, it is nice to have a grip on possible memory leaks and the why of their growth patterns, and from what they may be coming from. As for tracking heap allocations, well, you just ran into that problem in the chrome bug you have been coping with with. When you have a program that needs to run without leaks, for months at a time, even the smallest leak, will bite you. Both of these are just nice to haves at this point. |
One of the reasons I adopted Jem allocator is that it has a lot of tooling
built in. I'll see about grabbing some output from it, eg
https://gist.github.com/ordian/928dc2bd45022cddd547528f64db9174
Strings are mostly a problem at the C boundaries in Rust. Once in a Rust
string, it's a smart pointer that stores length (null termination is awful,
Wirth solved it in the 70s...). It deallocates as soon as it goes out of
scope (same mechanism as a C++ destructor) - and dangling pointers, use
after free literally won't compile. So they are a performance concern, but
not a safety issue anymore. (Memory leaks are not part of Rust's safety
guarantee, but you really have to work to make them by accident)
…On Sat, Mar 25, 2023, 2:09 PM Dave Täht ***@***.***> wrote:
Moving to two items I did not check off:
It is nice to have a grip on structure sizes. Traditionaly I tried to
construct something that took every structure we had and showed the size of
it. Even more so, it is nice to have a grip on possible memory leaks and
the why of their growth patterns, and from what they may be coming from.
As for tracking heap allocations, well, you just ran into that problem in
the chrome bug you have been coping with with. When you have a program that
needs to run without leaks, for months at a time, even the smallest leak,
will bite you.
—
Reply to this email directly, view it on GitHub
<#229 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADRU437EY3N3STJ3QXMRAPTW547FXANCNFSM6AAAAAAUICTRO4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
What is release checklist for v1.5 and what is "the date"?:) |
When it's done! We don't have a formal list at this time. I hope to include (not complete):
|
What is the blocker for releasing v1.5rc1? |
Several merges, some testing and a handful of minor bugs in the configuration system. That, and we have day jobs! |
Deb package build for develop branch are available (daily/ondemand/commit)? |
Checklist items on code passes
Testing
Writing
Outreach plan
The text was updated successfully, but these errors were encountered: