release repo structure and 3.3.2

[David Caro]

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?

> 
>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20140115/316ffeb3/attachment.sig>