Merge lib389 into the 389-ds-base source tree

[389-ds-bot]

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

• Created at 2017-08-23 06:42:02 by firstyear (@Firstyear)
• Closed at 2019-08-23 20:05:39 as fixed
• Assigned to firstyear (@Firstyear)

---

Issue Description

The issue is that we have a split: we have tests in
389-ds-base/dirsrvtests that are often version dependent. They relate
to features of the server, or issues in specific versions of the server
that may not exist in older versions. Today we kind of stradle the line
of "it's a bit of both". We have tests in 389-ds-base that depend on
versions of lib389 - but lib389 moves quickly and has little ability to
distinguish 389-ds-base versions.

-- Merging lib389 to 389-ds-base

One proposal is to merge them. We would mix in lib389 and the
dirsrvtests into lib389 tests. It is often the case that lib389's
features are bound tightly to a version of directory server.

Pros:

• No need to separate version lib389 to ds. lib389 is guaranteed to work
  with that version of DS
• Testing DS is guaranteed to work. Right now we have rapid change in
  lib389 and the tests in say 1.3.5 or 1.2.11.x are unlikely to work with
  latest lib389.
• We can tightly tie in features of DS with lib389 and their
  administration (ie no need to worry about backward compatibility).
• Simpler release process - we only need to release 389-ds-base, and we
  are done.
• No more split patches for lib389 features and tests.

Cons:

• We will need to backport lib389 features to backport tests for fixes
  to older versions.
• Inability for latest lib389 to manage older (or newer) versions of ds.

At this time, this is supported by @droideck and @vashirov . @tbordaz Has commented on irc that the design of lib389 was always that we "could" merge in the future.

I'd love to see comments from @mreynolds389 @tbordaz and @elkris about this topic.

I would suggest during the merge, we can make lib389 a dependency of the 389-ds-base rpm too, and we can also ship our python2/3 libs quite easily with this change. This would really open the door to using the new ds* cli tools, and usage of lib389 by other projects (with a current disclaimer the api isn't yet stabilised).

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-08-23 06:42:11

Metadata Update from @Firstyear:

• Issue assigned to Firstyear

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2017-08-23 16:46:55

Cons:
We will need to backport lib389 features to backport tests for fixes
to older versions. Inability for latest lib389 to manage older (or newer) versions of ds.

We can still merge lib389 into older versions/branches of DS, then we can maintain it for all versions. it would make backporting easier.

How is this going to impact the python-lib389 package? Are we just going to make it a subpackage of 389-ds-base?

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2017-08-23 16:46:57

Metadata Update from @mreynolds389:

• 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]

Comment from firstyear (@Firstyear) at 2017-08-24 04:04:49

Yes, that's true. We could target 1.3.6 and 1.3.7 with this I expect, and then it will carry on with 1.4.x.

I would say we make it a subpackage of 389-ds-base, it would be the easiest approach. It gives us one source tree, and one rpm spec file, which seems like the easiest solution. :)

[389-ds-bot]

Comment from vashirov (@vashirov) at 2017-08-24 06:51:44

I think it's not worth to backport it to 1.3.6, because we won't be able to use it in downstream (we can't put it in z-stream). 1.3.7 is a better target.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-08-24 10:02:36

How will we run the tests on 1.3.6 then? We'll need two source copies of 389-ds-base then?

I think a better idea is merge it back to 1.3.6 as well, but have the specfile not build the python-lib389 parts for zstream- just introduce them with 1.3.7.

This way we still get the ability to test 1.3.6, but we don't add to parts to zstream. That would be up to @mreynolds389 as he is the master of rpm specs at this time,

[389-ds-bot]

Comment from vashirov (@vashirov) at 2017-08-24 10:35:42

How will we run the tests on 1.3.6 then? We'll need two source copies of 389-ds-base then?

It depends on your workflow. We use rpm installations and (versioned) tests from git master.

I think a better idea is merge it back to 1.3.6 as well, but have the specfile not build the python-lib389 parts for zstream- just introduce them with 1.3.7.

We can't land this in downstream 1.3.6. Only fixes are accepted at this moment. Even if it will be in upstream 1.3.6 branch, it's no use for us.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-08-24 11:21:40

We don't (at least I don't, I can't speak for @mreynolds389, @tbordaz or @elkris ) use rpms, we use the source tree.

We don't plan to land it in downstream 1.3.6, just upstream. I think it will make our lives a lot easier from the upstream view point, even if we don't push it to zstream. I know that it's fix only at the moment :)

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-10-11 17:27:01

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-10-11 17:27:02

Metadata Update from @Firstyear:

• Custom field reviewstatus adjusted to review (was: None)

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2017-10-11 17:33:28

Metadata Update from @mreynolds389:

• Custom field reviewstatus adjusted to ack (was: review)

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-10-12 08:46:30

commit 9dccfea
To ssh://git@pagure.io/389-ds-base.git
22e54fa..9dccfea master -> master

commit 0658297
To ssh://git@pagure.io/389-ds-base.git
964bf65..0658297 389-ds-base-1.3.7 -> 389-ds-base-1.3.7

@mreynolds389 The master commit and push has the full history, but 1.3.7 is a single squashed patch. The result isn the code is the same and patches will apply on top of both correctly, but it allows you to more easily extract the single 1.3.7 patch for downstream spec files as needed.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-10-12 17:26:53

Metadata Update from @Firstyear:

• Issue close_status updated to: fixed
• Issue status updated to: Closed (was: Open)

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2017-10-12 17:27:54

Metadata Update from @mreynolds389:

• Issue set to the milestone: 1.3.7.0
• Issue status updated to: Open (was: Closed)

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-08-23 20:05:40

Metadata Update from @mreynolds389:

• Issue close_status updated to: fixed
• Issue status updated to: Closed (was: Open)