On 08/06/2014 08:37 PM, Jakub Hrozek wrote:
On Tue, Aug 05, 2014 at 05:59:39PM +0300, Nikolai Kondrashov wrote:
> On 08/05/2014 04:31 PM, Lukas Slebodnik wrote:
>> The main purpose of CI should be to test new features, primary on fedora and
>> rhel/centos. In last version of SSSD, we enhanced integration with AD and this
>> last patch will disable this provider on el6 and el7. It is step back.
>>
>> I test sssd from master branch with modified version of epel-6-x86_64.cfg and
>> epel-7-x86_64.cfg. They contain extra repositories with ding-libs-0.4.
>
> This patch was the result of an IRC discussion I had with Jakub, where we
> basically concluded that maintaining packages for *all* the dependencies
> currently and potentially necessary to enable all the (newest) features on at
> least some currently released distros (my idea originally) would be too much
> of a burden (especially considering Samba and Kerberos), and we can limit
> testing new features to the baseline of Fedora Rawhide (for which purpose I
> brought up a new Jenkins node).
>
> However, if we limit these only to (some) packages we "control" and know
how
> to build properly for corresponding distros, then perhaps it will be
> manageable. Lukas, am I right that you already maintain a set of repos for
> ding-libs? We can still disable features which require other packages.
>
> Still, if we are to use that in CI, we'll have to fully commit to the
> maintenance of a repository holding these packages and will have to make it
> official: mention it in the developer instructions along with supported
> distros.
>
> Then, if we would like to use this repo to enable new features not only for
> mock builds, but for the native CI builds as well (benefiting test coverage,
> valgrind, clang scanner, etc. on older distros), we'll have to add
> instructions to add this repo to yum configuration, so CI could install the
> newer packages.
>
> It would also be nice to have a similar repo for Debian testing.
>
> (BTW, regardles of the above, we might need to add something like a --no-deps
> option to the CI script for those wishing to install/use dependencies in other
> ways, say from source)
>
> So, would having the newer features depending only on (some) packages
> "controlled" by us be tested on some currently released distros worth the
> extra effort partially described above? How many of features being added
> depend only on "our" packages, usually?
>
> Jakub, what do you think?
I'm fine with creating a repo with *ding-libs*, because it's a small
package, developed by us and understood by us. So in this particular case
of ding-libs, I'm fine with us putting the package into the buildroot or
some special repo. But ding-libs is a special case.
What I don't like is us maintaining a repo with large packages like
Samba or Krb5 if/when we depend on new features in these packages. That
would be too much of a burden. If we rely on a feature that depends on
the latest Kerberos or Samba, my opinion is that we should make it easy
to disable the functionality and run CI only for the supported subset of all
features and run the full subset on rawhide or F-<latest> maybe.
This is no different from a user grabbing a tarball of latest SSSD and
compiling it on Debian or Centos 6 maybe. They're not going to get all
the features either, fine by me. The important thing for me is that
a) existing functionality doesn't regress on any platform
b) all functionality is tested on at least one platform
I really don't think we have the time to maintain all the missing deps
for all the packages we depend on and all the platforms we test.
Thanks, Jakub.
Lukas, would you be willing to maintain such a repository and to make it
official, accepting public reliance on it?
I'd say that it might be better to give it a more abstract name, not including
"ding-libs", or a person's user name, giving us more flexibility in the
future.
Nick