----- Original Message ----- > From: "David Caro" <[email protected]> > To: "Sandro Bonazzola" <[email protected]>, "Alon Bar-Lev" > <[email protected]>, "infra" <[email protected]> > Cc: "Kiril Nesenko" <[email protected]> > 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ó: > > 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 repository 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.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@-@[email protected] > >> > >> 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 with > >> what we publish. > >> > >> Immediate action is to move the 3.3.2 content into the stable directory. > > > > 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 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 repositories. > > 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 together > 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 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 provide a > link > like 'previous_stable' so if you want to rollback to the previous version you > can use --enablerepo=previous_version easily, but if you want to keep 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 space) 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 change 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 not 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 around 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 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?
I think that you do not trust individual maintainer to provide z-streams. And you do not allow quick fix of issues found in various of packages. Although there is /some/ sense in syncing minor releases, I do not see any reason of syncing z-stream. A change in z-stream should not be exposed (unless is fixing) an external interface. 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: [email protected] > Web: www.redhat.com > RHT Global #: 82-62605 > > _______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
