Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature gating design and integration #3052

Open
389-ds-bot opened this issue Sep 13, 2020 · 5 comments
Open

Feature gating design and integration #3052

389-ds-bot opened this issue Sep 13, 2020 · 5 comments
Milestone

Comments

@389-ds-bot
Copy link

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/49993


Issue Description

We have had a number of features land that have caused some challenges, and needed to be reverted. We should improve the process of development, review, test, enable and rollback. To achieve this we should have a feature gating mechanism, similar to how we managed enable-disable-nunc-stans. It's been done in the past, but designing and having a dedicated feature for this will allow us to develop and commit sooner, allows QE to test, and allows us to develop stronger developer confidence in changes, and control, delay releases, and to ship "quick reverts" if required to users and admins.

@389-ds-bot 389-ds-bot added this to the 1.4.4 milestone Sep 13, 2020
@389-ds-bot
Copy link
Author

Comment from tbordaz (@tbordaz) at 2018-10-25 09:31:33

Reading the description I see two proposals but may be there are more. First is a process improvement (design, review, dev, push, test, doc). The second is a mechanism to control when/how the implemented feature will be used. Are there others proposals ?
I have the feeling that the result of this ticket could be a process document but not code change, am I wrong ?

@389-ds-bot
Copy link
Author

Comment from tbordaz (@tbordaz) at 2018-10-25 09:31:34

Metadata Update from @tbordaz:

  • Custom field component adjusted to None
  • Custom field origin adjusted to None
  • Custom field reviewstatus adjusted to None
  • Custom field type adjusted to None
  • Custom field version adjusted to None

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2018-10-26 04:00:11

Yes, this is both a process change, but in order to support the process, we need a way to technically gate the changes. I don't thing cn=config is a good idea because the change may be for cn=config. So I think we could have an alternate mechanism, read early in main() that defines the set of server features to turn on/off.

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2019-02-07 17:48:47

Metadata Update from @mreynolds389:

  • Issue set to the milestone: 1.4.1

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2020-02-26 17:02:25

Metadata Update from @mreynolds389:

  • Issue priority set to: normal
  • Issue set to the milestone: 1.4.4 (was: 1.4.1)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant