1:58 a.m.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Mdtdq0OpWWeWKSHMEaaBTtuR5rUPjTbeD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El mi=C3=A9 15 ene 2014 19:04:04 CET, Alon Bar-Lev escribi=C3=B3:
----- Original Message -----
> From: "David Caro" <dcaroest(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, "infra"
<infra(a)ovirt.org=
, "Kiril Nesenko" <kiril(a)redhat.com>
> Sent: Wednesday, January 15, 2014 5:47:59 PM
> Subject: Re: release repo structure and 3.3.2
>
> El mi=C3=A9 15 ene 2014 16:30:00 CET, Alon Bar-Lev escribi=C3=B3:
>>
>>
>> ----- Original Message -----
>>> From: "David Caro" <dcaroest(a)redhat.com>
>>> To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, "Alon
Bar-Lev"
>>> <alonbl(a)redhat.com>, "infra" <infra(a)ovirt.org>
>>> Cc: "Kiril Nesenko" <kiril(a)redhat.com>
>>> Sent: Wednesday, January 15, 2014 5:26:32 PM
>>> Subject: Re: release repo structure and 3.3.2
>>>
>>> El 07/01/14 15:31, Sandro Bonazzola escribi=C3=B3:
>>>> Il 01/01/2014 10:42, Alon Bar-Lev ha scritto:
>>>>> Hi,
>>>>>
>>>>> For some reason there 3.3.2 z-stream was released in its own repos=
itory
>>>>> so
>>>>> people that are subscribed to stable[1] did not get it.
>>>>
>>>> Why not?
>>>> stable release had ovirt-release-10 which enabled both stable and 3=
=2E3.2
>>>> repository by yum updating it.
>>>>
>>>>>
>>>>> There is no much sense in releasing fix release that people do not=
get
>>>>> in
>>>>> simple "yum update".
>>>>>
>>>>> Also the following is now broken of most packages' spec:
>>>>> Source0:
>>>>> http://ovirt.org/releases/stable/src/@PACKAGE_NAME@-@PACKAGE_VERSI=
ON@.tar.gz
>>>>>
>>>>> For each minor we should have rolling repository, to reduce noise =
and
>>>>> provide service.
>>>>>
>>>>> All released tarballs (sources) should be stored at fixed location=
to
>>>>> allow distro specific code to fetch, the location
must be synced w=
ith
>>>>> what we publish.
>>>>>
>>>>> Immediate action is to move the 3.3.2 content into the stable dire=
ctory.
>>>>
>>>> So previous request of having each release in its own repository ha=
s been
>>>> retired?
>>>> Or is it combined?
>>>> Do we want stable to be a rolling repository and have also a reposi=
tory
>>>> for
>>>> each version?
>>>> I'm not against having rolling packages in just one stable reposito=
ry, I
>>>> just want to understand what is the desired structure
of the
>>>> repositories.
>>>
>>> I am, having a stable repository with rolling rpms is a lot more har=
d
to
>>> manage
>>> and maintain than having separated individual complete repos.
>>>
>>> Because what we are actually delivering is not a specific rpm, but t=
he
>>> whole
>>> set, that is, one repository with the set of rpms that were tested
>>> together
>>> and
>>> validated. If at any point you want to mix them, you still can addin=
g
the
>>> other
>>> repos.
>>>
>>> For updates just updating the directory where the 'stable' link poin=
ts
>>> gets
>>> it done.
>>>
>>> For rollbacks you'll have to configure the old repo. That is not as
>>> annoying
>>> as
>>> it might seem, because when you enable the stable repo, you want to =
have
>>> the
>>> stable version, that changes with time. If you want to rollback to a=
>>> previous
>>> version then just use that versions specific repo. At much we can pr=
ovide
>>> a
>>> link
>>> like 'previous_stable' so if you want to rollback to the previous ve=
rsion
>>> you
>>> can use --enablerepo=3Dprevious_version easily, but if you want to k=
eep
>>> using
>>> that, you should point directly to the specific version you want tot=
use.
>>>
>>> Creating a new repository using is almost as cheap (on hard disk spa=
ce) as
>>> having a rolling repository, if you use hard links, so we
can create=
lot's
>>> of
>>> them, specially for small changes from one to another.
>>>
>>> The only drawback that I see is when you have to release a minor cha=
nge in
>>> one
>>> the the rpms, for example, to fix a critical bug, the repo will not
>>> include
>>> the
>>> old package, but I'm not sure if that's really a drawback... if you =
really
>>> need
>>> that package without the critical fix (you should not) you can have =
it
>>> changing
>>> to that specific repository. The internal naming of the repos does n=
ot
>>> really
>>> matter, having to point to the repo 3.3.3-beta.2 to get the second
>>> 'respin'
>>> of
>>> the 3.3.3 beta repo is not a big issue I think.
>>>
>>> The advantages are many, the most importants I see:
>>> - Easy management:
>>> * no need to go version hunting in the repo to remove/add rpms
>>> * you should never get a repo with version combinations that are =
not
>>> tested
>>> * it's a lot easier to get rid of old repos, and to move them aro=
und as
>>> they
>>> are independent
>>> * no broken links, right now stable repo is full of links to othe=
r
>>> repos,
>>> so
>>> removing those repos leave the links broken, you have to go che=
cking
>>> if
>>> someone links to them (or their internal directories) if you ha=
ve to
>>> clean
>>> up old versions
>>> - Testing, it's a lot easier to reproduce any error found, as you c=
an
>>> just use the same repo and you'll get the same
version set.
>>>
>>> What do you think?
>>
>
>> And you do not allow quick fix of issues found in various of packages=
=2E
> Why not? You can create a new repo based in the previous one
that
> includes the fixed packages. It's cheap!
who is you?
In this case you is the person/process/chimpanzee that is in charge
of=20
publishing the fixed packages to the correct environment
how do I push fix to users for z-stream of packages as otopi,
ovirt-hos=
t-deploy, log collector and such?
Exactly the same way you do it for engine or vdsm
why is these components' release cycle should be at same schedule
of ov=
irt-engine which is heavy and slow?
It should not.
>>
>> Although there is /some/ sense in syncing minor releases, I do not se=
e
any
>> reason of syncing z-stream.
>>
>
>> I think that you do not trust individual maintainer to provide z-stre=
ams.
>>
>> A change in z-stream should not be exposed (unless is fixing) an exte=
rnal
>> interface.
>
> I don't think it should be hidden neither, just make clear that those
> are not builds to be used widely, maybe just putting it under another
> directory (not releases). Where only promoted repos can go (meaning,
> not everyone can put repos there).
> For example:
> repos/releases -> for repos that have been tested and we want to publi=
sh
> repos/testing -> for any temporary generated repo, that is not
fully
> tested and not ready for be used widely
>
why not released? only because engine is slow? I do not understand.
I don't
even understand your question. We got lost at some point. I'll=20
try to explain a little more what I said before, maybe that will=20
clarify the issue to you.
You said that a change in z-stream should not be exposed, for that I=20
understand for that that a package that is meant to go to a z-stream=20
should not be exposed to the general public. I think that it should,=20
but it must be clear to the public that it's not yet ready (I suppose=20
that's the reason you don't want it public), so they use it at their=20
own risk. And separating the repos into two seems a good wat for making=20
that clear (another one is adding a suffix to the repo name for=20
example).
> That way you make sure that if anyone is using a repo that is not full=
y
> tested, is because he wants to, but you don't forbid it.
why do you think that someone is releasing untested packages?
I do not think that
someone is releasing untested packages. That=20
sentence comes from the hypothetical situation where a repository that=20
is not meant to be used by the general public (I said untested, but it=20
could be for any other reason) is made public using a different url=20
than the repos that are meant to be widely used.
Part of the advantages of that system is the ease to run tests on=20
specific version sets (repos). That we do not do right now (at least=20
*upstream*) but I think would be done in the near future.
>>
>> Alon
>>
>>>
>>>>
>>>>> Regards,
>>>>> Alon Bar-Lev.
>>>>>
>>>>> [1] http://resources.ovirt.org/releases/stable/
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> David Caro
>>>
>>> Red Hat S.L.
>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>>>
>>> Email: dcaro(a)redhat.com
>>> Web: www.redhat.com
>>> RHT Global #: 82-62605
>>>
>>>
>
>
>
> --
> David Caro
>
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>
> Email: dcaro(a)redhat.com
> Web: www.redhat.com
> RHT Global #: 82-62605
>
>
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Email: dcaro(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
--Mdtdq0OpWWeWKSHMEaaBTtuR5rUPjTbeD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJS1yCQAAoJEEBxx+HSYmnDm50H/ig7nM9EidzwOWrcPmWW1907
26fZUjcy17uLa8dnbnaDZSNeL4EzLgLnJz8ftovSIFQ2MKzB6D2M5EgFHU7DNltm
Jk0p/DM8JTgEb5lAPKrBbzlPx3eF8Dfodmyi8laaaClm+i7D4cZaM6qNxKXrncTW
K562ymN7YBn13r+/9tQVoGeLl93itnJ813ez9MvCrPOCvMTITs+idOwfOniVcjrl
3050hBChkwbZ3o7XM1ZgO3hiPOYf5GqdXDa3+EZ6G5hXiTELuIrmAPbQWcFlcSIg
mP1z4Ygz76k7C320jjXg2dv45Y4Yar/f3yVoBj/26nfC3hanf060VJwLCFX5+Jg=
=xowh
-----END PGP SIGNATURE-----
--Mdtdq0OpWWeWKSHMEaaBTtuR5rUPjTbeD--