[Freeipa-devel] FreeIPA Copr repo plan

[Martin Kosek]

Hi guys,

Some time ago we started managing FreeIPA Copr repos (mkosek/freeipa) with a
target to have the latest greatest FreeIPA available for older arches (read -
RHEL/CentOS) and to allow people using older stable Fedoras (read - Fedora 20)
try FreeIPA 4.0+ releases which brought in several dependencies.

So far this was a more ad hoc approach, I think a more firm plan and tools are
due. I see several questions that needs to be decided:

1) What Copr repos do we want to maintain and what should be the expectations?
My take:

a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+,
EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, right?
Does it fit your needs?

b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest and
greatest release, would it make sense to have a Copr repo with *releases* per
supported branch to give users a choice? I.e.
* mkosek/freeipa-4.1
* mkosek/freeipa-4.0
These repos are there already, but not used consistently. I do not think we
should build all the dependency chain (too much overhead) for older systems
(F20/EPEL). But I assume we could at least build the freeipa SRPM itself for
these systems if it uses "mkosek/freeipa" as additional build root in Copr.

c) Daily repos
Should we deprecate old John's repos
(http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is difficult to
maintain and replace them with Copr ones? I.e. to have common repo (e.g.
mkosek/freeipa-daily) built for the supported Fedoras (F20, F21, rawhide ATM)
including dependencies?

Should it contain daily master builds for all tracked projects (FreeIPA, SSSD,
389 DS, bind-dyndb-ldap)? Or do we simply want to let distribute it across
projects "mkosek/freeipa-master", "someone/sssd-master",
"someone/389-ds-base-master? Second option may scale better better, the list of
such repos may be maintained somewhere (freeipa.org wiki).


2) We will need to have some tool chain and Jenkins CI jobs watching these
repos to make sure the build & run deps are OK. So far I used the attached 2
clumsy bash scripts to handle the repos build and one for analysis. But we will
need something better.


3) Scalability of the approach
Some dependencies are more difficult to maintain than the others. Especially
the PKI ones often required custom Java packaging (resteasy-base) or a
complicated dependency chain (the latest jackson-jaxrs-json-provider). It would
be great if PKI team helps with this effort, as Lukas proposed. Downside is
that mkosek/freeipa installation would require 2 Copr repos. But maybe we could
have a job syncing the PKI build/runtime dependencies directly to FreeIPA copr.
Whatever works and scale.

-- 
Martin Kosek <mkosek at redhat.com>
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build-srpms.sh
Type: application/x-sh
Size: 443 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20141110/af6a5d4e/attachment.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check-status.py
Type: text/x-python
Size: 3069 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20141110/af6a5d4e/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: prep-srpms.sh
Type: application/x-sh
Size: 1998 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20141110/af6a5d4e/attachment-0001.sh>