[389-devel] Use of rust for new logging backend

2019-05-13 Thread William Brown
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. 


—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


[389-devel] 389 DS nightly 2019-05-14 - 91% PASS

2019-05-13 Thread vashirov
https://fedorapeople.org/groups/389ds/ci/nightly/2019/05/14/report-389-ds-base-1.4.1.2-20190513git974c802.fc29.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


[389-devel] please review: PR 50366 - CLI verbose mode displays clear text passwords in console output

2019-05-13 Thread Mark Reynolds

https://pagure.io/389-ds-base/pull-request/50366
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org