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:
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Alon Bar-Lev" <alonbl@r=
Cc: "Kiril Nesenko" <kiril@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.
I am, having a stable repository with rolling rpms is a lot more hard = to 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 =
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=
edhat.com>, "infra" <infra@ovirt.org> the p using
that, you should point directly to the specific version you want tot u= se.
Creating a new repository using is almost as cheap (on hard disk space= ) as 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.
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.
-- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Email: dcaro@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@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" -----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--