#49363 Merge lib389 into the 389-ds-base source tree
Closed: wontfix 2 years ago by mreynolds. Opened 4 years ago by 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 @spichugi 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 @mreynolds @tbordaz and @lkrispen 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).


Metadata Update from @firstyear:
- Issue assigned to firstyear

4 years ago

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?

Metadata Update from @mreynolds:
- 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

4 years ago

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. :)

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.

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 @mreynolds as he is the master of rpm specs at this time,

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.

We don't (at least I don't, I can't speak for @mreynolds, @tbordaz or @lkrispen ) 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 :)

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to review (was: None)

4 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to ack (was: review)

4 years ago

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

@mreynolds 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.

Metadata Update from @firstyear:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

4 years ago

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.3.7.0
- Issue status updated to: Open (was: Closed)

4 years ago

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

2 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2422

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

2 years ago

Login to comment on this ticket.

Metadata
Attachments 1