release repo structure and 3.3.2

[Alon Bar-Lev]

----- Original Message -----
> From: "David Caro" <dcaroest at redhat.com>
> To: "Sandro Bonazzola" <sbonazzo at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>, "infra" <infra at ovirt.org>
> Cc: "Kiril Nesenko" <kiril at 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ó:
> > 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@-@PACKAGE_VERSION@.tar.gz
> >>
> >> 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: dcaro at redhat.com
> Web: www.redhat.com
> RHT Global #: 82-62605
> 
>