5:47 p.m.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--rH8JAPLilKLwTq03sJMa0XiwfrPV3vPb4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
El mi=C3=A9 15 ene 2014 16:30:00 CET, Alon Bar-Lev escribi=C3=B3:
> I am, having a stable
repository with rolling rpms is a lot more hard = to
> Creating a new repository using
is almost as cheap (on hard disk space= ) as
> A change in z-stream should not be exposed (unless is
fixing) an extern=
al interface.
I don't think it should be hidden neither, just make clear that those=20
are not builds to be used widely, maybe just putting it under another=20
directory (not releases). Where only promoted repos can go (meaning,=20
not everyone can put repos there).
For example:
repos/releases -> for repos that have been tested and we want to publish
repos/testing -> for any temporary generated repo, that is not fully=20
tested and not ready for be used widely
That way you make sure that if anyone is using a repo that is not fully=20
tested, is because he wants to, but you don't forbid it.
> 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
--rH8JAPLilKLwTq03sJMa0XiwfrPV3vPb4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
----- Original Message -----
> From: "David Caro" <dcaroest(a)redhat.com > To:
"Sandro Bonazzola" <sbonazzo(a)redhat.com>, "Alon Bar-Lev"
<alonbl@r=
edhat.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 reposit=
ory 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.3=
=2E2
>> repository by yum updating it.
> >>
>>> There is no much sense in releasing fix release that people do not g=
et in
>>> simple "yum update".
>> >>> Also the following is
now broken of most packages' spec:
>>> Source0:
>>> http://ovirt.org/releases/stable/src/@PACKAGE_NAME@-@PACKAGE_VERSION=
@.tar.gz
>> >>> For each minor we
should have rolling repository, to reduce noise an=
d
>>> provide service.
>> >>> All released tarballs
(sources) should be stored at fixed location t=
o
>>> allow distro specific code to fetch, the location must be
synced wit=
h
>>> what we publish.
>> >>> Immediate action is to
move the 3.3.2 content into the stable direct=
ory.
> >> So previous request of
having each release in its own repository has =
been
>> retired?
>> Or is it combined?
>> Do we want stable to be a rolling repository and have also a reposito=
ry
for
>> each version?
>> I'm not against having rolling packages in just one stable repository=
, I
>> just want to understand what is the desired structure of the
reposito=
ries.
> manage
> and maintain than having separated individual complete repos.
> Because what we are actually delivering is not a specific
rpm, but the=
whole
> set, that is, one repository with the set of rpms that were
tested tog=
ether
> and
> validated. If at any point you want to mix them, you still can adding =
the
> other
> repos.
> For updates just updating the directory where the
'stable' link points=
gets
> it done.
> For rollbacks you'll have to configure the old repo.
That is not as an=
noying
> as
> it might seem, because when you enable the stable repo, you want to ha=
ve the
> stable version, that changes with time. If you want to rollback
to a p=
revious
> version then just use that versions specific repo. At much we can
prov=
ide a
> link
> like 'previous_stable' so if you want to rollback to the previous vers=
ion you
> can use --enablerepo=3Dprevious_version easily, but if you want
to kee=
p using
> that, you should point directly to the specific version you want
tot u=
se.
> having a rolling repository, if you use hard links, so we can
create l=
ot'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 chang=
e in
> one
> the the rpms, for example, to fix a critical bug, the repo will not in=
clude
> the
> old package, but I'm not sure if that's really a drawback... if you re=
ally
> 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 not=
really
> matter, having to point to the repo 3.3.3-beta.2 to get the
second 're=
spin'
> 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 no=
t
> tested
> * it's a lot easier to get rid of old repos, and to move them aroun=
d
as
> they
> are independent
> * no broken links, right now stable repo is full of links to other =
repos,
> so
> removing those repos leave the links broken, you have to go check=
ing if
> someone links to them (or their internal directories) if you
have=
to
> clean
> up old versions
> - Testing, it's a lot easier to reproduce any error found, as you can=
> 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.
Why not? You can create a new repo based in the previous one that=20
includes the fixed packages. It's cheap!
Although there is /some/ sense in syncing minor releases, I do not see =
any reason
of syncing z-stream.
I think that you do not trust individual maintainer to provide
z-stream=
s.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJS1q2vAAoJEEBxx+HSYmnD4bIH/3K4M9CtZY+dSBiB4F43UZIx
TvIvlhqY91A7lVzMDXrmASqJmDRMT4Wcuh317W69cp6EAN2g6SiZbGmMqDWIqU9m
ourCWTzHlMBXWIXKDRKhAmUB0XK2PnZeBV4krVxABXW9Lc1AATCdHLb7fYKuftJI
9mShPv0s2jLsWbMPfAgI/NJVFda1yg5JQm3b4Q0+iBIokZioDcSe8UlyLMWHA7E9
ygtI9m3V96tEQg/GsFp+3/KizVPD/qqGp/5VH6AhifQxjRoFvKLPBrv3xur7lKPx
gmJ1vdhFo/gpr6RMWZydmVFwdlZEe66VljAgB8tz/Xk17m+G5JksXW9UDpB7HcU=
=mbvQ
-----END PGP SIGNATURE-----
--rH8JAPLilKLwTq03sJMa0XiwfrPV3vPb4--