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 <[email protected]> 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 -- [email protected] > > To unsubscribe send an email to [email protected] > > 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/[email protected] > _______________________________________________ > 389-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] >
_______________________________________________ 389-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
