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