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 repositor= y so people that are subscribed to stable[1] did not get it. =20 Why not? stable release had ovirt-release-10 which enabled both stable and 3.3.2= repository by yum updating it. =20
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@-@P= ACKAGE_VERSION@.tar.gz
For each minor we should have rolling repository, to reduce noise and =
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UQOVhnEdnAfdTdS57IlOdxiBx98VKmWw8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable El 07/01/14 15:31, Sandro Bonazzola escribi=F3: provide service.
All released tarballs (sources) should be stored at fixed location to =
allow distro specific code to fetch, the location must be synced with wha= t we publish.
Immediate action is to move the 3.3.2 content into the stable director=
y. =20 So previous request of having each release in its own repository has be= en retired? Or is it combined? Do we want stable to be a rolling repository and have also a repository= 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 repositori= es.
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 wh= ole set, that is, one repository with the set of rpms that were tested togeth= er 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 ge= ts it done. For rollbacks you'll have to configure the old repo. That is not as annoy= ing 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 prev= ious version then just use that versions specific repo. At much we can provide= a link like 'previous_stable' so if you want to rollback to the previous version= you can use --enablerepo=3Dprevious_version easily, but if you want to keep u= sing 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 space) a= s 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 change i= n one the the rpms, for example, to fix a critical bug, the repo will not inclu= de the old package, but I'm not sure if that's really a drawback... if you reall= y need that package without the critical fix (you should not) you can have it ch= anging to that specific repository. The internal naming of the repos does not re= ally matter, having to point to the repo 3.3.3-beta.2 to get the second 'respi= n' 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 t= ested * it's a lot easier to get rid of old repos, and to move them around a= s they are independent * no broken links, right now stable repo is full of links to other rep= os, so removing those repos leave the links broken, you have to go checking= 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?
=20
Regards, Alon Bar-Lev.
=20 =20
--=20 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 --UQOVhnEdnAfdTdS57IlOdxiBx98VKmWw8 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 iQEcBAEBAgAGBQJS1qioAAoJEEBxx+HSYmnDN5sH/1ZDK4QTr0Ktg+aoYVajkSr+ aVJCifIE9SpcDwS8O9b296gTc+q7cSzZ3wwSzk/cczGRCx5zsWlI1sTPE5xW3usD 0uCi0OzdLeefq5lYhFc4mI04GZCxeQ7HNOtVZx5HFam8dRPYoGPtzfPGMPw0Yku7 K9p45oJowGZhOBMVHD1kSnbuYCTvBM17nSb+u04FO5ZmkIF8APBacSNkM8et7DxH RVuoX6udklB7058lYvKP6h52aMjgF6HVBnUjaIf82YH0WslwrfbRs1UgXXJiK/HG sxJQok+ZTOWrj68ybdv3Kcx92K5bRwk4WSjpcsK2vVCr8+NA5swiMUqyAwzKmDM= =meiM -----END PGP SIGNATURE----- --UQOVhnEdnAfdTdS57IlOdxiBx98VKmWw8--