Re: release repo structure and 3.3.2

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: y so people that are subscribed to stable[1] did not get it. repository by yum updating it. in simple "yum update". ACKAGE_VERSION@.tar.gz provide service. allow distro specific code to fetch, the location must be synced with wha= t we publish. y. en retired? for each version? 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 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 --UQOVhnEdnAfdTdS57IlOdxiBx98VKmWw8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" --UQOVhnEdnAfdTdS57IlOdxiBx98VKmWw8--