URL:
https://github.com/SSSD/sssd/pull/531
Title: #531: Add the needed machinery to have automated builds for our COPR repos
fidencio commented:
"""
The COPR repos should be at least usable and currently the git HEAD
of our branches might or might not be usable in some aspects -- for example AD provider or
IPA provider are not tested at all upstream. The integration tests we have test only a
small subset of the functionality and for a lot of functionality we rely on greentea
tests. Prior to the release of 1.16.1 there was quite a few bugs (3594 for example, I
remember that one because I was working on it) which were only revealed by the greentea
tests.
Until we have commit gating with all the available tests, we can't
be sure that everything works. And we only do a release at the point where our downstream
tests are also passing. After that, we tag the release and the release is the sssd
upstream saying "this bundle of commits is known to work well together".
Okay, I agree with that for branches that are not the master one.
I don't think there is any harm in having
"sssd-1-13-rolling" branch and "sssd-1-16-rolling" in addition to
building the releases in COPR, but I don't think having the git HEAD as the default
without warning is a good idea until we drastically improve our coverage.
Okay, here I can see I had a wrong perception of the COPR usage for SSSD team. My
understanding was that sssd-1-13 COPR was **exactly** what you're suggesting by
"sssd-1-13-rolling" and then if someone wants something more stable they would
go for the release.
Having sssd-1-13, sssd-1-13-rolling, sssd-1-13 release ... It does sound like a quite big
overkill IMHO.
So, summing up ... I'm fine about enabling this for **master** only and then I'm
open to discuss some idea to automate the way 1.16 and 1.13 would be generated.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/531#issuecomment-372714239