----- Original Message ----- > From: "David Caro" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "Sandro Bonazzola" <[email protected]>, "infra" <[email protected]>, > "Kiril Nesenko" <[email protected]> > Sent: Wednesday, January 15, 2014 5:47:59 PM > Subject: Re: release repo structure and 3.3.2 > > El mié 15 ene 2014 16:30:00 CET, Alon Bar-Lev escribió: > > > > > > ----- 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? > > > > > 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 > includes the fixed packages. It's cheap!
who is you? how do I push fix to users for z-stream of packages as otopi, ovirt-host-deploy, log collector and such? why is these components' release cycle should be at same schedule of ovirt-engine which is heavy and slow? > > > > 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-streams. > > > > A change in z-stream should not be exposed (unless is fixing) an external > > interface. > > I don't think it should be hidden neither, just make clear that those > are not builds to be used widely, maybe just putting it under another > directory (not releases). Where only promoted repos can go (meaning, > 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 > tested and not ready for be used widely > why not released? only because engine is slow? I do not understand. > That way you make sure that if anyone is using a repo that is not fully > tested, is because he wants to, but you don't forbid it. why do you think that someone is releasing untested packages? > > > > 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 > >> > >> > > > > -- > 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
