release repo structure and 3.3.2

[Alon Bar-Lev]

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