Mailinglist Archive: opensuse-buildservice (65 mails)

< Previous Next >
Re: [opensuse-buildservice] How to manage a product with very frequent releases and no maintenance for each release
Julio González Gil wrote:
On viernes, 7 de septiembre de 2018 14:41:54 (CEST) Ludwig Nussel wrote:
Julio González Gil wrote:
We basically want to release each two/four/six weeks a new version,
starting with 4.0, promoting packages from systemsmanagement:Uyuni:Master
(development project) to some place.

Check the :ToTest mechanism of Factory.

I think this is exactly what I could need!

However I see at
openSUSE:Factory:ToTest that the project is described as "This project does
not build, it is just for storing snapshots used for automated testing. The
result is released as Tumbleweed" but
view_file/openSUSE:Factory:ToTest/000product/ seems
be publishing to <productoption name="REPO_LOCATION">http://</productoption>

It's not relevant what is in that file. The point about the mechanism is
that the main project can be used for building and only if it's done
building the packages are moved over to :ToTest for testing by
openQA. Based on that the result is released or held back.

Between one version and the other, there will be no maintenance. Each
change, whatever itis, will required a new release and version.

You could see it as Tumbleweed to some extent, but with a big difference:
we really want to have versions, as Leap or SLE, but unlike Leap or SLE,
very frequent releases.

Tumbleweed does have an integer number as version that can be
displayed as date. Just not coded into the project name in OBS. By
default OBS only publishes the last version of the repo to
download.o.o. There is work in progress to keep some previous
snapshots around though:

Yes, I had a look at
master/tumbleweed which is mentioned at one of the links of your link above,
but as you said, the snapshots are not ready yet.

Since you mentioned that "by default OBS only the last version of the repo to
download.o.o", is there a switch I can change at the prjconfig, meta or
_product to change that behaviour?

No, we have scripts on side that implement the
history outside OBS. Nevertheless if that is a more often requested
feature, maybe the OBS team wants to implement it after all ... :-)

What I wanted to say is that instead of jumping through hoops
creating subprojects etc (where users would have to change their repos),
just stick with the one project approach. If historic repo versions turn
out to be really needed, OBS should implement means for that.


(o_ Ludwig Nussel
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups