Hi all, Something that has been on my mind lately has been how we manage the release of new features, reverting, and more. We've had two major reverts lately (filter optimising, nunc-stans), so I've been thinking about: * How we can develop new features in isolation (reviews don't get left for months because we don't know if they are "ready") * How we can revert without "git revert" * How we can test * How we can release features when we are ready. I've been thinking that what we did with nunc-stans is pretty close to what we want, but we need some refinement. "Feature gating" is where we have a series of on/off switches for features. This way we can release with features in the "off" state, and enable them in testing and when we are ready to release. When we are happy, we set them "on". If an issue happens, we can disable them, or if they are good, we eventually can remove the switch. At the moment we do this in cn=config but the issue is if users ever set their own values - suddenly our defaults-upgrade mechanism won't work because we always respect the user values. This means features being in the "on" state when we want to revert, and features in the "off" state when we want to enable them on release. This also has an issue in bootstrapping during ds setup becuase we need the server built to enable the feature, but enabling the feature may break the setup. Additionally, we may want the feature we are testing to be part of cn=config, so that creates a "chicken and egg problem". I'm wondering if we should add a different feature gating mechanism. First, this mean cn=config is "just configuration" and we avoid the above. It also means we resolve some of the above issues, and we can more easily test. A few ideas: * defaults.inf can list booleans that we read early in ns-slapd startup * environment variables (these can be passed from systemd units or lib389) * command line switches (passed in lib389 or systemd args) For example, there is a really substantial patch for NS that's been outstanding since march, slapi v4 that has been there since late last year. If we can apply them but "disable", it means we can test and get confidence, the code is not "rotting". I think it's a nice balance between "innovate and change" and "conservative changes and confidence in releases". What do we think? -- Sincerely, William _______________________________________________ 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
