URL:
https://github.com/SSSD/sssd/pull/139
Title: #139: Initial revision of sssd pytest framework
jhrozek commented:
"""
On Thu, Feb 02, 2017 at 12:48:11PM -0800, lslebodn wrote:
On (02/02/17 08:33), Jakub Hrozek wrote:
>On Thu, Feb 02, 2017 at 08:29:15AM -0800, lslebodn wrote:
>> On (02/02/17 08:14), Jakub Hrozek wrote:
>> >On Tue, Jan 31, 2017 at 12:18:44AM -0800, fidencio wrote:
>> >> Looking at the patches I see this can be a completely new library
instead of being part of SSSD.
>> >> Knowing this it does make sense to have it as a submodule or even a
completely external library (but still under SSSD group).
>> >>
>> >> I'd like to know the opinion of the more experienced developers
about this.
>> >
>> >I also like the idea of a git submodule, because IIRC these tests are
>> >supposed to be used kind of separately by downstream.
>> >
>> May I know why git submodule is better?
>>
>> The idea is that all test will pass with upstream
>> so upstream distributions should use the version from tarball (+ patches)
>>
>> Or could you describe your use-case why git-submodule is better?
>
>I was under the impression that the tests should also be usable by
>downstream. The submodule would make it possible to git clone just the
>tests w/o the rest of sssd.
>
And how will you know which git hash from "submodule repo" should be used
for testing specific version of sssd in downstream ?
I already keep the rhel- branches in my tree, I was thinking we might
expose them on some internal git server and collaborate there.
This is the problem I am thinking about -- the tests might need patching
when we add some patch to the 'downstream git branch' or we might just
add a test for a bug we fix in the downstream branch.
On the other hand, the developers that mostly work on the tests (the
current QE team) might be adding test cases on their own.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/139#issuecomment-277193337