[Freeipa-devel] FreeIPA Copr repo plan

[Martin Kosek]

On 11/10/2014 01:49 PM, Jakub Hrozek wrote:
> On Mon, Nov 10, 2014 at 12:07:46PM +0100, Martin Kosek wrote:
>> 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?
> 
> +1
> 
>>
>> 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.
> 
> Is it worth it? Is the older supported branch some kind of LTM or just
> happens to be alive because of some Fedora or RHEL release using it?
> 
> I think there is value in providing early access to RHEL/CentOS users
> prior to dumping the RPMs onto them, but maintaining the repos is hard,
> I think we should only commit to this work if there is a use-case.

In this particular case we wanted to have a repo to build FreeIPA 4.0.x given
that mkosek/freeipa repo already contained 4.1. The purpose was to provide
option to people who do not want to update to early 4.1.0 yet.

>> 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?
> 
> Is there a build script or other infrastructure that would make the new
> repo easy to maintain (easier than John's repo)? In general I think there
> is quite a bit of value in the daily builds -- we can ask users if their
> problem goes away with the latest builds and we could even use this for
> some CI setups and we know early if something breaks.

There seems to be a traction to use a single supported way of building RPMs and
not maintain 2 systems - see John Dennis' response.

>> 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).
> 
> I think I might be missing something, but why do you think separate
> repos are better?

My idea was to decentralize it - to not overload FreeIPA developers with
maintaining nightly devel builds and it's potentially new dependencies but to
let domain experts from different teams to maintain it.

Also, people interested in nightly builds may not be interested in nightly
builds for all these packages, but maybe just SSSD. So they would just download
SSSD yum repo and enable it.

But if there is a value in having a united repo with nightly builds of all
these packages, maybe there could simply be a cron script merging all the
distributed Copr repos RPMs and placing them on fedorapeople.

Martin