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
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
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,
It depends on your workflow. We use rpm installations and (versioned) tests from git master.
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 :)
<img alt="0001-Ticket-49363-Merge-lib389.patch" src="/389-ds-base/issue/raw/files/85897f15e4523511c5a01cf20f10dcf05882beaed804ffe666e4e16e28c7d8b3-0001-Ticket-49363-Merge-lib389.patch" />
Metadata Update from @firstyear: - Custom field reviewstatus adjusted to review (was: None)
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to ack (was: review)
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)
Metadata Update from @mreynolds: - Issue set to the milestone: 1.3.7.0 - Issue status updated to: Open (was: Closed)
Metadata Update from @mreynolds: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.