Hello,
Would it be possible to moved to a timed release schedule? Looking at the ChangeLog, the current release 'schedule' seems to be a bit... non-deterministic:
http://www.openldap.org/software/release/changes.html
Moving towards a fixed-date schedule (once or twice a year?) would allow downstream maintainers to update things like Linux distributions in a more predictable fashion. The "maintenance releases" would be nothing more than tagging all of the patches since the last release and creating a tarball.
If there are zero patches since the last releases, then a new tarball may not be needed (or a "NOP release" could be done just to keep people in-practice). Otherwise, regardless of whether is is one or one-dozen patches, a new version is revved.
If there is a security issue, a release could be issued outside of the fixed schedule. Ideally (IMHO) security releases would only include the security fix so people can be confident that it is a low-risk change that won't change / break other behaviours.
Given that most users of OpenLDAP "consume" it via their distribution-of-choice's package, this would (IMHO) increase the chances of more recent versions of OpenLDAP being used (especially in Debian and Ubuntu, but also Fedora). Recent Debian releases occur in Q2, and Ubuntu does April/October (LTSes are April), while Fedora (roughly) does May/November. Perhaps a February/September cycle?
Not sure whether this is something for 2.4, or for 2.5 when it comes out.
Any thoughts?
Regards, David
Hi!
I think the question is not whether a time-based release schedule or a feature-based release schedule is better; instead the question is "when will a release be considered ready?"
Regards, Ulrich
"David Magda" dmagda@ee.ryerson.ca schrieb am 03.07.2018 um 15:52 in
Nachricht ebb6857e3819d931930b3824966a86e5.squirrel@webmail.ee.ryerson.ca:
Hello,
Would it be possible to moved to a timed release schedule? Looking at the ChangeLog, the current release 'schedule' seems to be a bit... non-deterministic:
http://www.openldap.org/software/release/changes.htmlMoving towards a fixed-date schedule (once or twice a year?) would allow downstream maintainers to update things like Linux distributions in a more predictable fashion. The "maintenance releases" would be nothing more than tagging all of the patches since the last release and creating a tarball.
If there are zero patches since the last releases, then a new tarball may not be needed (or a "NOP release" could be done just to keep people in-practice). Otherwise, regardless of whether is is one or one-dozen patches, a new version is revved.
If there is a security issue, a release could be issued outside of the fixed schedule. Ideally (IMHO) security releases would only include the security fix so people can be confident that it is a low-risk change that won't change / break other behaviours.
Given that most users of OpenLDAP "consume" it via their distribution-of-choice's package, this would (IMHO) increase the chances of more recent versions of OpenLDAP being used (especially in Debian and Ubuntu, but also Fedora). Recent Debian releases occur in Q2, and Ubuntu does April/October (LTSes are April), while Fedora (roughly) does May/November. Perhaps a February/September cycle?
Not sure whether this is something for 2.4, or for 2.5 when it comes out.
Any thoughts?
Regards, David
On Tue, Jul 03, 2018 at 09:52:37AM -0400, David Magda wrote:
Given that most users of OpenLDAP "consume" it via their distribution-of-choice's package, this would (IMHO) increase the chances of more recent versions of OpenLDAP being used (especially in Debian and Ubuntu, but also Fedora). Recent Debian releases occur in Q2, and Ubuntu does April/October (LTSes are April), while Fedora (roughly) does May/November.
In the case of Debian and Ubuntu at least, what's relevant is the freeze date, not the actual release. For Debian 9 (Stretch) that was 2017-02-05, for Debian 10 (Buster) it is planned for 2019-03-12. For Ubuntu the relevant date is the "Debian Import Freeze" on their release calendar.
As always, if there are specific bugs in an OpenLDAP release that affect your use of it on these distros, please open a bug report in the distro tracker so we can have a conversation about backporting the patches.
Ryan Tandy wrote:
On Tue, Jul 03, 2018 at 09:52:37AM -0400, David Magda wrote:
Given that most users of OpenLDAP "consume" it via their distribution-of-choice's package, this would (IMHO) increase the chances of more recent versions of OpenLDAP being used (especially in Debian and Ubuntu, but also Fedora). Recent Debian releases occur in Q2, and Ubuntu does April/October (LTSes are April), while Fedora (roughly) does May/November.
In the case of Debian and Ubuntu at least, what's relevant is the freeze date, not the actual release. For Debian 9 (Stretch) that was 2017-02-05, for Debian 10 (Buster) it is planned for 2019-03-12. For Ubuntu the relevant date is the "Debian Import Freeze" on their release calendar.
Sounds like we'd be looking at a release date in January then. Maybe a bit awkward, first thing after the new year holiday.
On Tue, July 3, 2018 11:48, Howard Chu wrote:
Ryan Tandy wrote:
On Tue, Jul 03, 2018 at 09:52:37AM -0400, David Magda wrote:
Given that most users of OpenLDAP "consume" it via their distribution-of-choice's package, this would (IMHO) increase the chances of more recent versions of OpenLDAP being used (especially in Debian and Ubuntu, but also Fedora). Recent Debian releases occur in Q2, and Ubuntu does April/October (LTSes are April), while Fedora (roughly) does May/November.
In the case of Debian and Ubuntu at least, what's relevant is the
freeze date,
not the actual release. For Debian 9 (Stretch) that was 2017-02-05, for
Debian
10 (Buster) it is planned for 2019-03-12. For Ubuntu the relevant date
is the
"Debian Import Freeze" on their release calendar.
Sounds like we'd be looking at a release date in January then. Maybe a bit awkward, first thing after the new year holiday.
It does not /have/ to be related to downstream distros. I mentioned the distros in my original message as a suggestion, and not as a hard requirement.
If OpenLDAP has a biannual cycle, then the "out-of-date" release would only be at most six months old. Compare that between 2.4.46 to 2.4.45 (>9 months) to 2.4.44 (16 months).
Ubuntu's Debian Import Freeze is usually the first week of March and September, so February/September would be okay for that. Debian package maintainers can ask for uploads to be "unblocked" on a case-by-case basis. But a six-month-old point-release is certainly better than have year-old code in the distros (which then can live on for >2 years.)
Taking out external factors from consideration, are there any internal OpenLDAP concerns about doing a calendar-based maintenance release cycle? (Major version and security releases would not be included in this.)
-- David Magda
On 07/03/2018 08:07 PM, David Magda wrote:
It does not /have/ to be related to downstream distros. I mentioned the distros in my original message as a suggestion, and not as a hard requirement.
Then I fail to understand why you want that.
If OpenLDAP has a biannual cycle, then the "out-of-date" release would only be at most six months old. Compare that between 2.4.46 to 2.4.45 (>9 months) to 2.4.44 (16 months).
Even then there's no guarantee that downstream maintainers really pick up the latest version at that time. No problem solved at all. And bear in mind that there are way more downstream maintainers out there all with their own release schedule.
Besides that Debian distribution or similar are way too slow anway.
Personally I'd prefer OpenLDAP project to return to the old release-early-release-often mantra. And hey, that matches today's *agile* CI/CD models pretty well. ;-)
Ciao, Michael.
On Tue, July 3, 2018 14:24, Michael Ströder wrote:
On 07/03/2018 08:07 PM, David Magda wrote:
It does not /have/ to be related to downstream distros. I mentioned the distros in my original message as a suggestion, and not as a hard requirement.
Then I fail to understand why you want that.
Perfect is the enemy of good. I think it's better to get the ball rolling on regular releases than doing a bikeshed on the exact timing.
I do not know what's involved in the release process, or how onerous it is, so will let the actual people that are going to do the work make that call.
If OpenLDAP has a biannual cycle, then the "out-of-date" release would only be at most six months old. Compare that between 2.4.46 to 2.4.45 (>9 months) to 2.4.44 (16 months).
Even then there's no guarantee that downstream maintainers really pick up the latest version at that time. No problem solved at all. And bear in mind that there are way more downstream maintainers out there all with their own release schedule.
Besides that Debian distribution or similar are way too slow anway.
Some of us don't have the time to pull down the latest git commit and roll our own release of OpenLDAP. If you need something more recent than what Debian offers that's something you can address yourself, but I would hazard to guess that the majority of people running OpenLDAP are using a RPM/DEB/etc.
Personally I'd prefer OpenLDAP project to return to the old release-early-release-often mantra. And hey, that matches today's *agile* CI/CD models pretty well. ;-)
If you want to argue for monthly or quarterly releases, I won't object. I also won't object to starting with annual releases. I just think there is something better than sleep(rand()).
-- David Magda
On Tue, July 3, 2018 10:04, Ulrich Windl wrote:
"David Magda" dmagda@ee.ryerson.ca schrieb am 03.07.2018 um 15:52 in Nachricht ebb6857e3819d931930b3824966a86e5.squirrel@webmail.ee.ryerson.ca:
Hello,
Would it be possible to moved to a timed release schedule? Looking at the ChangeLog, the current release 'schedule' seems to be a bit... non-deterministic:
http://www.openldap.org/software/release/changes.html[...]
Hi!
I think the question is not whether a time-based release schedule or a feature-based release schedule is better; instead the question is "when will a release be considered ready?"
How would that be determined? Presumably 2.4 should mostly be bug and security fixes now, with hopefully minimal regressions when patches are applied. (Which is why I mentioned security releases should perhaps (ideally) only contain the fix for the issue, and no other patches: minimize risk so people few safe using with few other side effects.)
If there is regression testing and such before a release is tagged / cut, than that would obviously have to be considered in the timelines. But if everyone knows that on Week X of Month Y the goal is to release something, people can plan ahead a bit versus trying to "find time" to do a release. Also, if releases start happening regularly, than there may be some motivation to look into some automation (per Michael Ströder's CI/CD suggestion).
I do not know what's involved in the release process, or how onerous it is, so will let the actual people that are going to do the work make that call. I am simply bringing up the idea (which may be a bad one of course :).
-- David Magda
On 07/03/2018 08:44 PM, David Magda wrote:
Some of us don't have the time to pull down the latest git commit and roll our own release of OpenLDAP. If you need something more recent than what Debian offers that's something you can address yourself, but I would hazard to guess that the majority of people running OpenLDAP are using a RPM/DEB/etc.
Regarding mainstream Linux: - On Debian and RHEL/CentOS I'd recommend to use the LTB packages anyway which are always compiled from latest release. - For openSUSE I keep the packages updated. Personally I'm using openSUSE Tumbleweed which is a rolling release with decent QA staging.
Personally I'd prefer OpenLDAP project to return to the old release-early-release-often mantra. And hey, that matches today's *agile* CI/CD models pretty well. ;-)
If you want to argue for monthly or quarterly releases, I won't object.
I want to argue to release 2.4.47 now ;-) so I can get rid of back-port patches for needed features - just because I really hate back-port patches.
Ciao, Michael.
openldap-technical@openldap.org
-
David Magda -
Howard Chu -
Michael Ströder -
Ryan Tandy -
Ulrich Windl