Hi
I will also help from QA team(Test and automation ) , i started learning "rust" 6 month ago (not regular ). I know 2% (may be).
Regards
Anuj Borah
On Wed, May 15, 2019 at 8:20 PM Simon Pichugin <spichugi@xxxxxxxxxx> wrote:
On Tue, May 14, 2019 at 01:21:28PM +1000, William Brown wrote:
> Hi all,
>
> So it's been a while since I pushed this, but again, I think I want to bring this up. I'd like to write the new logging backend in Rust.
>
> I'll start with a summary:
>
> Pros:
> * Faster development time due to stricter code correctness guarantees
> * Modern and safe language to lower number of bugs in implementation
> * Much better libraries for interacting with things like json and thread safety
>
> Cons:
> * Another language in the codebase ...
> * We need to learn it to work on it
> * Vendors need to be ready to build with the toolchain
>
> I've talked through some of these thoughts with Mark a bit, and I really think it's time we did this - or gave up on pursuing it. I have been running the rust enabled version of ds for a few years now with no issues. SUSE is also in a position where they are able to and ready to build DS with Rust (I'm assuming RH could easily also be brought to parity here).
>
> So the main barrier becomes us: the most common argument is we don't know enough or have enough experience. However I think this argument is flawed, in the fact that there are many parts of the code where we already only have 1 or 2 experts in that area - often when we look into a bug or a feature, we always have to learn new things, we have to read the code, understand even the unique styles of how that was written for the time, and then do work. This would be no different. I think we are all capable of learning and working with these tools.
>
> By this point, Gnome is looking into Rust as a mainline part of the desktop, Samba has started to look into it, Firefox is already shipping Rust components. I think that Rust is here to stay, and is not some passing trend.
>
>
> So what do we think? I think if there are no major objections I would like to do this in Rust. I'll also commit to providing C-Rust FFI documentation for the team, resources to help understand what's going on, and like always, I will be sure to comment all my code thoroughly as part of this improvement.
Hi William,
I am more than interested!
I'd like to learn it one day anyway.
So if there will be no objections and we'll go forward now,
I think, it is important to agree on some points of decreasing a bus factor:
- As you said, it should have very detailed comments on all of the
language features and technics you'll use.
- I think it will be nice to have an additional documentation which will
describe the basic setup for the development you use. All the toold you
need to develop, compile, test and debug.
- Also, some nice links for the basic tutorials on Rust types, concepts, etc.
- I think, we should have detailed unit tests. It will help to
understand the code better and we will have less bugs (hopefully).
And the final and big point I wanted to mention:
- We should be prepared for a slow review process because we have quite limited
recources in the team and a lot of work should be done (WebUI still has to be refactored to React,
and it is only a small piece of the workload).
Also, I think, it makes sense to have the smallest Rust PRs that can be put together as an independent unit.
But everything is just my opinion and I don't know what others think and
if everyone is prepared to join it. I am feeling excited though :)
Thanks,
Simon
P.S. check the contribution guide please. Espesially a part about
'rebase-force-push'. I think it is nice not to force push during
the review process (and rebase-squash only after you got an ACK).
>
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
