October 2018 - 389-devel - Fedora Mailing-Lists

389 DS nightly 2018-10-16 - 85% PASS

by vashirov＠redhat.com

https://fedorapeople.org/groups/389ds/ci/nightly/2018/10/16/report-389-ds...

5 years, 6 months

1
0
0 / 0

389 DS nightly 2018-10-15 - 91% PASS

by vashirov＠redhat.com

https://fedorapeople.org/groups/389ds/ci/nightly/2018/10/15/report-389-ds...

5 years, 6 months

1
0
0 / 0

Please review: 49975 rpmlint

by William Brown

https://pagure.io/389-ds-base/issue/49975 https://pagure.io/389-ds-base/pull-request/49977 -- Sincerely, William

5 years, 6 months

1
0
0 / 0

please review: Ticket 49926 - Add replication functionality to UI

by Mark Reynolds

https://pagure.io/389-ds-base/pull-request/49976

5 years, 6 months

1
0
0 / 0

389 DS nightly 2018-10-13 - 91% PASS

by vashirov＠redhat.com

https://fedorapeople.org/groups/389ds/ci/nightly/2018/10/13/report-389-ds...

5 years, 6 months

1
0
0 / 0

389 DS nightly 2018-10-12 - 92% PASS

by vashirov＠redhat.com

https://fedorapeople.org/groups/389ds/ci/nightly/2018/10/12/report-389-ds...

5 years, 6 months

1
0
0 / 0

please review: PR 49952 - PassSync not setting pwdLastSet attribute in Active Directory after Pw update from LDAP sync for normal user

by Mark Reynolds

https://pagure.io/389-ds-base/pull-request/49952

5 years, 6 months

1
1
0 / 0

389 DS nightly 2018-10-10 - 91% PASS

by vashirov＠redhat.com

https://fedorapeople.org/groups/389ds/ci/nightly/2018/10/10/report-389-ds...

5 years, 6 months

1
0
0 / 0

Feature gating discussion

by William Brown

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

5 years, 6 months

1
0
0 / 0

Please review: Issue 49928 - Fix various small WebUI schema issues

by Simon Pichugin

Hi team, please, review the WebUI schema change. Also, I wait for this to be merged https://github.com/python-ldap/python-ldap/pull/247 but my PR will work as intended without it, I put a small workaround which we will remove later. https://pagure.io/389-ds-base/pull-request/49966 https://pagure.io/389-ds-base/issue/49928 Thanks, Simon

5 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel October 2018