Hi all,
Background: https://pagure.io/389-ds-base/issue/51140
Ludwig and Mark both raised some good points here. First is that features today (EntryUUID, LDAPSsoToken) are both locked behind another language. Rightly so, they shouldn't be hidden here forever. As well, Mark wants to ask what it would take to enable by default.
** Why did I use the fedse.c to load a plugin entry?
Because we don't (fully) support startup migrations yet. Mark has privately reminded me that he has reviewed https://pagure.io/389-ds-base/pull-request/49579 and that I should revive it. This v4 plugin adds a stateful assertion of entries allowing better migrations beyond what fedse.c's bootstrap can achieve. IE we can create an entry if it does not exist, and modify it partially if an admin has changed it (ie we can tweak defaults but without affecing say pluginEnabled). There was an issue viktor raised about pbkdf2 where it could not be disabled, and this would resolve it. Most likely, I will break the on startup migrations out from the v4 plugin patch set, and make it it's own change, and move some of the content from fedse.c and friends into this.
** TODO list to get rust enabled by default.
I think there is still a bit of work to do to enable by default, but I think we are pretty close. Roughly ordered, this is the list of things that has to happen to let us enable rust by default.
- everyone -> test that you can build and run tests with --enable-rust --disable-asan in your development environment so that we can work out and issues that may exist for us as developers.
- william -> fix the intentional name leak in the rust slapi plugin interface to use lazy_static. Today this triggers LSAN which breaks basic test suites.
- william -> clean up libsds linking and some of the related elements
- william -> revive and make on upgrade configs better (see above), potentially break it out from the v4 plugin patch.
- william + mark -> check that our respective major distros/releases can build with --enable-rust in release rpms
- william + viktor -> check that we can pass with --enable-rust and --enable-asan, especially in CI
- anyone interested -> update wiki contributing guide to include rust as a requirement
- (optional) anyone interested (but not william) -> add a section to the wiki on using rust in development
- team -> agree we are happy, and make configure.ac have --enable-rust by default
- team -> after a few weeks / months, remove the ifdefs, duplicate C versions of Rust features, and enable/disable features from configure.ac
Does this seem reasonable to everyone? I really want to make sure we do this right as a team, and we are all happy with it (I don't want a repeat of nunc-stans ;) ). If we agree on this, I will open some tickets up, add the relevant blocks/ordering and assign out the work.
Thank you all!
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
https://github.com/389ds/389-ds-base/
All developers, and any other interested individuals, should make sure
to "watch" this repo. We moved off of Pagure and onto github, but the
Pagure subscribers were not migrated. So if you want to keep an eye on
what's happening make sure to watch this project!
--
389 Directory Server Development Team
Hi team,
so the migration to GitHub was successfully completed!
389 Directory Server repo is now available on:
https://github.com/389ds/389-ds-base
<https://github.com/389ds/389-ds-base/issues/4317>
The issue tracker is here:
https://github.com/389ds/389-ds-base/issues
Pull-requests are accepted here:
https://github.com/389ds/389-ds-base/pulls
The old Pagure repo is now closed and read-only.
All Bugzillas are updated with the new links and Devel Whiteboard numbers.
Commit email notifications still go to:
389-commits(a)lists.fedoraproject.org
If you have any questions, please let me know here or on IRC - #dirsec or
PM to spichugi.
I've sent 389ds organization invitations to all active developers.
Please, check your mailboxes.
Sincerely,
Simon
Hi team,
for the last couple of weeks, I was working on the migration tool that will
allow us to switch 389-ds project to GitHub.
It will be done through the weekend 2020-09-12 - 2020-09-13.
I was testing it on a custom repo for some time but, please, review the
code, if you would like to:
https://github.com/droideck/patogith/
I will open the example 389-ds-base [migrated] repo tomorrow when my final
run will finish.
I've managed to disable Github notifications but there are two more things
that should be taken into the account:
1. Pagure notifications - as Viktor has suggested, probably, we can ask
Pierre-Yves Chibon <pingou(a)pingoured.fr> to do this for us at Friday.
2. Bugzilla notifications. It may be that it's not possible to disable it
for everyone involved. In that case, it will be one time thing that will
spam you with 3000 emails. :) But I hope not.
Regards,
Simon