Title: #531: Add the needed machinery to have automated builds for our COPR
> 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
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
See the full comment at
sssd-devel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org