On Wed, 2017-11-08 at 09:53 +0100, thierry bordaz wrote:
I see benefit to offer the support of modern language in 389-ds.
Rust developer can be interested to improve 389-DS with missing
Especially with the plugin-api we have the ability to support
without change to the core server. If a rust plugin hit a bug, we
have the ability to disable it until a rust expert can fix it.
#49325 implements rust functionality into a crucial core server
component (nunc stans). The consequence is that we do need to be
able to fix it rapidly. Correct ?
This is an optional replacement of the threadsafe queue. We already
have a C version that's used in production. So if we hit a bug in the
rust version, we already have a tried-and-tested C version to revert
back to :) So we are not in a rush to "fix" it if we find an issue.
As well, rust is not "enabled-by-default" in this patch - that's a
This is to say "we can optionally include pieces" today. We can still
back out :)
On 11/07/2017 03:51 AM, William Brown wrote:
has been in a ready to
> state for some time. This is still an optional integration (not a
> commitment to production rust), but I still want to check that it's
> okay to merge. It's been reviewed by an external Rust developer who
> happy with it, and checked by Mark. I would like to merge this on
> Friday, so I would love to hear comments about this before then.
> A discussion on production commitment will happen in the near
> future I
> think as to whether we want to pursue this path,
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.o
Red Hat, Australia/Brisbane