On (06/08/14 21:00), Nikolai Kondrashov wrote:
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.
totally
agree.
>
>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.
I have already created ding-libs repo
https://copr.fedoraproject.org/coprs/lslebodn/ding-libs/
It is available for all necessary platforms: epel-{5,6,7} and fedora-{19,20}
fedora >= 21 has already new version of ding-libs.
LS