[Freeipa-devel] FreeIPA Copr repo plan

[thierry bordaz]

On 11/10/2014 04:26 PM, Martin Kosek wrote:
> 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.
DS is building the latest and greatest release in copr.
I am using this DS repo to test it against IPA 4.0.x  and IPA 4.1.x latests.
Currently I am building IPA latests (srpms+rpms) on my own copr repos, 
so with a risk of taking wrong dependencies.
I would prefer to have a global per supported branches copr repos, like 
mkosek/freeipa-4-0...

thanks
thierry


>
>>> 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
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20141110/ed1f11e5/attachment.htm>