URL: https://github.com/SSSD/sssd/pull/531
Title: #531: Add the needed machinery to have automated builds for our COPR 

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 

See the full comment at 
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

Reply via email to